note here if you read my script, the script DO NOT delete classes after the diff check to avoid data loss. Also the migration strategy of fields is destructive.
Hi @Moumouls, I was looking at how to integrate existing data migration tools with buildSchema().
Whenever buildSchema thinks to delete a field,
if buildSchema instead renamed the backing table/collection, and created a new one in it’s place,
then buildSchema would not have to be destructive.
Data migration scripts should run after Parse buildSchema() code has created/modified the tables or collections.
This could also be done in serverStartComplete.
If buildSchema() returned a promise for the number of tables it renamed, the migration code could .then() on that promise.
If serverStartComplete accepted an async function, who’se promise was used to open the API to outside connections, the whole thing could look like this:
const parseServer = new ParseServer({
allowClientClassCreation: false,
...otherOptions
// Parse has already been added to global
async serverStartComplete(error) {
const numMigrations = await Parse.buildSchema()
if (numMigrations) await myMigrationCode() // SQL or Mongojs to migrate data
return true // start accepting connections
}
If the Parse Javascript SDK could query the old data, migrations could be implemented as a stream of rows to be migrated, with migrations declared like this:
rowMigrations: {
classname: function (oldRow, newRow) => { /* modify newRow */ return true /* indicates complete */ },
otherclass: ()=>{},
}
This would allow the same migration code to work for Mongo and Postgres. Adding a “version” column to the Parse class would allow for versioned updates.
This migration stream may be out of scope for the SDK, but would be enabled by an Parse API to query the old table/collections.
What do you think?