On Tue, Oct 4, 2011 at 5:10 PM, Denis Gervalle <[email protected]> wrote: > 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/f1fa1b1357d17c1ee4ed65eb2cc7f2867ddb3762 > > 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/6a353d6d45bfb73789ed0693af92a8ce96cd441e, > 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.
Generally sounds good and I trust you made a bunch of tests on it but I would limit it to 3.3 since it's pretty serious change for 3.2 which is in RC phase. Lets say I'm +1 for 3.3 and -0 for 3.2. Great work ! > > -- > Denis Gervalle > SOFTEC sa - CEO > eGuilde sarl - CTO > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
