[tae898]

What does this PR do?

Part of #317 and #315. This is a small, exact piece of the update half of #317, and it leaves the default case at three entries. I am opening it as a draft so that the rest can be decided with the facts below.

On the native wheel, save() of a saved record (record.set(...) then save()) makes three entries into the library, as I read _save_update in src/arcadedb/_native/records.py: is_transaction_active() (arcadedb_n_tx), query(SELECT FROM :rid).first() for the stale-record check, and the UPDATE ... MERGE (exec_query, or arcadedb_n_exec_bin with a float array). The JVM wheel does it in two. #329 did the create half and moved the UPDATE to the eager form; it kept these three on purpose.

The change: the check was not db.is_transaction_active() and not db._auto_transaction, so the crossing was made first and its answer thrown away whenever auto-transaction is on. The operands are swapped, so the state is not asked for when the flag is on (a Python attribute is read instead of a crossing).

case	entries before	entries after
save() of a saved record, auto-transaction off (the engine default), inside a transaction	3	3
same, outside a transaction (refused with "Transaction not begun")	1	1
same, auto-transaction on, bare or inside a transaction	3	2

I did not count the foreign calls inside one entry, so I make no claim per entry. Nothing observable changes: with auto-transaction off the error, its message and its place (before any read) are the same, and with it on a closed database raises the same "Database is closed", from the SELECT instead of from the state call.

Why the default case stays at three

I looked for a way to get to two without a Java change and found none that keeps every behaviour.

• The engine's own refusal cannot replace the check. In LocalDatabase.updateRecord the validation and the before-update events run before the engine looks for a transaction, so a save outside a transaction would run Python callbacks (or be swallowed by a veto) before it raised, and an UPDATE of a record that is gone raises nothing. I read this in the 26.12.1-SNAPSHOT source; I have not checked the 26.11.1 tag.
• A Python-side record of the state would be exact for begin, commit and rollback, which all go through _tx_text, but a SQL COMMIT or ROLLBACK sent through command ends the transaction without passing there, so a stale "active" would skip a refusal the user relies on.
• The SELECT cannot be folded into the UPDATE from Python. RETURN BEFORE shows the conflict only after the write is in the caller's transaction (Native: a created or updated record reads its row in the statement's crossing (closes #317) #329 said the same). A conditional UPDATE would compare with the engine's =, not with _same (1 against 1.0, NaN, 0.0 against -0.0, a Decimal's scale, a missing key against a null), and a count of zero cannot tell a stale record from one that is gone.

What would need a native change, as a separate PR if you want it: the reply of arcadedb_n_exec carries "active":<bool> under a flag bit (db.isTransactionActive() is a thread-local read), so the SELECT of the stale-record check answers the transaction question too, and the default case is two entries. One entry would be a dedicated entry point that does the check, the compare and the merge in the engine, with the rules of _same ported to Java. I did not add either here.

Related issues

Part of #317 and #315. No closing keyword: #317 stays open.

Performance changes

Not measured yet: the speed claim waits for a timed A/B of a candidate wheel against 26.11.1.post2. This PR makes no speed claim, and it only changes a path that is off by default.

Tests

In tests/test_native_one_row_crossings.py (native backend only), in a first commit of their own:

• two entries for an update with auto-transaction on, bare and inside a transaction, for the exact form and for the read-back form (four cases). By reading the code they make three entries on the commit before the change; I did not run them there.
• unchanged on both sides: with auto-transaction switched back off the check is back and refuses before any read (["arcadedb_n_tx"]), and still comes first inside a transaction; a stale record is refused with ConcurrentModificationException under auto-transaction too and nothing is written; an update under auto-transaction stores what the same update inside a transaction stores, and leaves the same baseline (the next save of the same object is no conflict), for NULL, float, text, date-time, date, Decimal, a list and map, a float32 array and a value set unchanged.

Docs

None needs it: no page or README section describes the entries of save().

How I verified it

Only light checks here, no build and no test run: compile, black 26.10.1, isort 9.0.2 (--profile black), ruff 0.17.4 and bandit 1.9.4 on the two files, all clean. The tests run in CI only; test-native.yml was started on my fork for this branch (a draft skips the platform jobs here).

Checklist

• A regression test fails on the old code and passes on the new (by reading the code, not yet run)
• The test suite that the change can affect passes (CI on the fork pending)
• The checks that run locally pass (black, isort, ruff, bandit on the two files); uvx pre-commit run --files itself not run here

🤖 Generated with Claude Code

[tae898]

This change shipped in 26.11.1.post3 (on PyPI since 2026-11-14) through the release line, which #387 merged into main with a merge commit. The release line carries the same change as its own commits, so I close this draft. The measurements are on #315.