[tae898]

Closes #317. Part of #315 and the glue changes of the wheels-only 26.11.1.post1. Nothing changes for users: the records, their values and the error messages are those of the lazy form, and the test below compares them with it.

What changes: on the native wheel, save() of a new record and Vertex.new_edge run their statement with the lazy command form (arcadedb_n_cmd returns a cursor id) and then read the one row they always read with a second crossing (arcadedb_n_next_bin). They now call a private NativeDatabase._command_first_row, which is command through the existing form of arcadedb_n_exec whose reply already carries the first rows (the lazy bit of its flags left off), so a create is one crossing instead of two. save() of a saved record uses the same form for both of its UPDATE statements (the exact one and the RETURN AFTER one), so an update is three crossings instead of four. Public command is unchanged and keeps the lazy form for every other caller. Both forms run the same Java code to pull the rows; error timing is the same on both forms: an error the engine raises while it runs the statement (an INSERT or UPDATE, which save() sends) is raised by the call, as by command, and one met while rows are computed lazily (a SELECT run as a command) comes in the reply as rerr and is raised when the row is read, as before. Public command is unchanged.

The stale-record check is not read from the update's own result, and I kept it as it was. The engine's reply to an UPDATE comes after the write, and save() promises that it writes nothing when the stored record changed. A before-image from RETURN BEFORE would only show the conflict after the caller's transaction already holds the write, so it would change what a caller that catches the error sees. The SELECT and the is_transaction_active crossing stay.

Peak memory does not rise: a create drops a cursor and a call, the reply holds the same one row.

Tests (tests/test_native_one_row_crossings.py, native backend only): spies on the ctypes doors (cmd, call, call_bin, exec_query and the batched cursor close) count the crossings of one save() (create: one, also with a float array, which takes arcadedb_n_exec_bin), one new_edge with and without properties, and one update (three, for the exact and for the read-back form). They fail on the old code, which makes two and four. Oracles on the old behaviour: every created record (ints, text, non-ASCII, date and time, decimal, list and map, float array, nothing) is compared with the record the lazy statement INSERT INTO D CONTENT :row returns and with a lookup by RID; a unique-key violation raises the same message and class as the lazy form; a stale record is still refused with ConcurrentModificationException and writes nothing; an update outside a transaction still raises before any read. Added after review: a before_create veto on a new record (no error, no record id, nothing stored, one crossing, and the same object saves once the veto is lifted), a before_update veto on both UPDATE forms (nothing written, three crossings, and the next save is no conflict), a statement error (a division by zero in an INSERT and an UPDATE: same timing, message and class as the lazy form, raised by the call in both, as a CI run showed) and a row error (a SELECT run as a command: raised when the row is read, by both forms, with the Reading the result set failed: message), and a before_create callback that raises. tests/test_native_statement_texts.py and tests/test_native_save_baseline.py (statement texts and the number of copies) are untouched and must pass, and so must tests/test_cross_wheel_golden.py. I could not run any of it here (CI only); the runs are listed below.

No speed claim: the measurement is a later laptop A/B, and the untimed profile studies queued for tonight. I did not touch lookup_by_rid, which keeps the record id in its SQL text (#229).

🤖 Generated with Claude Code