[xwiki-devs] Automatically migrating/adding wiki documents upon upgrade
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) * 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. WDYT ? Are there other approaches I'm missing ? Regards, Jerome.
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. 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)
* 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.
WDYT ? Are there other approaches I'm missing ?
Regards, Jerome.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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?
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
* 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/
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
The good solution for this is to have an application manager component with the following features: * Install/Uninstall/Upgrade applications * Manage dependencies/prereqs between apps and with core runtime * Download updates from a remote repo (the first implementation should be done with a maven remote repo) (since you need some info about the latest released version, etc and this exists in a maven repo) * Supports installing not only pages but also jars, skin extensions/ interface extensions. This app manager would replace both the packager code in core and the current app manager plugin/application. What this means in practice is that your pages/extensions/plugins/etc (in XE, XWS or others) would be split into applications managed by this app manager. So when we update these apps we deploy them in the remote repo and all users get notifications of new apps through the app manager. Right now everyone is already busy: new rendering, new wysiwyg, new administration. What I'd like to do (in this order): 1) new rendering refactoring (for Sept) 2) new model and new related components 3) new storage and new query components 4) new app manager What this means is that I don't foresee the new app manager to be ready before next year (and probably more likely to be middle/end of the year). What it also means is that in the meantime you have 2 solutions: 1) make upgrades manual and list in the release notes the list of pages changed/added/removed and let admins update their installs accordingly 2) develop something ad hoc (something like what you propose I guess) with the knowledge that it'll be thrown away in the future and replaced by the app manager. WDYT? Thanks -Vincent On Jun 13, 2008, at 10:44 AM, Jerome Velociter wrote:
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)
* 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.
WDYT ? Are there other approaches I'm missing ?
Regards, Jerome.
The good solution for this is to have an application manager component with the following features:
* Install/Uninstall/Upgrade applications * Manage dependencies/prereqs between apps and with core runtime * Download updates from a remote repo (the first implementation should be done with a maven remote repo) (since you need some info about the latest released version, etc and this exists in a maven repo) * Supports installing not only pages but also jars, skin extensions/ interface extensions.
This app manager would replace both the packager code in core and the current app manager plugin/application.
What this means in practice is that your pages/extensions/plugins/etc (in XE, XWS or others) would be split into applications managed by this app manager. So when we update these apps we deploy them in the remote repo and all users get notifications of new apps through the app manager.
Right now everyone is already busy: new rendering, new wysiwyg, new administration. What I'd like to do (in this order): 1) new rendering refactoring (for Sept) 2) new model and new related components 3) new storage and new query components 4) new app manager
What this means is that I don't foresee the new app manager to be ready before next year (and probably more likely to be middle/end of the year).
What it also means is that in the meantime you have 2 solutions: 1) make upgrades manual and list in the release notes the list of pages changed/added/removed and let admins update their installs accordingly 2) develop something ad hoc (something like what you propose I guess) with the knowledge that it'll be thrown away in the future and replaced by the app manager.
WDYT?
Yes I cannot agree more : a proper application manager is the way to go :) As for now, I think I will first try to not have this need, and if I really have to, I'll do some ad hoc upgrading code, as solution 1) is not applicable for my use case (upgrading tenth or more of workspaces -the space abstraction, not the product itself- that is, adding new documents in N existing spaces). Jerome.
Thanks -Vincent
On Jun 13, 2008, at 10:44 AM, Jerome Velociter wrote:
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)
* 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.
WDYT ? Are there other approaches I'm missing ?
Regards, Jerome.
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (3)
-
Jerome Velociter -
Sergiu Dumitriu -
Vincent Massol