Hi Doug, That fact that your environment is showing different results from mine for the queries with no options illustrates my point: the defaults will change depending on your environment. Notice that the queries that explicitly set the defaults return the same (the 2nd and 4th return true) in your environment and mine.
As for the cts:search results, what exactly is the query you ran to get those results? It might be that the data I constructed in the cts:contains example does not exactly match your data? And when you say the data represents a two-part string UID, is this value all in the same element or attribute? Or are they in different elements/attributes? If they are in a single value, then I think the range-queries can work for you. If so, you will have to choose a collation that makes sense to you. Also, what version of MarkLogic Server are you running? -Danny From: [email protected] [mailto:[email protected]] On Behalf Of Glidden, Douglass A Sent: Wednesday, June 10, 2009 10:25 AM To: [email protected] Subject: RE: [MarkLogic Dev General] element-value-queryvs.element-attribute-value-query behavior difference Danny, Well, I copied and pasted your query into CQ and got all true results, so apparently there's a configuration difference going on here. What's more distressing is that (with those docs in the DB so that they can be searched), running those four cts:contains calls returns (as before): true true true true but changing cts:contains to cts:search returns (respectively): () () (<testNode><insertDate>10JUN2009</insertDate></testNode>) (<testNode><insertDate>10JUN2009</insertDate></testNode>) This confuses me greatly because it seems to indicate that cts:contains and cts:search are not even consistent with each other when operating on the same element-attribute-value-query. By the way, I probably shouldn't have used dates as examples, but I used them for simplicity; in reality the data value represents a two-part, string UID (the format of the UID is outside of my control, and the second part is optional), so I don't think an element-range-query or element-attribute-range-query is an option. Doug Glidden -----Original Message----- From: Danny Sokolsky [mailto:[email protected]] Sent: Wednesday, June 10, 2009 12:27 To: General Mark Logic Developer Discussion Subject: RE: [MarkLogic Dev General] element-value-queryvs.element-attribute-value-query behavior difference I think what is going on here is that the defaults are tripping you up. MarkLogic tries to be smart about the default query options like wildcarded and case-sensitive, setting the defaults based on the actual query text and on the database settings. The defaults work well for your typical text query, but sometimes for these data-like queries, it will default to something that is inconvenient. To avoid this confusion, particularly when searching for values with numbers, caps, and punctuation, it is good to be explicit in the query about the query options, that way there are no surprises and your query behavior will not change with your data and configuration. For example, consider the following: let $x := <testNode insertDate="10JUN2009" /> let $y := <testNode> <insertDate>10JUN2009</insertDate> </testNode> return (cts:contains($x, cts:element-attribute-value-query( xs:QName("testNode"), xs:QName("insertDate"), "10JUN2009*")), cts:contains($x, cts:element-attribute-value-query( xs:QName("testNode"), xs:QName("insertDate"), "10JUN2009*", ("wildcarded", "case-sensitive", "punctuation-sensitive"))), cts:contains($y, cts:element-value-query( xs:QName("insertDate"), "10JUN2009*")), cts:contains($y, cts:element-value-query( xs:QName("insertDate"), "10JUN2009*", ("wildcarded", "case-sensitive", "punctuation-sensitive"))) ) returns: false true false true So make sure you are running the query you think you are running. Also, you might consider creating range indexes on those values and then using either the lexicon APIs to get the values or cts:element-range-query and cts:element-attribute-range-query. THese might prove to be faster. Does that help? -Danny _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
_______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
