You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was just something we overlooked when first implementing. We would have to add some bits to the index value to distinguish types and decide on an ordering.
The text was updated successfully, but these errors were encountered:
arv
added
the
Future
Something we want to fix but is not blocking next release
label
Jan 2, 2023
The obvious type to add support for is number. However, the ordering we use is UTF8 strings. How do we encode an arbitrary number in a way that we preserve the ordering? This paper looks promising: https://www.zanopha.com/docs/elen.pdf
There is also the issue of how to deal with the secondary key in scan
I'm not following. At the basic level we can clearly encode the number however we want and decode it to compare. Is the problem that you're trying to find a way that we can avoid that and compare as a string? That's an interesting problem. It seems similar to the fracdex problem?
The "value" is part of the key in the underlying B+Tree we use for the index.
To get scan to iterate over the keys in the correct order we need to have a mapping from number to string that preserves the numeric order. If it was only ints we could zero pad the number for example.
For scan we can pass the start key which is a tuple for index scans consisting of the [secondary: string, primary: string]. If the index is over numbers we would want to pass a number into secondary
This was just something we overlooked when first implementing. We would have to add some bits to the index value to distinguish types and decide on an ordering.
The text was updated successfully, but these errors were encountered: