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:
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:
http://docs.basex.org/wiki/**Java_Bindings#Context-**Awarenesshttp://docs.basex.org/wiki/Java_Bindings#Context-Awareness
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-talkhttps://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
basex-talk@mailman.uni-konstanz.de
-
Charles Duffy -
Christian Grün -
Jan Vlčinský (TamTam Research)