Well, I guess that if a XAR extension needs to migrate its data, it will have to depend on some jar extension that will have the migration code and that will be its only purpose.
Thanks, Eduard On Mon, Apr 25, 2016 at 3:46 PM, Thomas Mortagne <[email protected]> wrote: > On Mon, Apr 25, 2016 at 12:10 PM, Eduard Moraru <[email protected]> > wrote: > > On Fri, Apr 22, 2016 at 8:08 PM, Thomas Mortagne < > [email protected]> > > wrote: > > > >> On Fri, Apr 22, 2016 at 5:59 PM, Clemens Klein-Robbenhaar > >> <[email protected]> wrote: > >> > > >> >> On Fri, Apr 22, 2016 at 5:34 PM, Thomas Mortagne > >> >> <[email protected]> wrote: > >> >>> Sounds good. > >> >>> > >> >>> What about upgrades, do you plan to provide a migrator ? > >> >> > >> >> (I would love to see my old calendars converted to new style ;)) > >> >> > >> > > >> > I have to check out the > >> > http://extensions.xwiki.org/xwiki/bin/view/Extension/Nested+Pages+Migrator+Application > >> > and see how it works / if it can be adapted to nested pages, etc. > >> > > >> > I guess this will be a separate application / helper etc in any case, > or > >> is there a way to trigger the migration when installing a newer version? > >> > >> There is an ExtensionUpgradedEvent event that an extension can listen > >> to be called after it's upgraded. > >> > > > > Cool! Did not know about that. So we can have per-extension migration > > scripts, which would kind of superseed the XWiki migration framework > (that > > work with the XWiki DB version) and we would only be still using that for > > core changes. Right now we use the XWiki DB version even for bundled app > > migrations. > > > > I guess we should document that somewhere and make it a best practice (if > > not already). > > It's OK in Java but impossible to use that in a XAR extension that > might be installed without programming right (since wiki component > require PR). > > > > > Thanks, > > Eduard > > > >> > >> > > >> > No deadline for this in my scedule yet, however .... > >> > > >> > > >> >>> > >> >>> On Fri, Apr 22, 2016 at 5:31 PM, Clemens Klein-Robbenhaar > >> >>> <[email protected]> wrote: > >> >>>> > >> >>>> I see there has been some discussion on the list, as far as I > >> understand there is no decision about it in general. > >> >>>> > >> >>>> However I would like to drop support for pre-nested pages for the > >> mocca calendar on the master branch right now. > >> >>>> > >> >>>> The pre-nested spaces structure is: > >> >>>> > >> >>>> - Calendars are plain pages > >> >>>> - Events are pages that have their calendar as parent page, but > are > >> usually placed as siblings in the same space > >> >>>> (necessarily w/o nested pages) > >> >>>> > >> >>>> It is more natural to have calendars as nestable, non-terminal > pages, > >> and the corresponding events nested inside these calendar pages. > >> >>>> > >> >>>> Bugs that would be easy to solve after dropping support: > >> >>>> > >> >>>> http://jira.xwiki.org/browse/MOCCACAL-91 "Cannot create two > events > >> with the same title in the same calendar " > >> >>>> This has been fixed in 2.5.1 for pre-nested pages, but that fix > >> does not work for nested pages. > >> >>>> Admittedly it could also be fixed with an if (nested space) do > x > >> else y > >> >>>> I have to admit that I am reluctant to implement the if-else > fork > >> and fully test it (If I do not test both nested and pre-nested spaces it > >> will be broken with high probability) > >> >>>> In some places there are already horrible if-else clauses to > >> support both colibri and flamingo, which I put there and the experience > >> makes me unwilling to try this again with nested spaces. > >> >>>> > >> >>>> http://jira.xwiki.org/browse/MOCCACAL-93 "Preinstalled "Other > >> Events" Calendar should not be a terminal page" > >> >>>> This actually can not be fixed in a pre-nested spaces compatible > >> way (I think) > >> >> > >> >> Another great feature of nested space based calendar: you can watch a > >> >> single calendar just by watching its page instead of having to watch > >> >> eveything. > >> >> > >> >>>> > >> >>>> > >> >>>> Proposal: > >> >>>> a) there is already a "stable-2.5" branch. > >> >>>> all fixes and improvements for pre-nested spaces will/should go > >> on this branch > >> >>>> b) master will switch its xwiki platform dependency from 5.4 to > 7.4.2 > >> >>>> (not 7.2 for me, because 7.4.2 is what I am willing to test > >> against ... any takers to test with 7.2 ?) > >> >>>> c) for now, the old "parent-child" relationship will still be used > >> to determine which events belong to which calendar > >> >>>> so no migration from pre-nested spaces is really necessary - at > >> least I think so. Of course this should be tested. > >> >>>> (It would be nice to have such migration, of course. I am not > >> sure how to write this, however.) > >> >>>> > >> >>>> > >> >>>> Any opinions? Should I send an official [vote] request? > >> >>>> > >> >>>> Clemens > >> >>>> _______________________________________________ > >> >>>> devs mailing list > >> >>>> [email protected] > >> >>>> http://lists.xwiki.org/mailman/listinfo/devs > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> Thomas Mortagne > >> >> > >> >> > >> >> > >> > > >> > mit freundlichen Grüßen > >> > Clemens Klein-Robbenhaar > >> > > >> > -- > >> > Clemens Klein-Robbenhaar > >> > Software Development > >> > EsPresto AG > >> > Breite Str. 30-31 > >> > 10178 Berlin/Germany > >> > Tel: +49.(0)30.90 226.763 > >> > Fax: +49.(0)30.90 226.760 > >> > [email protected] > >> > www.espresto.de > >> > > >> > HRB 77554 B - Berlin-Charlottenburg > >> > Vorstand: Maya Biersack, Peter Biersack > >> > Vorsitzender des Aufsichtsrats: Dipl.-Wirtsch.-Ing. Winfried Weber > >> > Zertifiziert nach ISO 9001:2008 > >> > _______________________________________________ > >> > 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 > >> > > _______________________________________________ > > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
