[
https://issues.apache.org/jira/browse/OAK-3591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15006290#comment-15006290
]
Chetan Mehrotra commented on OAK-3591:
--------------------------------------
bq. Yes, and if that's the case, then the index shouldn't be used for queries
of type "contains(., '1234')", this is what the bug is about:
Got it. Yup that would be a bug in IndexPlanner logic. Added testcase in
1714519 which cover 2 scenarios
# Any property has analyzed=true and fulltext query performed - A plan was
being returned. Should have been null
# Any property has analyzed=true and pure nodeType based query being performed
- A plan was being returned. Should have been null
> Lucene index with 'analyzed=true' sometimes used by mistake
> -----------------------------------------------------------
>
> Key: OAK-3591
> URL: https://issues.apache.org/jira/browse/OAK-3591
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene, query
> Reporter: Thomas Mueller
> Assignee: Chetan Mehrotra
> Fix For: 1.3.11
>
>
> A Lucene index with a property that is configured as "analyzed = true" is
> sometimes used by mistake. Example:
> {noformat}
> oak:index/testLuceneIndex (oak:QueryIndexDefinition)
> compatVersion: 2
> type: lucene
> async: "async"
> indexRules (nt:unstructured)
> nt:base (nt:unstructured)
> properties (nt:unstructured)
> xyz (nt:unstructured)
> propertyIndex: true,
> analyzed: true,
> name: xyz
> query:
> /jcr:root/content//*[jcr:contains(., '1234')]
> {noformat}
> The index is used, but the result does not contain nodes with properties abc
> = '1234'.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
