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
Unless I'm missing something pretty sure this is a low level bug in the sorting order. Note that this only happens when numbers and letters are mixed in the key, if its all numbers or all letters then it prints it out alphabetically.
Ethan Frey: this is odd but expected behavior.
if the items are all the same length (like Addr) or binary encoded (like u64), then they will be sorted properly.
However, stings and byte slices are all length prefix encoded, so shortest goes first... but only in prefixes.
this was needed to properly separate prefixes from suffixes, but you hit a case where it doesn't work as the user would assume and should be documented
The text was updated successfully, but these errors were encountered:
Per CosmWasm Discord, question and answer between me and @ethanfrey
Question:
Hello devs
I am working in the storage-plus repo and I found what I believe is a weird bug with IndexedMap/storage
If I put the following pk key data into an IndexedMap:
then do a simple range order Ascending with no prefix I get
now if I change "zing" to "zing1" then do a range I get
Unless I'm missing something pretty sure this is a low level bug in the sorting order. Note that this only happens when numbers and letters are mixed in the key, if its all numbers or all letters then it prints it out alphabetically.
What I'm doing here is a modified version of the test here:
https://github.com/CosmWasm/cw-plus/blob/main/packages/storage-plus/src/indexed_map.rs#L1069
Answer:
Ethan Frey: this is odd but expected behavior.
if the items are all the same length (like Addr) or binary encoded (like u64), then they will be sorted properly.
However, stings and byte slices are all length prefix encoded, so shortest goes first... but only in prefixes.
this was needed to properly separate prefixes from suffixes, but you hit a case where it doesn't work as the user would assume and should be documented
The text was updated successfully, but these errors were encountered: