bindings docs: known issues, three fixed for 26.10.1 and the NOTUNIQUE_HASH delete failure; hash advice qualified - #49

Closes #48.

• Known Engine Issues: A UNIQUE composite index answers a lookup by its first property with part of the entries: WHERE host = ? returns 12,589 of 30,000 rows (26.8.1 to main) ArcadeData/arcadedb#8806 (fixed by PR fix: #8806 unique prefix lookup, #8811 ORDER BY index via aliases, #8802 top-K ArcadeData/arcadedb#8821, merged 45004cd), SQL UPDATE that moves an indexed key forward, filtered by a range on that key, updates the same record again and again (Halloween problem): UPDATE V SET a = a + 10 WHERE a < 1001 makes 50,601 updates for 1,001 records (26.8.1 to main) ArcadeData/arcadedb#8814 and Inside a transaction, an index range or index-end read misses the records the transaction inserted once the LSM index has a compacted sub-index: WHERE a BETWEEN 500 AND 509 returns 0 of 10 (26.8.1 to main) ArcadeData/arcadedb#8817 (fixed by PR fix(#8817, #8814, #8813): tx index range after compaction, UPDATE Halloween problem, TS oldest sample after COMPACT ArcadeData/arcadedb#8825, merged bbc23b5) now say they are fixed in 26.10.1, each verified on its merge with its repro on Temurin 25 and 21; they stay on the page while 26.9.1 is what the bindings ship. The SQL UPDATE that moves an indexed key forward, filtered by a range on that key, updates the same record again and again (Halloween problem): UPDATE V SET a = a + 10 WHERE a < 1001 makes 50,601 updates for 1,001 records (26.8.1 to main) ArcadeData/arcadedb#8814 entry carries upstream's note that UPDATE now applies in storage order, which can change the row order of RETURN BEFORE/AFTER (our one RETURN AFTER test compares a set, unaffected).
• New entry for Deleting records from a type with a NOTUNIQUE_HASH index fails at commit once a key holds a few dozen records (ArrayIndexOutOfBoundsException / Cannot write outside the page space in HashIndexBucket.compactPage; 26.9.1 to main) ArcadeData/arcadedb#8829 (26.9.1 to main): deleting records with a NOTUNIQUE_HASH index fails at commit once a key holds a few dozen records. Workaround verified on the same repro: with a NOTUNIQUE (LSM_TREE) index all 30,000 deletes commit at 300 and at 30 records per key, and the index matches a scan.
• Queries guide: the paragraph that recommended NOTUNIQUE_HASH for values many records share (status, country) now says to use NOTUNIQUE there until Deleting records from a type with a NOTUNIQUE_HASH index fails at commit once a key holds a few dozen records (ArrayIndexOutOfBoundsException / Cannot write outside the page space in HashIndexBucket.compactPage; 26.9.1 to main) ArcadeData/arcadedb#8829 is fixed, with a link to the page.

mkdocs build passes locally; the links resolve.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WWcDr7TwvcfMsQkeYQVHZr