Honestly currently i have no idea about how we can support this feature efficiently.
Currently on all of my project i tried to avoid field type migration:
- Need to write/test a one time script (high cost for low business value)
- Can be dangerous if not well tested, can lead to data loss
- At a given time the database is not consistent, the upgrade need to introduce a maintenance page to avoid unwanted service degradation
- If migration fail, data inconsistency is some time really hard to solve
Solution that i use:
- Create a new field
- Perform dynamic migration on beforeSave/AfterFind triggers (easy to test/implement)
- Front end use GraphQL to support the new field and fall back to the old one if needed (thanks to the afterFindTrigger you can perform migration easly on data pulled out from the DB)
- After a while run a Parse.Cloud.Job to migrate last inactive content
- Check in the front end that the old field is now not used (easy to track with GraphQL)
- Remove the field
On my side today i prefer to follow the deprecated strategy with a beforeSave/afterFind triggered migration to avoid inconsistency, data loss, performance, continuous delivery behavior.
Thanks to GraphQL it’s now super easy to notify front end teams and all client apps about deprecated fields (need a custom overloaded schema to add deprecated message on parse server currently we should add the support on Parse Schema field )