You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Ard Schrijvers (JIRA)" <ji...@apache.org> on 2007/10/25 17:05:51 UTC
[jira] Created: (JCR-1189) XPath '=' comparison operator results in
a redundant "or" in the lucene query
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
//*[@mytext='test']
results in for example
(_:PROPERTIES:1:mytext?test _:PROPERTIES:1:mytext?test )
while adding a space, like
//*[@mytext='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.
[jira] Commented: (JCR-1189) XPath '=' comparison operator results
in a redundant "or" in the lucene query
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ 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
> //*[@mytext='test']
> results in for example
> (_:PROPERTIES:1:mytext?test _:PROPERTIES:1:mytext?test )
> while adding a space, like
> //*[@mytext='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.
[jira] Updated: (JCR-1189) XPath '=' comparison operator results in
a redundant "or" in the lucene query
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-1189:
-------------------------------
Fix Version/s: (was: 1.4)
Affects Version/s: (was: 1.3.3)
> 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
> Reporter: Ard Schrijvers
> Priority: Trivial
>
> 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
> //*[@mytext='test']
> results in for example
> (_:PROPERTIES:1:mytext?test _:PROPERTIES:1:mytext?test )
> while adding a space, like
> //*[@mytext='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.
[jira] Closed: (JCR-1189) XPath '=' comparison operator results in
a redundant "or" in the lucene query
Posted by "Ard Schrijvers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ard Schrijvers closed JCR-1189.
-------------------------------
Resolution: Invalid
You are right. I missed this little thing :-)
Sorry for the trouble, I'll quickly close the issue. Thanks
> 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
> //*[@mytext='test']
> results in for example
> (_:PROPERTIES:1:mytext?test _:PROPERTIES:1:mytext?test )
> while adding a space, like
> //*[@mytext='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.