David Snelling
a7eb7f5222
`getIdsForRange` routes two ways. The column store compares RAW values and is
correct. The legacy sparse chunk index — the pre-7.20.0 fallback, still read for
workspaces that have not been rebuilt — compared normalizeValue() output, and
normalizeValue carries an escape hatch that destroys order on purpose: a string
over 100 characters becomes a short hash so it can serve as a filesystem-safe
key. Ordering hashes ranks rows by digest.
Two shapes, both silent:
(a) A LONG BOUND against ordinary values. `{ gte: <a 120-character string> }`
collapsed the BOUND to `__HASH_…`, whose leading underscores sort below
every letter — so a bound that should have excluded everything matched the
entire field instead. Measured on the fixture here: 3 of 3 rows returned
where 0 is correct. This shape reaches a caller who never stored a long
value at all.
(b) LONG VALUES in the index. The field was persisted hashed, so its order is
not recoverable from this index. The old code compared the digests anyway
and returned a subset chosen by hash — 1 of 3 rows, the wrong one.
Bounds are now normalized WITHOUT the hash escape hatch, so a long bound stays
comparable and (a) is simply fixed. Where the persisted KEY is a hash the order
does not exist to be computed, and the query throws a typed
BrainyError('INVALID_QUERY') naming the field and the cure. The refusal is
checked before chunk SELECTION as well as during the scan: selection orders the
bounds against each chunk's zone map, and its failure mode is an empty answer —
the quietest wrong answer of all. Equality on a hashed field is untouched; only
ordering is refused.
KNOWN, NAMED DIVERGENCE, recorded in the doc comment rather than papered over:
the persisted keys are also lower-cased and trimmed, so this path's string
ranges are case-INSENSITIVE where the column store's are not. The raw values are
not in the index to compare — that is a property of the bytes a pre-7.20.0
engine wrote, and it ends when the column store adopts the field.
The pin builds a genuine legacy index through the same ChunkManager /
SparseIndex doors that engine wrote through, into a field the column store does
not serve. The chunk write path was removed in
|
||
|---|---|---|
| .. | ||
| collation.test.ts | ||
| contentExtractor.test.ts | ||
| entity-id-mapper-stability.test.ts | ||
| entity-id-mapper-u32-ceiling.test.ts | ||
| indexReadiness.test.ts | ||
| memoryLimits.test.ts | ||
| metadataIndex-nested-orderby.test.ts | ||
| metadataIndex-sort-callshape.test.ts | ||
| metadataIndex-sparse-range-collation.test.ts | ||
| metadataIndex-text-indexing.test.ts | ||
| metadataIndex-type-aware.test.ts | ||
| metadataIndex-watermark.test.ts | ||
| mutex.test.ts | ||
| osLimits.test.ts | ||
| paramValidation.test.ts | ||
| resultRanking.test.ts | ||
| roaring-bitmap-integration.test.ts | ||
| unifiedCache-eviction.test.ts | ||