[tae898]

Second slice of #267 (audit of the docs against 26.11.1). It covers row 3 (types and datetimes), row 9 (record objects) and row 12 (the Schema API line), in one new page, how-to/values-and-records.adoc.

Tests first: tests/test_values_and_records_behavior.py pins, with SQL and wrapper objects only, how Python values go in and what comes back (scalars, the declared type winning over the Python type, Decimal, naive and aware datetime, the precision of DATETIME_SECOND, DATETIME and DATETIME_MICROS, date, bytes as signed ints, tuples, dicts, sets until the commit, an embedded document), what a query row and a record object give (methods only, no item access or attributes, to_dict() is a new dict), that a record or row is the record as it was read, modify(), save() and a stale save, identity, lookup_by_key, and the Schema API next to SQL. Several of these statements were already pinned one by one in older tests (test_type_conversion.py, test_graph_api.py, test_schema.py); the new file holds them in the form the page states them. The page says only what those tests prove, and tests/test_docs_values_page.py runs every Python block of the page on both builds and checks the printed output, in the pattern of the transactions page. The nav gets one line, and Databases and queries and the quickstart link to the page (a [[record-ids-in-rows]] anchor was added for that link).

I could not run the tests on the laptop (CI runs them), so the assertions came from reading type_conversion.py, graph.py, results.py and the native codec, records and schema code, plus the older tests above. The Antora build of the component passes locally with no warning. The first CI run found one wrong statement (the embedded document above) and it is fixed here. The JVM test workflow on the current head passes (24 of 24 jobs); the native parity legs run now that the PR is ready.

Behavior worth a look, none of it filed:

• On the native build Result.get() and Document.get() return the object the row or record holds, and to_dict() is a shallow copy, so changing a list or dict you got back changes what the same row or record returns next. On the JVM build every get() converts afresh, so it does not. Read from _native/database.py and _native/records.py, not run: the page only says that such a change is never stored.
• Document.get_rid() of a record that was never saved returns "#-1:-1" on the native build; on the JVM build it is str(None) by my reading of graph.py (the identity is null until save()). The page and the tests only use get_rid() after save().
• A Document, a Vertex and an Edge have no __eq__: two reads of one record are two unequal objects, and a row has no __getitem__ or attribute access, so row["name"] raises TypeError. That is documented as is.
• Bytes come back as a list of signed ints, not bytes, and a set comes back as a list after the commit. Both are stated as they are.
• Confirmed by CI: on the JVM build to_dict() and to_list() give the engine's own Java object (ImmutableEmbeddedDocument) for a nested embedded document, not a dict. On the native build the source gives a dict with an @type member. The page says this once, per build, and points to the dotted path in the statement (SELECT em.q AS q), which returns the plain value on both.
• The Schema create and get methods return a Java object on the JVM build and a placeholder on the native build, so the page tells readers not to use the return value. That sentence comes from the source and has no test.
• get_or_create_property on the JVM build passes the type name to the engine without upper-casing it (create_property upper-cases); the page uses upper-case names and does not rely on this.

Left of #267: row 4 (import and export) and row 5 (DataFrame, Arrow and columns) are on the other open branch; rows 8 (Python functions and events), 10 (set_wal_flush, fileSync, txWalGroupCommit) and 11 (AsyncExecutor) are not started. Rows 6, 7 and 13 and the stale statements were planned for #264 and #276; I did not re-check them against main.

Refs #267

🤖 Generated with Claude Code