Module versioning for new packaging system
Thursday, 5 April 2012 · 5 messages · last reply 8 Apr 2012
CD
Charles Duffy5 Apr 2012 23:18 #
Howdy --
For the most part, I'm glad to have the non-EXPath packaging mechanism introduced for 7.2.1 -- particularly given how the EXPath implementation in BaseX has some unintended side effects (ie. loading all modules when only one is referenced).
However, I wonder if perhaps the current implementation could stand to be fleshed out a bit:
- No mechanism for atomically upgrading a module exists; it must be uninstalled, then installed again, leaving an intermediate period in which the module is unavailable.
- No mechanism for attaching a version to a module exists, making it impossible to determine whether an upgrade is necessary.
The combination of these two factors is particularly unfortunate -- meaning that uninstallation/reinstallation is necessary when there is any conceivable possibility that a module may have changed (given the lack of a version registry), but not providing any means of performing such reinstallation without possible service disruption.
With respect to versioning mechanism -- perhaps an optional pragma embedded in the module text, or an optional argument to 'REPO INSTALL'?
CG
Christian Grün6 Apr 2012 00:59 #
Quoted text · Charles Duffy · 5 lines
> For the most part, I'm glad to have the non-EXPath packaging mechanism introduced for 7.2.1 -- > [...] > - No mechanism for atomically upgrading a module exists; it must be > uninstalled, then installed again, leaving an intermediate period in which > the module is unavailable.
We could add a "force" flag to the "repo install" command; a "repo update" would be another alternative. Ideas?
Quoted text · Charles Duffy · 2 lines
> - No mechanism for attaching a version to a module exists, making it > impossible to determine whether an upgrade is necessary.
..this won't happen before the release of 7.2.1 or 7.3, because we'd have to invest more time (than currently available) in a clean concept.
Everyone: I have just added some Annotations to the QueryModule; this way, the permissions of functions and other properties can be fine tuned, and Java code can thus be better optimized by the XQuery processor:
http://docs.basex.org/wiki/Java_Bindings#Context-Awareness
CD
Charles Duffy6 Apr 2012 19:00 #
Quoted text · Christian Grün · 3 lines
On 04/05/2012 05:59 PM, Christian Grün wrote: > We could add a "force" flag to the "repo install" command; a "repo > update" would be another alternative. Ideas?
"Update" makes more sense to me than "force", simply on account of "force" being somewhat ambiguous as a term -- it could imply that other anomalous situations are to be ignored as well.
Quoted text · Christian Grün · 5 lines
>> - No mechanism for attaching a version to a module exists, making it >> impossible to determine whether an upgrade is necessary. > ..this won't happen before the release of 7.2.1 or 7.3, because we'd > have to invest more time (than currently available) in a clean > concept.
Makes sense to me. I'll plan on coming up with my own mechanism (say, a $version variable in each module) in the interim.
Quoted text · Christian Grün · 6 lines
> Everyone: I have just added some Annotations to the QueryModule; this > way, the permissions of functions and other properties can be fine > tuned, and Java code can thus be better optimized by the XQuery > processor: > > http://docs.basex.org/wiki/Java_Bindings#Context-Awareness
Nice!
JR
Jan Vlčinský (TamTam Research)8 Apr 2012 14:28 #
To me, "force" seems to have advantage, that it could be usable also for downgrade. Simply "put this version there, regardless of what is currently installed".
Jan
Quoted text · Christian Grün · 39 lines
On 6 April 2012 17:00, Charles Duffy <charles at dyfis.net> wrote: > On 04/05/2012 05:59 PM, Christian Grün wrote: > >> We could add a "force" flag to the "repo install" command; a "repo >> update" would be another alternative. Ideas? >> > > "Update" makes more sense to me than "force", simply on account of "force" > being somewhat ambiguous as a term -- it could imply that other anomalous > situations are to be ignored as well. > > > - No mechanism for attaching a version to a module exists, making it >>> impossible to determine whether an upgrade is necessary. >>> >> ..this won't happen before the release of 7.2.1 or 7.3, because we'd >> have to invest more time (than currently available) in a clean >> concept. >> > Makes sense to me. I'll plan on coming up with my own mechanism (say, a > $version variable in each module) in the interim. > > > Everyone: I have just added some Annotations to the QueryModule; this >> way, the permissions of functions and other properties can be fine >> tuned, and Java code can thus be better optimized by the XQuery >> processor: >> >> http://docs.basex.org/wiki/**Java_Bindings#Context-**Awareness<http://docs.basex.org/wiki/Java_Bindings#Context-Awareness> >> > > Nice! > > > ______________________________**_________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-**konstanz.de <BaseX-Talk at mailman.uni-konstanz.de> > https://mailman.uni-konstanz.**de/mailman/listinfo/basex-talk<https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk> >
CG
Christian Grün8 Apr 2012 18:18 #
Jan, Charles,
thanks for your feedback. I have decided to replace existing packages in the repository instead of throwing an error -- mostly because most other BaseX operations also replace existing components without further complaints (think of the creation or export of databases, writing files via file:wite(), etc.). The "repo list" command can be used to check if a package already exists.
Some more details: the behavior of the "repo delete" command was now aligned with Florent George's xrepo tool: you can suffix the name of a package with its version number to delete a specific version. Next, the latest version of a package will be imported if more than several versions have been installed.
Christian
Quoted text · Jan Vlčinský (TamTam Research) · 56 lines
On Sun, Apr 8, 2012 at 2:28 PM, Jan Vlčinský (TamTam Research) <jan.vlcinsky at tamtamresearch.com> wrote: > To me, "force" seems to have advantage, that it could be usable also for > downgrade. Simply "put this version there, regardless of what is currently > installed". > > Jan > > > On 6 April 2012 17:00, Charles Duffy <charles at dyfis.net> wrote: >> >> On 04/05/2012 05:59 PM, Christian Grün wrote: >>> >>> We could add a "force" flag to the "repo install" command; a "repo >>> update" would be another alternative. Ideas? >> >> >> "Update" makes more sense to me than "force", simply on account of "force" >> being somewhat ambiguous as a term -- it could imply that other anomalous >> situations are to be ignored as well. >> >> >>>> - No mechanism for attaching a version to a module exists, making it >>>> impossible to determine whether an upgrade is necessary. >>> >>> ..this won't happen before the release of 7.2.1 or 7.3, because we'd >>> have to invest more time (than currently available) in a clean >>> concept. >> >> Makes sense to me. I'll plan on coming up with my own mechanism (say, a >> $version variable in each module) in the interim. >> >> >>> Everyone: I have just added some Annotations to the QueryModule; this >>> way, the permissions of functions and other properties can be fine >>> tuned, and Java code can thus be better optimized by the XQuery >>> processor: >>> >>> http://docs.basex.org/wiki/Java_Bindings#Context-Awareness >> >> >> Nice! >> >> >> _______________________________________________ >> BaseX-Talk mailing list >> BaseX-Talk at mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >
Written for BaseX 7.2. BaseX may have changed since: please check the current documentation.
⚡Generated with XQuery