Expand description
Sets, from the embedded side.
The same store SADD off a socket reaches (Y23), through two doors. Sets
is the keyspace shape, one method per Redis command with the key as the first
argument, which is what a program porting off a Redis client wants. Set is
one key with a handle around it, which is what a program that was never going
to use Redis wants: a set is a set, and the name of it gets spelled once
rather than at every call site.
A Set holds the Sets it goes through rather than building one per
call, so reaching a set by its handle costs the key it already had and
nothing else. There is no door here that is the slow one.
§Owned or borrowed, per call
Every read that hands back members comes in two forms. Set::members
allocates a Vec per member, which is what most code wants and what every
other embedded database gives you. Set::for_each hands each member over
where it lies and allocates nothing, which is Y29’s rule that zero copy is
available and never mandatory.
The difference is not decoration. A set stored as integers holds them as
integers, so walking a million member set with members formats a million
numbers into a million Vecs, and walking it with for_each formats none of
them unless the closure asks. That is why the borrowed form hands over a
Member and not a &[u8]: the choice of whether to spend the digits is
the caller’s.