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. • 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]. • The feature request reminds me of triggers what we envisioned for databases (but that were eventually discarded [2]).
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.
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.