fix Storage.Find
#200
fix Storage.Find
#200
Conversation
|
@RavenXce Can you review this? |
|
I don't think this will work. As mentioned in the edit, the additional size prefix in By constructing the StorageKey with only the prefix, the calculated key size will never match the actual keys which will always have a longer length. E.g. searching for prefix of However previously, And with this change, So I managed to make it work only because all the keys I'm iterating over have a same known length, and so I can prepend the full key size as bytes directly. Test code: |
|
You are right, it won't work.. |
|
We can group key data and add a flag to each group that indicates whether it is the last group. |
|
@RavenXce Will this work? Please review again. |
| ms.Write(prefix, index, remain); | ||
| prefix_key = context.ScriptHash.ToArray().Concat(ms.ToArray()).ToArray(); | ||
| } | ||
| StorageIterator iterator = new StorageIterator(Storages.Find(prefix_key).Where(p => p.Key.Key.Take(prefix.Length).SequenceEqual(prefix)).GetEnumerator()); |
There was a problem hiding this comment.
Is the Where part necessary? Since the prefix does not write any additional padding now
There was a problem hiding this comment.
Yes, it's necessary. Think of this, if the key is 0x112233, the padded key is 0x11223300000000000000000000000000. Then we find with the prefix 0x11223300. This should find nothing. But if we don't have the Where part, it will match the padded key and return wrong results.
fix #199