Re: [basex-talk] starts-with in a satisfies statement fails to fail
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
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
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
> 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?