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'?
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?
- 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
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:
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 On 6 April 2012 17:00, Charles Duffy <charles@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:
Nice!
______________________________**_________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-**konstanz.de <BaseX-Talk@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 ______________________________ On Sun, Apr 8, 2012 at 2:28 PM, Jan Vlčinský (TamTam Research) <jan.vlcinsky@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@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:
Nice!
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
participants (3)
-
Charles Duffy -
Christian Grün -
Jan Vlčinský (TamTam Research)