Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3847 +/- ##
==========================================
+ Coverage 82.46% 82.59% +0.13%
==========================================
Files 341 341
Lines 47740 47876 +136
==========================================
+ Hits 39368 39545 +177
+ Misses 6740 6695 -45
- Partials 1632 1636 +4 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
f19e0cb to
3e76d3b
Compare
roman-khimov
left a comment
There was a problem hiding this comment.
Dependency updates (SDK RC13 for sure)?
Regarding iter.Seq --- OK, I've not tried that, maybe it doesn't really fit for our use case.
Regarding unique --- looks like I've misinterpreted it originally, but it's hard to tell what can be improved by using it. Verification scripts look promising, but they're []byte.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
25251f0 to
7ccd764
Compare
|
48e2e81 to
0e5c72a
Compare
Everything except golang.org/x/* packages is upgradedto the latest version. golang.org/x/* packages upgrade introduces toolchain dependency, hence we'll postpone the update till the next Go version bump. Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
50d94ef to
a347353
Compare
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
|
Tests should be fine now, let's wait for the jobs to finish before the merge. |
Close #3553.
Regarding this: I tried and I'm not sure how can we apply these changes to our storage. We have a pattern like https://go.dev/blog/range-functions in our memcached storage, but it interacts with DB-level
Seekfunctions, so to me it looks like we can't really use range there. We also have a similar pattern in our interop-level storage package (storage iterator), but I don't see how can we improve it given the existing iterator API that is exposed from this package. May be I'm just don't understand something, so I need some help here.For things like this we already declare global
big.NewInt(0)variable at the package level in most of the packages and reuse this single variable. Dose it worth changing this pattern? To me it looks like the example they give in https://go.dev/blog/unique refers to a bit different usage scenario ofunique.