Re: [basex-talk] jobs:list-details o/p

2019-02-13 Thread Christian Grün
Hi Andy, I completely agree, the inclusion of the dummy file name doesn’t make any sense here. Job handling has been revised in Version 9, but I think I have found a solution for the job listing that should work similar to the original one. A new snapshot is online [1], your feedback is welcome.

[basex-talk] starts-with in a satisfies statement fails to fail

2019-02-13 Thread George Sofianos
Hi, I have a specific piece of code which fails to run as expected. Unfortunately i didn't manage to create an MCVE so far. The part of code that should fail in my script is:     some $i in $data satisfies starts-with($i, $string) Where $data is a list of strings, and $string is a sequence

Re: [basex-talk] proc:execute

2019-02-13 Thread Christian Grün
Hi Giuseppe, Have you tried to set your locale variable on your system? If it’s Ubuntu, you could have a look here: https://ubuntuforums.org/showthread.php?t=2212353 Hope this helps, Christian On Tue, Feb 12, 2019 at 4:13 PM Giuseppe G. A. Celano wrote: > > I notice that if I run "locale"

Re: [basex-talk] starts-with in a satisfies statement fails to fail

2019-02-13 Thread Christian Grün
> I'm not sure if you can find anything from the Query plan for why this is > happening. This fails either with or without inlining. > Regards, Difficult to tell without investing some considerable time I guess… How does the original query look like that produces this query plan? Maybe we still

Re: [basex-talk] starts-with in a satisfies statement fails to fail

2019-02-13 Thread George Sofianos
Hi Christian, On 2/13/19 6:19 PM, Christian Grün wrote: Difficult to tell without investing some considerable time I guess… How does the original query look like that produces this query plan? Maybe we still have a chance to get this reproducible? There are just two function involved in this.

Re: [basex-talk] Global locks

2019-02-13 Thread Christian Grün
Hi James, hi Andy, When adding database locks to BaseX, I remember we had some thoughts if we shouldn’t add explicit lock features to BaseX, exactly for those cases in which the optimizer is not powerful enough to detect the required locks. One of the reasons why we discarded this idea was that

Re: [basex-talk] starts-with in a satisfies statement fails to fail

2019-02-13 Thread George Sofianos
Hi again, My mistake, I failed to see an error in my code which returned empty elements, which resulted in the quantifier not executing. Sorry for wasting your time and have a good evening! On 2/13/19 6:19 PM, Christian Grün wrote: I'm not sure if you can find anything from the Query plan

Re: [basex-talk] Global locks

2019-02-13 Thread James Ball
> On 13 Feb 2019, at 16:38, Christian Grün wrote: > Manual locks could either be assigned globally or > within a query: > > (# db:manuallock #) { >(# basex:write-lock BEP-Staging #) { > (# basex:read-lock BEP #) { >let $d:=db:open('BEP') >return

Re: [basex-talk] starts-with in a satisfies statement fails to fail

2019-02-13 Thread Christian Grün
This doesn’t really contribute to your problem, but if all items in $elements are of type node() or xs:string, you could possibly simplify your query to something as follows: declare function common:string($elements) as xs:string* { $elements ! lower-case(normalize-space(.)) }; If you won’t,

Re: [basex-talk] Global locks

2019-02-13 Thread Christian Grün
> Would this work where the database names are only known at run time? Right now, our locking is based on static code analysis; runtime information won’t be included. In the longer term, we would like to extend our compiler to perform multiple steps: 1. Static parsing 2. Static optimizations

Re: [basex-talk] jobs:list-details o/p

2019-02-13 Thread Andy Bunce
Looks good. Thanks. /Andy On Wed, 13 Feb 2019 at 16:14, Christian Grün wrote: > Hi Andy, > > I completely agree, the inclusion of the dummy file name doesn’t make > any sense here. Job handling has been revised in Version 9, but I > think I have found a solution for the job listing that should