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, BaseX will probably do it for you, so… Never mind

In general, if trace() yields no results, I would assume that your
corresponding code snippet is never executed.


On Wed, Feb 13, 2019 at 5:30 PM George Sofianos  wrote:
>
> 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.
>
> declare function common:string($elements) as xs:string* {
> let $values := data($elements)
> let $values := for $i in $values return 
> lower-case(normalize-space(string($i)))
> return $values
> };
>
> declare function common:startsWith($elements, $string) as xs:boolean {
> let $string := common:string($string) => trace("STRING: ")
> let $data := common:string($elements)
> return some $i in $data satisfies starts-with($i, $string) => 
> trace("SATISFY: ")
> };
>
> The main query is 5823 lines so it's not very easy to find out what's going 
> on. My assumption is that for some reason the Quantifier expressions get 
> optimized to ignore errors. What I noticed is that if I change the following:
>
> satisfies starts-with($i, $string)
> to
> satisfies 1 = "a"
>
> It will finally fail as expected, even with the optimized final query plan. I 
> will keep trying to create a reproducible example. The alternative is to send 
> you the main query along with the source XML file.
> Best,
>
> George


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 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 have a chance to get this reproducible?


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.

declare function common:string($elements) as xs:string* {
    let $values := data($elements)
    let $values := for $i in $values return 
lower-case(normalize-space(string($i)))

    return $values
};

declare function common:startsWith($elements, $string) as xs:boolean {
    let $string := common:string($string) => trace("STRING: ")
    let $data := common:string($elements)
    return some $i in $data satisfies starts-with($i, $string) => 
trace("SATISFY: ")

};

The main query is 5823 lines so it's not very easy to find out what's 
going on. My assumption is that for some reason the Quantifier 
expressions get optimized to ignore errors. What I noticed is that if I 
change the following:


satisfies starts-with($i, $string)
to
satisfies 1 = "a"

It will finally fail as expected, even with the optimized final query 
plan.I will keep trying to create a reproducible example. The 
alternative is to send you the main query along with the source XML file.

Best,

George



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 have a chance to get this reproducible?