Inlined ...
On 22/05/24 13:00, Christian Grün wrote:
Hi Marco,
Thanks for your suggestion. Some thoughts:
• Function items can depend on the currently evaluated code and its static and dynamic context, but we could possibly design something similar as for the Job Module, in which the query is passed on as a string or a URI reference and evaluated completely independently.
Yes!
• Registered observers could be handled similarly as „services”, i.e., made persistent, end up in the same query pool, discarded by user requests, gracefully shut down when a server stops, etc. [1].
Yes!
• The feature request reminds me of triggers what we envisioned for databases (but that were eventually discarded [2]).
I remember. But IMO this could have much less implications and hidden complexity compared to a full-blown DB trigger mechanism.
Having said this, it could take a while to make this happen as it’s a non-trivial request :) I’d like to hear about suggestions of other readers.
I was not even expecting for this "loud thought" to be promoted so quickly to "feature request" :-) ... Thus thank you!
Apart from that, we are always interested in feedback on the Store Module; it’s still fairly new, but more and more people seem to discover it.
Ciao, Christian
[1] https://docs.basex.org/wiki/Job_Module#Services [2] https://github.com/BaseXdb/basex/issues/1082
On Wed, May 22, 2024 at 9:49 AM Marco Lettere m.lettere@gmail.com wrote:
Dear Christian and BaseX developers, just wondering if adding something like the following would be hard to implement. /store:observe($key as xs:string, $observers as function(*)*) / with $observers being something like /function($key as xs:string)./ The semantics is to call the registered observers whenever a value associated with the key in the store changes (put, remove, clear, ..). This would allow for nicely decoupled observer - notification pattern. Does it make sense? Regards, Marco.