feat: bitmap commands (GETBIT, SETBIT, BITCOUNT, BITPOS, BITOP) - #316
Merged
Conversation
implements all five redis-compatible bitmap commands backed by Value::String storage with big-endian bit ordering (bit 0 = MSB of byte 0). no new value type — bitmaps reuse the existing string type. - GETBIT / SETBIT with auto-extension and old-value return - BITCOUNT with byte-range and bit-range (BIT unit) support - BITPOS finds first set/clear bit; returns -1 when not found - BITOP (AND, OR, XOR, NOT) operates across arbitrary source keys, result length equals the longest source - AOF persistence for SETBIT and BITOP (tags 33 and 34) - recovery replay in ember-persistence without cross-crate dep (BitOpKind encoded as u8 in AofRecord) - fix pre-existing spawn_shard arity mismatch in shard unit tests (expired_tx param added in #313 but tests not updated) - 15 integration tests + 20 unit tests covering edge cases
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
1 participant
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.
summary
adds the five redis-compatible bitmap commands backed by
Value::Stringstorage with big-endian bit ordering. bitmaps don't introduce a new value type — they reuse the existing string variant, just like redis.GETBIT — returns bit at offset, 0 for missing keys
SETBIT — sets a bit, auto-extends the string with zero bytes, returns old value
BITCOUNT — counts set bits; supports both byte-range and bit-range (BIT unit, redis 7.0 compatible)
BITPOS — finds the first set or clear bit; returns -1 when not found
BITOP — applies AND/OR/XOR/NOT across multiple source keys, result length equals the longest source; missing keys are treated as zero-filled
bit ordering is big-endian (bit 0 = MSB of byte 0), matching redis semantics.
persistence uses two new AOF record tags (33=SETBIT, 34=BITOP). because
ember-persistencedoes not depend onember-protocol,BitOpKindis encoded as au8inAofRecord(0=AND, 1=OR, 2=XOR, 3=NOT) and decoded without importing the enum.also fixes a pre-existing arity mismatch in shard unit tests — the
expired_txparameter was added in #313 but test call sites weren't updated.what was tested
crates/ember-core/src/keyspace/bitmap.rscovering all five commands, wrong-type errors, boundary conditions, and bit-range unit semanticstests/integration/src/bitmap.rscovering the full round-trip through the server: setbit/getbit, auto-extension, big-endian byte check, bitcount with byte and bit ranges, bitpos on missing/set/clear, bitop AND/OR/XOR/NOT, result-length semantics, and missing-source zero-fillcargo test -p emberkv-core— 560 passed, 0 failedcargo clippy -p ember-protocol -p emberkv-core -p ember-server -- -D warnings— cleancargo fmt --all— applieddesign considerations
storing bitmaps as strings keeps the value type count flat and avoids any migration concerns. the bit-range BITCOUNT operates bit-by-bit rather than rounding to byte boundaries, which is correct per the redis spec but slightly slower for large ranges. for the sizes typically used (bitmaps rarely exceed a few MB), this is not a concern.