Phase 2 data migration will cover cases that Persistence can't handle in a completely automatic way. The idea is to put the onus on the dev to create migration scripts, which Persistence can manage and auto-apply for admins.
Persistence will maintain a special MigrationStep global entity for this, which tracks each migration script that's been applied.
Admins will drop a script in the Persistence folder with the server shut down (during a plugin upgrade). On startup, Persistence will execute this script, mark it as having been completed. and then move the physical file to a separate "completed" folder.
There needs to be some way to uniquely identify migration scripts- this gets complex, since they need to be globally unique, across all plugins and all changes. We made need to have Persistence auto-generate a template or something.
The actual id could either be the filename, or embedded in a comment on the first line of the script.
Phase 2 data migration will cover cases that Persistence can't handle in a completely automatic way. The idea is to put the onus on the dev to create migration scripts, which Persistence can manage and auto-apply for admins.
Persistence will maintain a special MigrationStep global entity for this, which tracks each migration script that's been applied.
Admins will drop a script in the Persistence folder with the server shut down (during a plugin upgrade). On startup, Persistence will execute this script, mark it as having been completed. and then move the physical file to a separate "completed" folder.
There needs to be some way to uniquely identify migration scripts- this gets complex, since they need to be globally unique, across all plugins and all changes. We made need to have Persistence auto-generate a template or something.
The actual id could either be the filename, or embedded in a comment on the first line of the script.