3 +1, 1 +0, no -1. I will commit... Denis
On Thu, Dec 8, 2011 at 14:05, Marius Dumitru Florea < [email protected]> wrote: > +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 > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
