> Jerome Velociter wrote: >> BTW, this reminds me this discussion http://tinyurl.com/587qqc we had on >> the Admin refactoring, on how to create the WebPreferences document for >> spaces that do not have it created. > > It's not quite the same, as in a wiki you can create spaces all the time, > and they don't have the > WebPreferences created at the same time (unless you write custom code for > this), but once you have > the new XWS version, all new wikis will have the new structure, right?
Yes, but I'm thinking about existing workspaces (the one that have been created before the upgrade). We want them to benefit from the new features too. So actually it is kind of the the same problem: adding to a space that does not belong to the original XAR (a space created by users use of the product) a new document (because the 'workspace template' has evolved with the upgrade). > >> Jerome. >> >>> Hello devs, >>> >>> I'm currently trying to find the best approach to automatically upgrade >>> an >>> XWS instance workspaces when upgrading the XWS version. By that, I mean >>> adding new pages to existing workspaces for example. >>> I see at least two possible approaches : >>> >>> * On display of the workspace, we check that the considered pages are >>> present, and if not either we automatically create them, either we >>> offer a >>> big button to "upgrade" the workspace. (the test could be done in a >>> skin >>> template, so that any page would trigger the upgrade) > > This is slow, as you have to make an upgrade check for each request. -0.5 Yes, I don't like it very much either. At the end, I think I will try hard to not need adding new documents. And if really I need to, I'll go the plugin way. Regards, Jerome. > >>> * On plugin init, we search for all workspaces and upgrade the ones in >>> need. And we could have a marker once the upgrade is done, not to >>> execute >>> the query at each init. > > Better, since it is a one-time check. You could add an XWSVersion class + > object in XWikiPreferences > to see if it was already upgraded or not. > >>> WDYT ? Are there other approaches I'm missing ? > > Could be done using a storage migrator. It isn't exactly a storage thing > from a semantic PoV, but i > think it qualifies. The advantage is that it is an already established > "framework" for upgrades, it > already has the notion of a "previous version", can execute any data > manipulation, so you will have > to write few code. The only problem is that currently migrators are > manually listed in > XWikiHibernateMigrationManager, so you won't be able to add your migrator > in there. But this is a > good opportunity to improve that code, too (maybe use components?) > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
