-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Storage.Find returns items out of order #946
Comments
this could be a problem in other implementations (neo-python) |
@ixje, maybe it is as Shargon said, I will double check asap. In general, I have been in seen in other communities that tags do not go in the tittle. |
I just double checked my output from the previous thread and it was out of order as you said, @ixje. Should this be adjusted or modified for Neo2X, @shargon and @igormcoelho? In fact, sometime ago I remember this discussion with @igormcoelho. |
Order should be fully deterministic, otherwise it's hard (or impossible) to reproduce the results.
I prefer option (2), if feasible, because key order is not easy to track in MPT or other data structures. So, sorting becomes the simplest solution I can see, at possibly big performance costs. |
@igormcoelho I prefer option 2 too. Can't we store it ordered and just retrieve it? I think it makes more sense to sort it when we update it. What do you think? |
I prefer sorted |
* reorg * fix links
Say we store the following values
The following code
returns
AA_1
,AA_2
,AA_3
as expected.Now add a
Storage_Get
before theFind
call, like so:and the iterator now returns:
AA_2
,AA_3
,AA_1
This is caused by line 126 of
neo/neo/IO/Caching/DataCache.cs
Lines 121 to 132 in 00f9c27
When the key is already found in its cache it actually skips it for the time being instead of immediate processing (checking if
DELETED
).I think this is unexpected behaviour. I do not think that possible data caching needs to be taken into account by the smart contract programmer. Any opinions?
The text was updated successfully, but these errors were encountered: