Hi Richard, The support team publishes a fixed-bug report that is available to all registered support contacts.
My expectation is that the not-query will be honored (with the exception of the case you found), but you can use xdmp:plan() to check any that you're not sure of. Dave. -- Dave Cassel Developer Community Manager MarkLogic Corporation<http://www.marklogic.com/> From: Richard Lees <[email protected]<mailto:[email protected]>> Reply-To: MarkLogic Developer Discussion <[email protected]<mailto:[email protected]>> Date: Monday, November 10, 2014 at 10:03 AM To: 'MarkLogic Developer Discussion' <[email protected]<mailto:[email protected]>> Subject: Re: [MarkLogic Dev General] cts:search AND queries - different query order affects results Many thanks for getting back to me Dave. I’m not sure that the element value queries necessarily *need* to have the same value, since the first time we spotted this, we were using different values, using an element-range-query (element >= date1 AND element <= date2). I didn’t include this in the example XQuery due to the increased amount of setup required – I wanted to make the xquery as simple as possible. Index-creation notwithstanding, it looked something like this: let $ query := ( cts:element-range-query((xs:QName("ns:dateElement")), ">=", xs:date("2013-05-15")), cts:element-range-query((xs:QName("ns:dateElement")), "<=", xs:date("2013-05-18")), cts:not-query(cts:properties-query(cts:element-value-query(xs:QName("three"), "xxx")))) When you raise the bug, is there a way to be able to track its progress? I’m not sure of what the visibility is for MarkLogic bugs, and it would be useful to know when it’s fixed, as well as what version(s) of MarkLogic it would be applicable to. For instance, would we need to upgrade to a later version of MarkLogic in order to take advantage of any potential fix? Also, one more question, if the “not” part of the query is always at the end, can we be sure that it will never be lost during query optimization? Regards, Richard From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Dave Cassel Sent: 10 November 2014 14:20 To: MarkLogic Developer Discussion Subject: Re: [MarkLogic Dev General] cts:search AND queries - different query order affects results Richard, I ran xdmp:plan()<http://docs.marklogic.com/xdmp:plan> on forward & reversed $elements-same-not-properties-query and it looks like a bug to me -- the "not" part of the query looks like it gets lost during query optimization. I'm going to file this as a bug. It looks like the only time it happens is when the two element value queries are not only applied against the same element, but have the same value (since your "this"/"that"/not("xxx") query works). -- Dave Cassel Developer Community Manager MarkLogic Corporation<http://www.marklogic.com/> From: Richard Lees <[email protected]<mailto:[email protected]>> Reply-To: MarkLogic Developer Discussion <[email protected]<mailto:[email protected]>> Date: Monday, November 10, 2014 at 7:47 AM To: "'[email protected]<mailto:'[email protected]>'" <[email protected]<mailto:[email protected]>> Subject: [MarkLogic Dev General] cts:search AND queries - different query order affects results Hi, We've noticed some unusual behaviour when performing a cts:search with a specific set of ANDed queries, in that the order of the queries is important. If the order of the queries is reversed, the search returns different results. Please find below some sample searches; the one with the unusual behaviour is labelled (: failure case :), which has the following characteristics: * Two element value queries against the same element * A NOT query against a property The search is successful when the NOT query is the last query; however, if the NOT query is the first, or second query, then the search is not successful. Other searches with different variations (e.g. where the element value queries are against different elements) are fine; the order of the individual queries does not affect the results. Any suggestions on this would be much appreciated - we'd like to know if there's a genuine (and expected) reason why this would be happening, or if there's an issue with cts:search. Is it the case that the order of ANDed queries could be important, in certain situations? Thanks, Richard XQuery: declare namespace ns = "https://and/query/fail";; (: set up - note that this should be done *before* the queries below, to give the indexes time to catch up :) let $content := <content xmlns="https://and/query/fail";<https://and/query/fail%22>> <one>this</one> <two>that</two> </content> let $doc := xdmp:document-insert("/querytest/x", $content) let $props := xdmp:document-set-property("/querytest/x", <three>other</three>) (: failure case - this is expected to return consistent results, irrespective of the order of the individual queries, but doesn't :) let $elements-same-not-properties-query := ( cts:element-value-query((xs:QName("ns:one")), "this"), cts:element-value-query((xs:QName("ns:one")), "this"), cts:not-query(cts:properties-query(cts:element-value-query(xs:QName("three"), "xxx")))) (: but this one works - there is only one element value query :) let $one-elements-not-properties-query := ( cts:element-value-query((xs:QName("ns:one")), "this"), cts:not-query(cts:properties-query(cts:element-value-query(xs:QName("three"), "xxx")))) (: this also works - the first two queries are against different elements :) let $elements-different-not-properties-query := ( cts:element-value-query((xs:QName("ns:one")), "this"), cts:element-value-query((xs:QName("ns:two")), "that"), cts:not-query(cts:properties-query(cts:element-value-query(xs:QName("three"), "xxx")))) (: this also works - it's a positive query, not a NOT query :) let $elements-same-positive-properties-query := ( cts:element-value-query((xs:QName("ns:one")), "this"), cts:element-value-query((xs:QName("ns:one")), "this"), cts:properties-query(cts:element-value-query(xs:QName("three"), "other"))) (: this also works - the NOT query is against an element instead of a property :) let $elements-same-not-element-query := ( cts:element-value-query((xs:QName("ns:one")), "this"), cts:element-value-query((xs:QName("ns:one")), "this"), cts:not-query(cts:element-value-query(xs:QName("ns:two"), "xxx"))) (: try each set of AND queries in normal order, and reverse order - the results should be consistent :) return <result> <elements-same-not-properties-query> <normal> { cts:search(doc(), cts:and-query($elements-same-not-properties-query)) } </normal> <reversed> { cts:search(doc(), cts:and-query(reverse($elements-same-not-properties-query))) } </reversed> </elements-same-not-properties-query> <one-element-not-properties-query> <normal> { cts:search(doc(), cts:and-query($elements-different-not-properties-query)) } </normal> <reversed> { cts:search(doc(), cts:and-query(reverse($elements-different-not-properties-query))) } </reversed> </one-element-not-properties-query> <elements-different-not-properties-query> <normal> { cts:search(doc(), cts:and-query($elements-different-not-properties-query)) } </normal> <reversed> { cts:search(doc(), cts:and-query(reverse($elements-different-not-properties-query))) } </reversed> </elements-different-not-properties-query> <elements-same-positive-properties-query> <normal> { cts:search(doc(), cts:and-query($elements-same-positive-properties-query)) } </normal> <reversed> { cts:search(doc(), cts:and-query(reverse($elements-same-positive-properties-query))) } </reversed> </elements-same-positive-properties-query> <elements-same-not-element-query> <normal> { cts:search(doc(), cts:and-query($elements-same-not-element-query)) } </normal> <reversed> { cts:search(doc(), cts:and-query(reverse($elements-same-not-element-query))) } </reversed> </elements-same-not-element-query> </result>
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
