Hi again,
There seems to be a bug related to our discussion.
We are using value queries in the Java API, but I've boiled it down to cts
searches.
We are using a database with FCSS and FDSS turned on, while all other
indexes are turned off.
The following snippet exhibits the wrong behavior:
xquery version "1.0-ml";
xdmp:document-insert("/bug/doc.xml", <status>NEW</status>)
;
"Document is found: OK",
cts:search(/,
cts:and-query((cts:directory-query("/bug/", "infinity"),
cts:element-value-query(xs:QName("status"), "NEW", ("exact")))),
"unfiltered"
)
,"---",
"Document is not found: OK",
cts:search(/,
cts:and-query((cts:directory-query("/bug/", "infinity"),
cts:element-value-query(xs:QName("status"), "NEw", ("exact")))),
"unfiltered"
)
,"---",
"Document is found: WRONG",
cts:search(/,
cts:and-query((cts:directory-query("/bug/", "infinity"),
cts:element-value-query(xs:QName("status"), "new", ("exact")))),
"unfiltered"
)
Do you have an idea on that?
Regards,
Andreas
2017-03-01 11:18 GMT+01:00 Andreas Hubmer <[email protected]>:
> Hi,
>
> I support Jason's suggestion to turn on exact matching by default (without
> manually enabling FCSS and FDSS).
> I've done that wrong several times and seen others doing it wrong.
> And further, the advice of MarkLogic is to use unfiltered queries.
>
> Regards,
> Andreas
>
>
> 2017-03-01 2:55 GMT+01:00 Jason Hunter <[email protected]>:
>
>> * Punctuation and space tokens are also not generally indexed as words in
>> the universal index in value queries either. However, as a special
>> exception there are terms in the universal index for "exact" value queries
>> (unstemmed, case-sensitive, whitespace-sensitive, punctuation-sensitive),
>> so "exact" value queries should be resolvable properly from the index, but
>> only if you have fast-case-sensitive-searches and
>> fast-diacritic-sensitive-searches enabled in the database.
>>
>>
>> I'm curious, what's the logic where we only index an "exact" value if
>> FCSS and FDSS are both on?
>>
>> Seems like as a database that's increasingly focusing on data beyond
>> textual content, the ability to do exact matches (like people are used to
>> with relational databases) should be a default feature even if the admin
>> hasn't toggled on text-specific things like those. It's a fairly cheap
>> index, I expect, so why not always have it on?
>>
>> RFE?
>>
>> -jh-
>>
>>
>
_______________________________________________
General mailing list
[email protected]
Manage your subscription at:
http://developer.marklogic.com/mailman/listinfo/general