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 devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

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 devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs