[tae898]

Database.lookup_by_key on an unindexed key scanned the type on the native wheel (arcadedb) and raised on the JVM wheel (arcadedb-jvm). Measured on the CI wheels of main 662851c (26.11.1.dev0), same script, same database.

Before, per backend (type D with an integer k, no index; then an index on k; a composite index on (a, b); a FULL_TEXT index on t):

call	native (before)	JVM
["k"], no index, hit	record	raises No index has been created on type 'D' properties [k]
["k"], no index, miss	None	raises (same)
["k"], UNIQUE index, hit / miss	record / None	record / None
["a"] and ["b", "a"] on index (a, b)	record	raises
["t"] on a FULL_TEXT index	None	raises No key index has been created ... FULL_TEXT
unknown type	raises was not found	raises was not found

The contract is the JVM one, because that is the engine: LocalDatabase.lookupByKey throws IllegalArgumentException unless the type or a supertype has a ready LSM_TREE or HASH index on exactly that property list (getPolymorphicIndexByProperties, isExactKeyLookup). The docstring already says the keys "must be indexed" and the user docs do not mention the method, so no document promises a scan.

The fix: the native lookup_by_key no longer runs a SELECT ... WHERE. A new entry point of the native library, arcadedb_n_lookup in NativeExtras.java, calls the engine's own Database.lookupByKey(type, keys, values) inside the image and replies with the first hit (none or one row) in the shape of a statement reply, so Python reads it with the reader of a SELECT and wraps it as a Document, Vertex or Edge. The engine's exceptions become the error reply and so the same ArcadeDBError text as on the JVM build, with no extra query on the hot path (one crossing, as before). This is the case where the bindings wrap a Java call instead of a statement: no SQL or Cypher statement raises when no index serves the keys. The docstring of the JVM method gains a Raises section and the exact-index rule. vector.py already catches ArcadeDBError from this call and falls back to a query, so find_nearest by key behaves as before.

Tests: tests/test_lookup_by_key_index.py (15 tests) is shared, no conftest entry. Unindexed hit and miss raise, UNIQUE/NOTUNIQUE/UNIQUE_HASH/NOTUNIQUE_HASH work once created, a dropped index raises again, an index on another property does not serve, a composite index serves exactly its list (prefix and reordered raise), FULL_TEXT raises, an index on a supertype serves subtypes two levels down but a subtype index does not serve the supertype, vertex and edge types follow the same rule, an unknown type names the type. On the CI wheels of main, 14 of the 15 fail on the native wheel and all 15 pass on the JVM wheel (the 15th is the one that already holds). With this change: JVM 15 of 15 (local, the core.py docstring is the only change there). Native: not run yet at the time of writing. Test native in CI builds the image from this commit, but it skips a draft PR, so it starts when the PR is marked ready for review. A local image build from this commit (native/scripts/build-image.sh through quiet_build.sh, then the new tests and the existing lookup tests on the native backend) is queued; its result will be added here. The Java compiles (GraalVM CE 25.4.4.1.1, mvn -o compile in native/).

Separate observation, not part of this change: on the native wheel SELECT FROM schema:indexes reports typeName D for the bucket index of a subtype Sub of D (Sub_0_...), where the JVM wheel reports Sub. Same engine rows, different typeName; worth its own look.

black and isort are clean, scripts/check_no_embedded_name.py --root . passes.

🤖 Generated with Claude Code