[
https://issues.apache.org/jira/browse/JCR-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538499
]
Marcel Reutegger commented on JCR-1189:
---------------------------------------
I think the above example for the generated Lucene query is not entirely
correct. In fact there will be generated two term queries, but they are
distinct. The reason can be found in LuceneQueryBuilder (line 1060). Because
the string literal 'test' may also be a property value of type NAME, it is
additionally coerced into a NAME. NAME values are indexed differently from
STRINGs because they are namespace sensitive. When I test the above query
Jackrabbit creates the following query:
(_:PROPERTIES:10:propspace?foo _:PROPERTIES:10:propspace?10:foo)
Note the 10:foo, which is the index internal NAME value representation of 'foo'
(10 is in my repository the prefix for the empty default namespace).
If a space is appended to 'test', the literal cannot be coerced because it is
not a valid NAME.
> XPath '=' comparison operator results in a redundant "or" in the lucene query
> -----------------------------------------------------------------------------
>
> Key: JCR-1189
> URL: https://issues.apache.org/jira/browse/JCR-1189
> Project: Jackrabbit
> Issue Type: Bug
> Components: query
> Affects Versions: 1.3.3
> Reporter: Ard Schrijvers
> Priority: Trivial
> Fix For: 1.4
>
>
> This issue has no real consequences as far as I can see (perhaps some
> performance, but lucene might ignore it though), but an XPath like
> //[EMAIL PROTECTED]'test']
> results in for example
> (_:PROPERTIES:1:mytext?test _:PROPERTIES:1:mytext?test )
> while adding a space, like
> //[EMAIL PROTECTED]'test ']
> does result in
> (_:PROPERTIES:1:mytext?test )
> Suppose it is somewhere in the generated code at
> org.apache.jackrabbit.core.query.xpath.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
