| 54 | | For the IEnvironmentSetupParticipant there is currently talk about a best practice to always commit changes to the database when upgrading using a migration path, so that on error during the migration, the existing data will not be corrupted. This basically involves atomic changes to the database, so that either all or none of the changes being applied will be committed. This also includes incrementally updating the system property ''database_version'', e.g. for each update available the version will be incremented by one. For your plugins this basically means that you should not try to upgrade the database and your data model schema thereof in just a single transaction, but allow the system to fail, and if it does, gracefully provide the user with the chance of upgrading your data model schema to its newest version. |
| | 54 | For the IEnvironmentSetupParticipant there is currently talk about a best practice to always commit changes to the database when upgrading using a migration path, so that on error during the migration, the existing data will not be corrupted. This basically involves atomic changes to the database, so that either all or none of the changes being applied will be committed. This also includes incrementally updating the system property ''database_version'', e.g. for each update available the version will be incremented by one. For your plugins this basically means that you should not try to upgrade the database and your data model schema thereof in just a single transaction, but allow the system to fail, and if it does, gracefully provide the user with the chance of reverting back to the original state. As of now, prior to each update to the database, a copy of the existing database will be created, at least for SQLite based backends. When using PostgreSQL or other supported backends, this will require extra effort by the user in order to be able to revert to a working version of the database before the failed upgrade attempt. |
