Skip to content
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

11-to-12: Re-work logic to use the backup file for both migrate and revert #150

Merged
merged 7 commits into from
Feb 15, 2022

Conversation

hsanjuan
Copy link
Contributor

Before: we Query all keys and write a backup file. Then Query all keys and
perform the swaps. This may cause that our query keeps getting results for all
the keys that we are writing while we run it.

After: we perform a Prepare() step where we query all the keys and write the
backup file. Then we read the backup file to perform the swaps without making
another query.

This also means that the migration (swapper.Run()) becomes very similar to the
revert (swapper.Revert()), since both read from the backup file. We are thus
able to refactor code and re-use logic better.

We have also tuned down the noise when encountering multihashes that are not
CIDv0s.

aschmahmann and others added 6 commits January 14, 2022 13:40
Avoid that there is confusion about the unit used.
…evert

Before: we Query all keys and write a backup file. Then Query all keys and
perform the swaps. This may cause that our query keeps getting results for all
the keys that we are writing while we run it.

After: we perform a Prepare() step where we query all the keys and write the
backup file. Then we read the backup file to perform the swaps without making
another query.

This also means that the migration (swapper.Run()) becomes very similar to the
revert (swapper.Revert()), since both read from the backup file. We are thus
able to refactor code and re-use logic better.

We have also tuned down the noise when encountering multihashes that are not
CIDv0s.
@hsanjuan
Copy link
Contributor Author

@aschmahmann this is a follow up to #149 . It addresses issues we discussed:

  • Do not log errors when encountering blocks that are not CIDv1s nor CIDv0s (potentially raw multihashes with different non-sha256 codecs)
  • Use the backup file rather than an ongoing query to perform the migration, similar to how the reverts work.

@BigLep
Copy link
Contributor

BigLep commented Jan 25, 2022

2022-01-25 discussion: @aschmahmann is going to review and also add some more tests.

@aschmahmann
Copy link
Contributor

Talking this through with @hsanjuan this seems to be a pretty reasonable and fairly low risk approach we've done some local testing on. We can do this instead of #151

@aschmahmann aschmahmann merged commit 9dcf004 into master Feb 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants