-
Notifications
You must be signed in to change notification settings - Fork 138
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
Also migrate path-capability and account-capability storage maps #3411
Conversation
Cadence Benchstat comparisonThis branch with compared with the base branch onflow:master commit 145dea1 Collapsed results for better readability
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3411 +/- ##
==========================================
- Coverage 80.42% 80.39% -0.03%
==========================================
Files 389 390 +1
Lines 95654 95790 +136
==========================================
+ Hits 76930 77013 +83
- Misses 16006 16058 +52
- Partials 2718 2719 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Related to onflow/flow-go#6069
Description
For completeness, also migrate the path-capability and the account-capability storage map.
The path-capability storage maps record all storage capability IDs for a storage path. The storage maps have strings as keys (the identifier of the storage path, e.g.
foo
in/storage/foo
), and the values are Cadence dictionaries, which are rather sets, where the keys are the capability IDs (UInt64
) and the values are always Cadencenil
values.The account-capability storage maps record all account capability IDs for an account. The storage maps have uint64 keys (the capability IDs), and the values are always Cadence
nil
values. The storage maps are rather sets.AFAIK we currently do not have migrations required for Cadence 1.0 that migrate such values (dictionaries and
UInt64
values), but still migrate these storage maps for completeness / correctness – the assumption we do not have migrations for such values might not hold in the future.Kudos to @fxamacker for noticing this omission. In the Cadence 1.0 migrations it is not important, but in the atree inlining migrations all values need to be migrated, so it is important there. See related issue.
master
branchFiles changed
in the Github PR explorer