Module versioning for new packaging system
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'?
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:
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!
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> >
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.