[tae898]

What does this PR do?

The JVM wheel's to_list() and iter_dicts() decode every TypedRows batch with json.loads(text, object_hook=_typed_hook(side)) and read the batch's side array first, also when the batch holds only plain values. The hook is a Python call per JSON object, and reading the side array is a JPype operation per batch (per row for iter_dicts(), which reads one row per crossing). I added _loads_typed_batch in src/arcadedb/results.py: it looks for the tag escape in the batch text first, and when it is absent it parses with plain json.loads and does not touch the side array. _loads_typed_row already does this for a single row. No Java change, and the native wheel is untouched.

How "nothing tagged" is decided, and why that is exact

The side array is not a usable signal: DECIMAL, dates, datetimes and sets are tagged without a side entry. The text is:

• TypedRows.java writes a tag in two places only, tagged() and the r row of appendRow(), and both spell it with the six characters \u0001. quote() writes a control character inside a string as the same escape, and no path writes the raw character.
• Every side array entry is referred to by an index inside a tag (toSide() and the r row). A text without those six characters therefore has no tag and no side index.
• _typed_hook returns any object that lacks the tag key unchanged, so json.loads(text) gives the same value as the hooked parse.
• The error can only go one way. A string that holds U+0001, or the text \u0001, also puts the escape into the text. The check then says "maybe tagged", the hook stays, and it changes nothing.

How it is verified

• The tests came first, in their own commit (ff852ad): tests/test_typed_batch_guard.py. It counts the hook factory, the object_hook argument of json.loads and the batch elements that are read. A result of plain values (three batches for to_list(), a row per crossing for iter_dicts()) must use no hook and never read element 1. Every kind of value the bridge tags (Decimal, big integer, dates, datetimes, instants, sets, NaN and the infinities, float and double arrays, a map with an int key or the tag as key, tagged values nested in lists and maps) must keep the hook. One tagged row among 2,100 must hook exactly one batch. to_list() and iter_dicts() are also compared with the old always-hooked decoding of the same batches over each shape alone, a mixed result, the wide table of test_typed_rows.py and batch boundaries. The counting tests fail on the old decoder (every batch gets a hook and a read of the side array) and pass on the new one. The file is not collected on the native wheel (NATIVE_NOT_APPLICABLE).
• On my machine I ran only light checks, no JVM: black, isort, ruff and pyflakes on the changed files, compile() of the sources, the real results.py against fake batches (the old code hooks every batch, the new one only the tagged ones), and a differential run of 30,000 random TypedRows-shaped texts, with U+0001 and the escape text inside strings, against the always-hooked decoding. Every result was equal. Those scripts are not in the PR.
• CI: this is a draft, and test-jvm.yml skips the platform matrix for a draft, so the JVM tests have not run yet. They run when the PR is marked ready for review.

Related issues

Part of #315. It stays open: nothing here claims a speed result.

Performance changes

Not measured yet. The speed claim waits for a timed A/B of a candidate wheel against 26.11.1.post2 (interleaved runs, a control run of the baseline against itself, the median ratio with its interval).

Docs

No page or README.md describes how a batch is decoded, and no behavior changes, so none is updated.

Checklist

• A regression test fails on the old code and passes on the new (the counting tests; confirmed against the real functions with fake batches, not yet by the JVM suite in CI)
• The test suite that the change can affect passes (waits for CI on the ready PR)
• uvx pre-commit run --files <changed files> passes (I ran black, isort and ruff with the versions pinned in .pre-commit-config.yaml, not pre-commit itself; the CI pre-commit job covers it)

🤖 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.