Edgewall Software

Changes between Version 18 and Version 19 of TracDev/PluginDevelopment/ExtensionPoints/trac.env.IEnvironmentSetupParticipant

Mar 27, 2017, 8:25:33 AM (6 years ago)
Ryan J Ollos

See comment:45:ticket:8172.


  • TracDev/PluginDevelopment/ExtensionPoints/trac.env.IEnvironmentSetupParticipant

    v18 v19  
    9494    def upgrade_environment(self):
    9595        dbm = DatabaseManager(self.env)
    96         if dbm.get_database_version(PLUGIN_NAME) == 0:
    97             dbm.create_tables(PLUGIN_SCHEMA)
    98             dbm.insert_into_tables(INITIAL_PLUGIN_DATA)
    99             dbm.set_database_version(PLUGIN_VERSION, PLUGIN_NAME)
    100         else:
    101             dbm.upgrade(PLUGIN_VERSION, PLUGIN_NAME, 'example.upgrades')
     96        with self.env.db_transaction:
     97            if dbm.get_database_version(PLUGIN_NAME) == 0:
     98                dbm.create_tables(PLUGIN_SCHEMA)
     99                dbm.insert_into_tables(INITIAL_PLUGIN_DATA)
     100                dbm.set_database_version(PLUGIN_VERSION, PLUGIN_NAME)
     101            else:
     102                dbm.upgrade(PLUGIN_VERSION, PLUGIN_NAME, 'example.upgrades')
    103104* `setup.py`
    120121 * Preventing data corruption on upgrade[[br]]
    121    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.
     122   Multiple operations should be put in a transaction context manager, as shown in the example, to ensure that all the operations are atomic.
    123124 * On upgrade the existing help pages in the wiki will not be updated[[br]]