Re: [xwiki-devs] [VOTE] Improving the migration manager to fix XWIKI-7006, XWIKI-1859, XWIKI-2075, XWIKI-2066

Hi devs, I need to do XWIKI-6990 (Reduce the likelihood of having same (hibernate) document id for different documents), but XWIKI-7006 (Accessing a store that is not migrated to the lastest data version should not be allowed) is blocking for this to be safely introduced. So I have refactored the migration code to better protect the database, I would like your vote to introduce this patch first, another vote will come for XWIKI-6990. The proposed commit is available at https://github.com/dgervalle/xwiki-platform/commit/f1fa1b1357d17c1ee4ed65eb… In summary, here is what it does:  a) Refactor the old XWikiMigrationInterface and XWikiMigratorInterface into new DataMigrationManager and DataMigration interfaces  b) Implement the DataMigrationManager and the DataMigration interfaces using components for the hibernate stores  c) Remove the migration check from XWiki and put them in hibernate stores components, freeing this from XWiki. Since store still use the XWikiContext, I still use it, but from the execution context, no more passing it everywhere.  d) Use a cache for DB version to not degrade performance  e) Remove many call to schemaUpdate which require synchronization, executing only schema updates during data migrations.  f) Remove some data migration like code from schemaUpdate, convert it to HQL (in place of native SQL :() and put them in an initial LegacyDataMigration, that migrate from version 0 to version 1  g) Fix empty/new database issue by considering a database without version AND without documents as a new database, and initialize it with the current schema and the latest version.  h) Properly report migration failure and prevent access on failure  i) Prevent access to any database not being properly migrated to the latest version by never providing a valid transaction for it. By the way, fix another (unnoticed ?) bug: if a throw occurs during database switching, a transaction could be return and used improperly (mixing data from different database).  j) deprecate xwiki.store.hibernate.updateschema, but use "1".equals(config.getProperty("xwiki.store.migration", "0") && !"0".equals(config.getProperty("xwiki.store.hibernate.updateschema") to enable migrations  k) Now xwiki.store.migration.databases=all, before it was xwiki only, which is not right IMO Currently, migration manager is injected in stores, using a hint, since the migration manager will be different depending on the store that keep the data version. The migration manager lookup the store by hint to retrieve the data version. The migration manager lookup data migrations using hint as well. Finally, data migrations lookup stores again using hint. Some improvements would be to allow multiple data versions (one per store hint), and mix data migration, since stores could be mixed, but this is out of my scope currently. To support injecting store by scope properly, there is another separate commit, available at https://github.com/dgervalle/xwiki-platform/commit/6a353d6d45bfb73789ed0693…, which replace the default unnamed stores, by "hibernate" named stores. Since store are still initialized at XWiki initialization, migration still occurs during first request to the system, but this is no more related to the migration system, which intercept the first database access, but this is related to this XWiki initialization only now. So XWIKI-2075 is fixed for me. I have already work hard to reach this state, there is still room for improvements, but I will not be able to afford much more time on this right now (at least without a sponsor :)). Please be fair in your remarks ;) Here is my +1. Currently the patch is done for 3.3, but if you think it could go in 3.2, I am +1.

-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs