[CaffeinatedCoder]

What was wrong

With an index on a double (or float), queries that hit zero did not treat -0.0 and +0.0 as equal:

// d1: Ratio = -0.0;  d2: 0.0;  d3: 1.0   (HasIndex(x => x.Ratio))
Where(x => x.Ratio == 0.0)   // expected [d1, d2], was [d2]
Count(x => x.Ratio == 0.0)   // expected 2, was 1

x.Ratio >= 0.0 also left out -0.0, and x.Ratio < 0.0 included it. C#, LINQ-to-Objects and the plain collection all use IEEE 754 equality, where -0.0 == 0.0.

Mechanism

IndexKey(double) is an order-preserving bit encoding: a negative value has all its bits inverted, a positive value only its sign bit. -0.0 has the sign bit set, so it encoded to 0x7FFF…FF, just below +0.0's 0x8000…00. The equality plan is a point lookup on the key of +0.0, and range bounds fall between the two zeros.

Fix

• IndexKey(double) maps a zero to +0.0 before taking the bits (if (value == 0) value = 0.0;). Stored keys and query bounds both go through this constructor, and so do float keys (ConvertToIndexKey and the optimizer widen them to double). One line fixes both sides.
• Existing indexes. An index written by an earlier release keeps -0.0 under the old key. No query bound reaches that key any more. Worse, an update or delete of the document now computes the +0.0 key and leaves the old entry behind, still pointing at a location that may be reused for another document. So the fix also hooks into the key-format migration that already runs on open (MigrateLegacyDecimalIndexes, which rebuilds legacy decimal and full-text indexes). NeedsKeyFormatMigration is now also true for a single-property double/float B-tree index that holds the old -0.0 key. The check is one range seek per such index on each open; an index without that key is left alone, and the test checks that.
• No KeyFormat bump. I checked this, as the issue suggested: no other key changes, and the trigger is the presence of the old key, not a format number. A bump would rebuild every double index on upgrade, whether or not it holds a -0.0. Checking the key also catches a -0.0 that an older release writes to the file after this one rebuilt it.

Tests

SignedZeroIndexTests (6 tests) seeds -0.0, +0.0, negative and positive values on an indexed and a plain collection and compares each query with LINQ-to-Objects:

• == (both zeros, plus a float property);
• >=, >, <, <= with a zero bound, and a closed range ending at 0.0;
• Count;
• OrderBy ascending and descending, a Skip/Take window over the two zeros, and Where(>= 0.0).OrderBy;
• the IndexKey values themselves.

One more test writes the old -0.0 key into an index, then checks that the next open rebuilds it, that the entry then goes away with its document, and that the second index (no -0.0 key) and a later open rebuild nothing.

Guard: with the src change reverted, all 6 fail. With only the migration reverted (the IndexKey change kept), the migration test fails. Full dotnet test tests/BLite.Tests: 3098 passed, 0 failed, 4 skipped.

Compatibility

• Index-served queries on double/float properties now match the plain path for -0.0.
• The first open after upgrading rebuilds any double/float index that holds a -0.0 key, with the same machinery and failure behaviour as the decimal migration.
• Compound keys (more than one property) are not checked. They would need a rebuild by hand (DropIndexAsync + recreate) if they hold a -0.0 written before this change.
• NaN is out of scope, as in the issue.

Not fixed here: dynamic double indexes (#254)

DynamicCollection keys doubles with new IndexKey(BitConverter.GetBytes(d)) (BsonValueToIndexKey and CreateIndexKeyFromObject). That encoding is little-endian and not order-preserving. I checked on this branch with a throwaway test (not committed): with an index on ratio over 0.1, 2.2, 1.3, 5.7, -3.3 and 1.0000001, BLQL {ratio: {$lt: 2.0}} returns nothing and {$gte: 1.0, $lt: 3.0} returns nothing, while the unindexed collection returns 4 and 3 documents. {ratio: 0.0} also misses -0.0 there.

I did not touch the dynamic path. Normalising the zero alone would bring the same leftover-entry hazard as above, and the real fix (switching to the order-preserving IndexKey(double)) means rebuilding every dynamic double index. That rebuild would fix -0.0 there for free. Filed as #254.

Fixes #249

PR #250 (oracle tests) lists these rows as known candidates (-0.0 is not found by an equality on an indexed double) and will drop the entries once this lands.

Merge order

#282 (one key for every NaN, #257) is stacked on this PR: both change IndexKey(double) at the same line. This one lands first. #282 is rebased onto it and carries both changes; I will retarget it to main once this merges.

🤖 Generated with Claude Code

[mrdevrobot]

Verified: the tests fail on 0450b97 and pass here; diff stays within #249. On-disk note: -0.0 now takes the key of +0.0, and an index holding an old -0.0 key is detected and rebuilt on open.