Basic approach to one off migration #2563
Conversation
|
This looks good. I am currently testing out the migration process to make sure the newly migrated channels work properly. Can we export this function from the node? I'd like to be able to import the function into a script we can call from the CLI. |
| @@ -15,6 +15,7 @@ import { | |||
| import { prettyPrintObject } from "./utils"; | |||
|
|
|||
| interface SharedData { | |||
| version: 1; // TODO: Add better versioning & migrations tooling | |||
There was a problem hiding this comment.
From looking around it seems like there are various ways of versioning a db schema.
Though I'm kinda confused as to why the version number is being put in SharedData? I'm also confused how this handles migrations overall if there are no typed schemas between the versions?
Maybe we should have a separate blob that holds both the version number and the schema at the corresponding version number. The migration script would then just diff n-1 and n to apply the migration.
There was a problem hiding this comment.
StoreData = { schemaVersion: number, data: SharedData } ?
This adds a basic migration script from all previous data schemas to the new one. There are only two major transformations from the previous pull requests. The first is that the data is now all stored under the key
${storeKeyPrefix}and the second is that some uses of{ _hex: string }to represent aBigNumberhave been changed tostring.