Re: [basex-talk] Making store reactive

2024-05-22 Thread Zimmel, Daniel
Nothing substantial to contribute right now to the discussion, but since you 
asked for feedback: I really like the Store Module for its ease of use and 
access. It is fast, reliable, flexible and short.
With my main use case, when running a handful of updating queries in a row, 
accessing a map structure I initially collected and put in the store is so much 
better than having to use intermediate custom XML indexes (that is what I did 
before, but if I like, I can even put those in the store as a tree!).
Especially to have a persistent map ready anywhere in the pipeline is great.

Von: BaseX-Talk  Im Auftrag von 
Christian Grün
Gesendet: Mittwoch, 22. Mai 2024 13:00
An: Marco Lettere 
Cc: basex-talk@mailman.uni-konstanz.de
Betreff: Re: [basex-talk] Making store reactive

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 
mailto:m.lett...@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.



Re: [basex-talk] Session problems with two BaseX installations

2024-05-22 Thread Jack Steyn
Hi Christian,

I think you're right, this is a browser issue relating to ports being
ignored. Unfortunately changing the session key doesn't resolve the issue.
It sounds like the DBA webapps need to be contacting different hosts to
prevent session data from being overwritten. Do you have any advice on how
to go about accomplishing this? I'm afraid networking is not one of my
strengths.

Many thanks for your assistance.

Best,

Jack

On Wed, 22 May 2024, 8:47 pm Christian Grün, 
wrote:

> Hi Jack,
>
> It seems that the browser ignores different ports when handling session
> data (just a guess). Does it work if you change the session key of your
> second DBA instance [1]?
>
> Best,
> Christian
>
> [1]
> https://github.com/BaseXdb/basex/blob/df83d80238a27f3a168e3d5e88f984c819a37fb8/basex-api/src/main/webapp/dba/lib/config.xqm#L8-L9
>
>
> On Wed, May 22, 2024 at 5:44 AM Jack Steyn  wrote:
>
>> Hi,
>>
>> I have two separate BaseX installations on the same machine. Each has its
>> own set of databases and users. I run their HTTP servers simultaneously,
>> configured to their own sets of ports.
>>
>> When I authenticate to the DBA webapp of one, I am logged out of the DBA
>> webapp of the other.
>>
>> What might I do to prevent this?
>>
>> Best regards,
>>
>> Jack
>>
>


Re: [basex-talk] Weird behaviour with sequence and random:integer

2024-05-22 Thread Marco Lettere

Everytime one learns something new.

Thanks for the explanation!

M.

On 22/05/24 15:41, Christian Grün wrote:

Hi Marco,

> ("a", "b", "c")[trace(1 + random:integer(3))]

The filter expression is defined in such a way that the predicate is 
evaluated anew for every item of the sequence. If you want 
random:integer(3) to be evaluated only once, you can either bind it to 
a variable…


let $r := random:integer(3) + 1
return ("a", "b", "c")]$r]

…or use functions like fn:subsequence:

subsequence(("a", "b", "c"), random:integer(3) + 1, 1)

Hope this helps,
Christian



Marco Lettere  schrieb am Mi., 22. Mai 2024, 15:34:

Dear all,

I have this strange behavior when running in BaseX 10.4:

["a","b","c"](1 + random:integer(3))

I got something empty result, sometimes (correctly) one out of the
three, sometimes two results...

I report the results and the trace in [1] and [2].

What is the reason for this?

Thank you.

Marco.

[1] Two results
a
c

Evaluating:
1
3
3
Compiling:
- rewrite list to xs:string sequence: ("a", "b", "c")
- swap operands: (1 + random:integer(3))
Optimized Query:
("a", "b", "c")[trace((random:integer(3) + 1))]
Query:
("a", "b", "c")[trace(1 + random:integer(3))]
Result:
- Hit(s): 2 Items
- Updated: 0 Items
- Printed: 3 b
- Read Locking: (none)
- Write Locking: (none)
Timing:
- Parsing: 0.21 ms
- Compiling: 0.4 ms
- Optimizing: 0.1 ms
- Evaluating: 0.57 ms
- Printing: 0.02 ms
- Total Time: 1.31 ms


[2] Empty result
()

Evaluating:
3
3
1
Compiling:
- rewrite list to xs:string sequence: ("a", "b", "c")
- swap operands: (1 + random:integer(3))
Optimized Query:
("a", "b", "c")[trace((random:integer(3) + 1))]
Query:
("a", "b", "c")[trace(1 + random:integer(3))]
Result:
- Hit(s): 0 Items
- Updated: 0 Items
- Printed: 0 b
- Read Locking: (none)
- Write Locking: (none)
Timing:
- Parsing: 0.16 ms
- Compiling: 0.41 ms
- Optimizing: 0.15 ms
- Evaluating: 0.56 ms
- Printing: 0.02 ms
- Total Time: 1.3 ms
Query Plan:

   
 
   a
   b
   c
 
 
   
 
   3
 
 1
   
 
   



Re: [basex-talk] Weird behaviour with sequence and random:integer

2024-05-22 Thread Christian Grün
Hi Marco,

> ("a", "b", "c")[trace(1 + random:integer(3))]

The filter expression is defined in such a way that the predicate is
evaluated anew for every item of the sequence. If you want
random:integer(3) to be evaluated only once, you can either bind it to a
variable…

let $r := random:integer(3) + 1
return ("a", "b", "c")]$r]

…or use functions like fn:subsequence:

subsequence(("a", "b", "c"), random:integer(3) + 1, 1)

Hope this helps,
Christian



Marco Lettere  schrieb am Mi., 22. Mai 2024, 15:34:

> Dear all,
>
> I have this strange behavior when running in BaseX 10.4:
>
> ["a","b","c"](1 + random:integer(3))
>
> I got something empty result, sometimes (correctly) one out of the
> three, sometimes two results...
>
> I report the results and the trace in [1] and [2].
>
> What is the reason for this?
>
> Thank you.
>
> Marco.
>
> [1] Two results
> a
> c
>
> Evaluating:
> 1
> 3
> 3
> Compiling:
> - rewrite list to xs:string sequence: ("a", "b", "c")
> - swap operands: (1 + random:integer(3))
> Optimized Query:
> ("a", "b", "c")[trace((random:integer(3) + 1))]
> Query:
> ("a", "b", "c")[trace(1 + random:integer(3))]
> Result:
> - Hit(s): 2 Items
> - Updated: 0 Items
> - Printed: 3 b
> - Read Locking: (none)
> - Write Locking: (none)
> Timing:
> - Parsing: 0.21 ms
> - Compiling: 0.4 ms
> - Optimizing: 0.1 ms
> - Evaluating: 0.57 ms
> - Printing: 0.02 ms
> - Total Time: 1.31 ms
>
>
> [2] Empty result
> ()
>
> Evaluating:
> 3
> 3
> 1
> Compiling:
> - rewrite list to xs:string sequence: ("a", "b", "c")
> - swap operands: (1 + random:integer(3))
> Optimized Query:
> ("a", "b", "c")[trace((random:integer(3) + 1))]
> Query:
> ("a", "b", "c")[trace(1 + random:integer(3))]
> Result:
> - Hit(s): 0 Items
> - Updated: 0 Items
> - Printed: 0 b
> - Read Locking: (none)
> - Write Locking: (none)
> Timing:
> - Parsing: 0.16 ms
> - Compiling: 0.41 ms
> - Optimizing: 0.15 ms
> - Evaluating: 0.56 ms
> - Printing: 0.02 ms
> - Total Time: 1.3 ms
> Query Plan:
> 
>
>  
>a
>b
>c
>  
>  
>
>  
>3
>  
>  1
>
>  
>
> 
>
>


[basex-talk] Weird behaviour with sequence and random:integer

2024-05-22 Thread Marco Lettere

Dear all,

I have this strange behavior when running in BaseX 10.4:

["a","b","c"](1 + random:integer(3))

I got something empty result, sometimes (correctly) one out of the 
three, sometimes two results...


I report the results and the trace in [1] and [2].

What is the reason for this?

Thank you.

Marco.

[1] Two results
a
c

Evaluating:
1
3
3
Compiling:
- rewrite list to xs:string sequence: ("a", "b", "c")
- swap operands: (1 + random:integer(3))
Optimized Query:
("a", "b", "c")[trace((random:integer(3) + 1))]
Query:
("a", "b", "c")[trace(1 + random:integer(3))]
Result:
- Hit(s): 2 Items
- Updated: 0 Items
- Printed: 3 b
- Read Locking: (none)
- Write Locking: (none)
Timing:
- Parsing: 0.21 ms
- Compiling: 0.4 ms
- Optimizing: 0.1 ms
- Evaluating: 0.57 ms
- Printing: 0.02 ms
- Total Time: 1.31 ms


[2] Empty result
()

Evaluating:
3
3
1
Compiling:
- rewrite list to xs:string sequence: ("a", "b", "c")
- swap operands: (1 + random:integer(3))
Optimized Query:
("a", "b", "c")[trace((random:integer(3) + 1))]
Query:
("a", "b", "c")[trace(1 + random:integer(3))]
Result:
- Hit(s): 0 Items
- Updated: 0 Items
- Printed: 0 b
- Read Locking: (none)
- Write Locking: (none)
Timing:
- Parsing: 0.16 ms
- Compiling: 0.41 ms
- Optimizing: 0.15 ms
- Evaluating: 0.56 ms
- Printing: 0.02 ms
- Total Time: 1.3 ms
Query Plan:

  
    
  a
  b
  c
    
    
  
    
  3
    
    1
  
    
  




Re: [basex-talk] Making store reactive

2024-05-22 Thread Marco Lettere

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  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.



Re: [basex-talk] Making store reactive

2024-05-22 Thread Christian Grün
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  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.
>


Re: [basex-talk] Session problems with two BaseX installations

2024-05-22 Thread Christian Grün
Hi Jack,

It seems that the browser ignores different ports when handling session
data (just a guess). Does it work if you change the session key of your
second DBA instance [1]?

Best,
Christian

[1]
https://github.com/BaseXdb/basex/blob/df83d80238a27f3a168e3d5e88f984c819a37fb8/basex-api/src/main/webapp/dba/lib/config.xqm#L8-L9


On Wed, May 22, 2024 at 5:44 AM Jack Steyn  wrote:

> Hi,
>
> I have two separate BaseX installations on the same machine. Each has its
> own set of databases and users. I run their HTTP servers simultaneously,
> configured to their own sets of ports.
>
> When I authenticate to the DBA webapp of one, I am logged out of the DBA
> webapp of the other.
>
> What might I do to prevent this?
>
> Best regards,
>
> Jack
>


[basex-talk] Making store reactive

2024-05-22 Thread Marco Lettere

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.