+0 Thanks, Marius
On Thu, Dec 8, 2011 at 11:08 AM, Denis Gervalle <[email protected]> wrote: > Hi Devs, > > In order to change the way we compute document ID to reduce > the likelihood of a collision, I need to improve and secure our current > data migration system. I have started this works late during 3.2, but it > since this is an important refactoring, and after discussion on IRC, it > have been decide to wait for 3.4 to commit it, so we have a full cycle to > have it carefully test. So I would like your approval now to commit this > work. > > The advantages of these changes are: > > - Ensure that the hibernate store could not be access without having it > migrated in the appropriate version for the running platform > - Ensure that the hibernate store is left untouched if the migration have > not been allowed > - Easy addition of migrations, since migrator are now components > - Schema and datamigration are done only once and together > - One more step in the isolation of the store from XWiki > - Secure enough to allow converting document IDs > > The impact on API and users are: > > - deprecate xwiki.store.hibernate.updateschema which is enable by default > - xwiki.store.migration.databases=all by default (in place of xwiki) since > this is the general UC > - XWikiMigrationInterface and XWikiMigratorInterface are removed and new > component roles DataMigrationManager and DataMigration should be used > instead > > These improvements consist in: > > - Replace Migrators by DataMigration components > - Replace the MigrationManager by a DataMigrationManager component > - Put a "hibernate" hint on hibernate stores (in place of default) to > allow the hibernate migrator to access a correctly typed store > - inject and call the HibernateDataMigrationManager from the stores (and > not from XWiki) > - Convert data migration like action done during schema update (yes we > have some sql updates during schema update) into a LegacyDataMigration > producing data version 1 from data version 0 > - Join together schema update and data migration on a unique place (schema > update were currently done in several places in XWiki and the store) > - XWIKI-1859: Do not start migrations on a clean installation of XWiki > - XWIKI-2075: Move all databases upgrades and schema updates to XWiki's > initialization instead of doing it lazily (partial fix, since it is still > hard to have the store initialized has needed) > - data migration is moved to the first access to a store (which is still > during first request, but the matter is no more here) > - XWIKI-2066: Migrator fails to upgrade sub wiki databases, now properly > fixed (previous fix was a hack that do not) > - no more excessive synchronization required for schema update, but > there is still some mandatory document added lazily > - clear reporting of access error when migration does not succeed > > For more, read http://markmail.org/thread/l3dzx7pj32n5qlqd > > Here is my +1 > > -- > Denis Gervalle > SOFTEC sa - CEO > eGuilde sarl - CTO > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
