fix: secondary index range #214
Conversation
vincent-herlemont
force-pushed
the
fix_secondary_index_2
branch
from
b18e352
to
56f4990
Compare
vincent-herlemont
force-pushed
the
fix_secondary_index_2
branch
5 times, most recently
from
003d9e0
to
c1f59b5
Compare
vincent-herlemont
force-pushed
the
fix_secondary_index_2
branch
from
c1f59b5
to
5c65e0f
Compare
|
The solution described in this comment was not good, because in all cases, a bug could appear by shifting the bytes—see the test: The adopted solution is to use MultimapTable to manage secondary indexes, which avoids concatenating keys and provides a much more stable solution. An automatic migration was also coded so that users do not have to do anything and no data is lost. |
| let start = start.to_key(); | ||
| let mut end = end.to_key(); | ||
| // Add 255 to the end key to include the last key | ||
| end.extend(&Key::new(vec![255])); |
There was a problem hiding this comment.
There is no difference between this and the one above? Should this be start.extend ?
There was a problem hiding this comment.
Well spotted, you're absolutely right to find this code strange; it's one of the things that needs refactoring and will be removed.
By the way, just a little background on this legacy code: in the case of Rust ranges and the workarounds put in place here, it’s all about the inclusive end range because we use start..=end.
There was a problem hiding this comment.
@C4Phoenix Here is the cleaned code a0b2e8c, in fact, part of the code might not be supported due to the syntax of ranges in Rust.
The bug is related to the formation of secondary keys, which were created from the primary keys in cases where the secondary key is not unique.
The problems encountered in this issue #208 show that this causes a problem when trying to scan with an inclusive range. This is because the secondary key concatenated with the primary key is always greater than the inclusive range (and falls outside the interval). To address this problem, I attempted to implement a byte delimiter by setting one byte to
0when creating the key, and adding a byte set to255when creating the inclusive range. Since255is always greater than0, the inclusive range will have the correct values.