Danny, sounds good, and I'm downloading 4.0-5 now. Is 4.0-5 a development-only release or something? The download page <http://www.marklogic.com/product/download-software.html> on the main MarkLogic site still leads to 4.0-3, but the developer download page <http://developer.marklogic.com/download/> has 4.0-5.
Doug Glidden (703) 317-7523 http://dougglidden.blog.boeing.com <http://dougglidden.blog.boeing.com/> _____ From: Danny Sokolsky [mailto:[email protected]] Sent: Wednesday, June 10, 2009 17:19 To: General Mark Logic Developer Discussion Subject: [MarkLogic Dev General] RE: [MarkLogic DevGeneral]element-value-queryvs.element-attribute-value-query behaviordifference Hi Doug, I believe you are running into a wildcard bug in 4.0-3, and it is fixed in 4.0-5. In 4.0-5, your query works as expected, and when the cts:contains returns true the corresponding cts:search returns the node (and vice versa). -Danny From: [email protected] [mailto:[email protected]] On Behalf Of Glidden, Douglass A Sent: Wednesday, June 10, 2009 12:29 PM To: [email protected] Subject: RE: [MarkLogic Dev General]element-value-queryvs.element-attribute-value-query behavior difference Danny, I executed both the cts:contains and the cts:search queries against the same data, these four documents that are in ML: * <testNode insertDate="10JUN2009"/> * <testNode insertDate="10JUN2009-0849"/> * <testNode><insertDate>10JUN2009</insertDate></testNode> * <testNode><insertDate>10JUN2009-0855</insertDate></testNode> Here is the query I executed (with some XML to format the results nicely): xquery version "1.0-ml"; let $queries := ( cts:element-attribute-value-query(xs:QName("testNode"), xs:QName("insertDate"), "10JUN2009*"), cts:element-attribute-value-query(xs:QName("testNode"), xs:QName("insertDate"), "10JUN2009*", ("wildcarded", "case-sensitive", "punctuation-sensitive")), cts:element-value-query(xs:QName("insertDate"), "10JUN2009*"), cts:element-value-query(xs:QName("insertDate"), "10JUN2009*", ("wildcarded", "case-sensitive", "punctuation-sensitive")) ) return <results>{ for $i in (1 to fn:count($queries)) return element {fn:concat("query_", $i)} { <contains_result>{ cts:contains(/testNode, $queries[$i]) }</contains_result>, <search_result>{ cts:search(/testNode, $queries[$i]) }</search_result> } }</results> The results returned are: <results> <query_1> <contains_result>true</contains_result> <search_result /> </query_1> <query_2> <contains_result>true</contains_result> <search_result /> </query_2> <query_3> <contains_result>true</contains_result> <search_result> <testNode> <insertDate>10JUN2009</insertDate> </testNode> </search_result> </query_3> <query_4> <contains_result>true</contains_result> <search_result> <testNode> <insertDate>10JUN2009</insertDate> </testNode> </search_result> </query_4> </results> So as you can see, regardless of whether the options are specified (in my particular configuration), the cts:contains query against the attribute returns true but the cts:search query (using exactly the same inner query and running against exactly the same data), returns an empty sequence. On the subject of the UID, it's all in a single attribute (I included the element version to show that the behavior was different). The first part (before the hyphen) is always present, can take one of several formats, and may contain another hyphen in addition to letters and numbers (in reality the first part consists of two or three independent sub-parts, but from the perspective of the DB it can be considered a single string); the second part (after the hyphen) is optional-used only for revisions to an existing item-but follows a single format when it is present. I'd be interested in knowing how you would use a range query in this situation. Also note that the query string is being parsed from a more-or-less Google-like search box, and I can't guarantee that there won't be wildcards at the beginning or somewhere in the middle rather than just at the end. Finally, I'm running MarkLogic Server 4.0-3. Thanks for all your attempts, Doug Glidden _____ From: Danny Sokolsky [mailto:[email protected]] Sent: Wednesday, June 10, 2009 13:52 To: General Mark Logic Developer Discussion Subject: RE: [MarkLogic Dev General]element-value-queryvs.element-attribute-value-query behavior difference 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
_______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
