feat(backend): User data migration #1967
Conversation
bitdivine
force-pushed
the
data-upload-download-apis
branch
from
bd92b41
to
27e6a38
Compare
bitdivine
changed the title
| pub async fn step_migration() { | ||
| /// The next chunk of user tokens to be migrated. | ||
| fn next_user_token_chunk(last_user_token: Option<Principal>) -> Vec<(Principal, Vec<UserToken>)> { | ||
| let chunk_size = 5; |
There was a problem hiding this comment.
This is a very small chunk size. Will this be increase / made configurable in the future?
There was a problem hiding this comment.
Oisy doesn't have many users. In future I expect this code to be gone, at which point all the migration code that exists will be infinitely configurable. 😉
| /// | ||
| /// # Errors | ||
| /// - Throws a `MigrationError::DataMigrationFailed` if the data transfer fails. | ||
| macro_rules! migrate { |
There was a problem hiding this comment.
Interesting. I would have approached that using generics, but this is probably cleaner. 👍
There was a problem hiding this comment.
I think generics are easier to debug than macros and more familiar to most people. So I tend to avoid macros where possible. But I am not sure it is possible to pass say $chunk_variant in a generic function, so I think this is the only option. I didn't spend a long time deciding though; I could be wrong.
Motivation
We would like to migrate user data to a new canister. The groundwork for the migration code is already in place. Now we need the actual migration code.
Changes
Tests
A
pocket-ictest is included that exercises the migration from end to end. The main difference from production code is that thepocket-iccode steps explicitly whereas normally the migration is driven by a timer.