-
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
Fixes #946 #950
Fixes #946 #950
Conversation
Codecov Report
@@ Coverage Diff @@
## master #950 +/- ##
==========================================
+ Coverage 52.59% 52.74% +0.14%
==========================================
Files 179 180 +1
Lines 12707 12749 +42
==========================================
+ Hits 6683 6724 +41
- Misses 6024 6025 +1
Continue to review full report at Codecov.
|
Grouping was playing with us 😆 |
You can't remove grouping. Because it is stored with grouping and sorted with grouping in leveldb. |
The last fix was wrong. This will produce that contract destroy or other calls fail, we need to call neo/neo/SmartContract/InteropService.cs Line 540 in abda789
In fact, we should remove the grouping, is very confuse. |
Can you point out where it is wrong? |
The |
Is wrong because you need to pass the arguments in the unit test with the group ac85174#diff-a3f0e31debacd97d5d593e04923f7f99R53 But in other calls within the code, it was called without grouping. neo/neo/SmartContract/InteropService.cs Line 540 in abda789
|
I know it, but only in this case always will come from a storage (file). |
Only |
The only case that use neo/neo/SmartContract/InteropService.NEO.cs Lines 341 to 369 in abda789
And it has processed the group correctly. |
I understand you, but is very weird, if i use the class, and i insert 0x00, and i need to find it with |
I think you misunderstood. The first 20 bytes is the script hash. The last byte is the prefix. Your original unit test missed scripthash, I just added it for you. |
Now I catch you 😆 , i was thinking in the key, but |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@erikzhang, it looks great to me.
@shargon, I am trying to complete understand these UTs.
Can we take 1-2 more days to check it out? I want to talk with @igormcoelho about this sorting strategy.
return x.Length.CompareTo(y.Length); | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rodoufu can you review this?
if (pair.Value.State != TrackState.Deleted && (key_prefix == null || pair.Key.ToArray().Take(key_prefix.Length).SequenceEqual(key_prefix))) | ||
yield return new KeyValuePair<TKey, TValue>(pair.Key, pair.Value.Item); | ||
cached = dictionary | ||
.Where(p => p.Value.State != TrackState.Deleted && (key_prefix == null || p.Key.ToArray().Take(key_prefix.Length).SequenceEqual(key_prefix))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, must do it in a deserialized format, to avoid different storage formats affecting Find.
.OrderBy(p => p.KeyBytes, ByteArrayComparer.Default) | ||
.ToArray(); | ||
} | ||
var uncached = FindInternal(key_prefix ?? new byte[0]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this FindInternal implementation-specific? This is a good moment to avoid specific decisions affecting the outcome of Find.
p.Key, | ||
p.Value | ||
)); | ||
using (var e1 = cached.GetEnumerator()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this "intercalation" strategy should be done in a separate function, so it's clear and also testable (perhaps useful in other situations too).
Just to make sure, this sort is not considering Grouping anymore, just raw key, correct? Because grouping looks like an implementation-specific strategy, not a protocol level one. |
I optimized it, and now our grouping algorithm will not affect the sorting. |
@@ -92,17 +92,16 @@ public static byte[] ReadBytesWithGrouping(this BinaryReader reader) | |||
{ | |||
using (MemoryStream ms = new MemoryStream()) | |||
{ | |||
int padding = 0; | |||
int count; | |||
do | |||
{ | |||
byte[] group = reader.ReadBytes(GroupingSizeInBytes); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should reuse this buffer
byte[] group=new byte[GroupSizeInBytes];
do{
read.Read(group,0,GroupSizeInBytes);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
read.Read(group,0,GroupSizeInBytes);
This may read data less than GroupSizeInBytes
and use an extra loop, which is very troublesome.
Close #947
Close #946