-
Notifications
You must be signed in to change notification settings - Fork 353
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MultiIndex
primary key spec removal
#569
Conversation
81236b5
to
9a517d3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, mostly nitpicking comments regarding comments.
pub struct MultiIndex<'a, IK, T, PK = ()> { | ||
index: fn(&T) -> IK, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This K -> IK change is quite sudden. I understand that K
stands for Key
, but is IK
an IndexKey
?
I think it would be good to have some reference to it... I doubt it will be clear to people diving into this code from outside.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is an index key, yes. It's a way to differentiate it from both a PK
(primary key), and from a generic K
that could stand for any of them.
I don't have the time to dig into this, which it deserves. If you and Jake agree, feel free to merge. Meaning, go ahead and merge, but we commit to no more 0.10.x releases now. And start all the 0.11 cleanup stuff. (When we get to them). Let's get that utils rename in (finally) |
401e386
to
491af83
Compare
491af83
to
2271956
Compare
Closes #533.
Builds on top of #568. Makes it simpler to handle
MultiIndex
by removing the pk from the index key specification.Solved it by collapsing the index key along with an extra element (the raw pk). This makes it possible to keep the old format in the store, as the new (internally generated) index key would be exactly the same as the one corresponding to the previous key spec.
Overall, I'm pretty happy with this implementation. It has some tricks, like shifting the definition of what is a prefix and a sub-prefix. So that prefixes can still be specified over the full index key (which doesn't include the primary key in its spec anymore). Despite (or because of) that, I think the end result is both clear and ergonomic.
This PR also renames
K
toIK
for clarity. So, it also closes (the second part of) #531.TODO:
Update related documentation / comments. (done)