Working on the secondary indexes, I made a bunch of mistakes conflating PrimaryKey vs Value vs a sub-portion of Value. These newtypes are good to have back in.
I think the optionality of types makes a lot more sense now. We're treating LSMTree as an abstracted dict data structure. Primary index LSMTree can take a "tombstone"-typed value. Client sees Option<Value> only, not tombstone.
primary index is LSMTree<PrimaryKey, OptDatum<Value>>
secondayr index is LSMTree<SubValueAndKey, Bool>
(You can see the code on branch ysono/secidx/wip, though it's very messy right now.)
Working on the secondary indexes, I made a bunch of mistakes conflating PrimaryKey vs Value vs a sub-portion of Value. These newtypes are good to have back in.
I think the optionality of types makes a lot more sense now. We're treating LSMTree as an abstracted dict data structure. Primary index LSMTree can take a "tombstone"-typed value. Client sees
Option<Value>only, not tombstone.LSMTree<PrimaryKey, OptDatum<Value>>LSMTree<SubValueAndKey, Bool>(You can see the code on branch
ysono/secidx/wip, though it's very messy right now.)