Add support for bytes key btree indices#4733
Merged
Conversation
joshua-spacetime
requested changes
Mar 31, 2026
Collaborator
joshua-spacetime
left a comment
There was a problem hiding this comment.
I think more testing is needed for this patch.
0367d60 to
58644fe
Compare
58644fe to
e649f64
Compare
047db8f to
1db5d12
Compare
Ludv1gL
added a commit
to Ludv1gL/SpacetimeDB
that referenced
this pull request
Apr 20, 2026
…abs#4733 The uniqueness-conversion macro has `HashBytesKey{8,24,56,120}` entries but no btree counterparts. Adding them needs `RangeCompatBytesKey` (a range-compatible ordering over bytes keys), which is introduced in clockworklabs#4733. A TODO inside the btree arm of `define_uniqueness_conversions!` makes the dependency explicit; the follow-up will also revisit the `HashBytesKey*` closures flagged in the review. Addresses review comment at table_index/mod.rs:1688.
5 tasks
joshua-spacetime
approved these changes
Apr 23, 2026
Ludv1gL
added a commit
to Ludv1gL/SpacetimeDB
that referenced
this pull request
Apr 23, 2026
…abs#4733 The uniqueness-conversion macro has `HashBytesKey{8,24,56,120}` entries but no btree counterparts. Adding them needs `RangeCompatBytesKey` (a range-compatible ordering over bytes keys), which is introduced in clockworklabs#4733. A TODO inside the btree arm of `define_uniqueness_conversions!` makes the dependency explicit; the follow-up will also revisit the `HashBytesKey*` closures flagged in the review. Addresses review comment at table_index/mod.rs:1688.
Ludv1gL
added a commit
to Ludv1gL/SpacetimeDB
that referenced
this pull request
Apr 23, 2026
Thread the index's key type through `TypedIndex::iter_duplicates` and the
`define_uniqueness_conversions!` macro so bytes-keyed variants can round-
trip their keys back to `AlgebraicValue` via `TypedIndexKey`'s existing
`decode_algebraic_value` path.
- Add `BTreeBytesKey{8,16,32,64,128} <=> UniqueBTreeBytesKey*` conversion
pairs to the macro, now unblocked by upstream clockworklabs#4733 providing
`RangeCompatBytesKey`.
- Replace the `HashBytesKey{8,24,56,120}` placeholder closures (which
debug-stringified the raw bytes into `AlgebraicValue::String`) with the
correct `TypedIndexKey::BytesKey*H(*k).into_algebraic_value(ty)`
round-trip; reviewer-requested "via `IndexKey` → `AlgebraicValue`"
shape.
- Drop the `TODO(clockworklabs#4733)` comment and grow all closures to accept the
`&AlgebraicType` key-type parameter (ignored by scalar variants).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of Changes
Add support for btree indices where the keys are encoded byte strings for e.g., multi-column indices of no-unbounded-types (arrays and strings) that aren't floats.
The main interesting stuff in this PR is in
bytes_key.rswhich definesRangeCompatBytesKey, a type that is derived fromBytesKey, by converting little-endian encoded integers to big-endian. Signed integers are now also supported, but floats are not.table_index/mod.rsalso includes a bunch of interesting stuff.API and ABI breaking changes
Technically this fixes pre-existing bugs in the handling of
Excludedranges for multi-col indices.Expected complexity level and risk
2?
Testing
order_in_bsatn_is_preservedis now adjusted and enabled to exercise the ordering ofRangeCompatBytesKey.btree_multi_col_range_scans_workis added to check the behavior of range scans on multi-col indices.