[jira] [Commented] (OAK-3838) IndexPlanner incorrectly lets all full text indices to participate for suggest/spellcheck queries
[
https://issues.apache.org/jira/browse/OAK-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229531#comment-15229531
]
Vikas Saurabh commented on OAK-3838:
Backported to 1.2 branch at [r1738073|https://svn.apache.org/r1738073].
> IndexPlanner incorrectly lets all full text indices to participate for
> suggest/spellcheck queries
> -
>
> Key: OAK-3838
> URL: https://issues.apache.org/jira/browse/OAK-3838
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.4, 1.3.14, 1.2.14
>
> Attachments: OAK-3838-take2.patch, OAK-3838.patch
>
>
> Currently, index planner builds plan for suggest/spellcheck queries even if
> the indices don't have those functionality enabled.
> Also, there's another issue: when suggestion/spell-check come into play, we
> need to dis-allow inheritance behavior of indexingRule. To clarify, a query
> like {{SELECT [rep:suggest()] from [nt:unstructured] where suggest('test')}}
> if using some index preparing suggestions on {{nt:base}} would give incorrect
> suggestions as the index would have suggested values from other type of nodes
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3838) IndexPlanner incorrectly lets all full text indices to participate for suggest/spellcheck queries
[
https://issues.apache.org/jira/browse/OAK-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15087365#comment-15087365
]
Thomas Mueller commented on OAK-3838:
-
OK I understand now. If there is only an index for "nt:base" and the query is
for node type "acme", then the index for "nt:base" can not be used, as the
index does not contain nodetype information (and the result is not actually
nodes, but suggestions). So, the index for "nt:base" can only be used for a
query on "nt:base".
As for the method name: we currently have getMixinTypes, getPrimaryTypes,
getSupertypes. Those return sets of strings. Therefore, I think the new method
should be called just getNodeType and not getNodeTypeName.
> IndexPlanner incorrectly lets all full text indices to participate for
> suggest/spellcheck queries
> -
>
> Key: OAK-3838
> URL: https://issues.apache.org/jira/browse/OAK-3838
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.4
>
> Attachments: OAK-3838-take2.patch, OAK-3838.patch
>
>
> Currently, index planner builds plan for suggest/spellcheck queries even if
> the indices don't have those functionality enabled.
> Also, there's another issue: when suggestion/spell-check come into play, we
> need to dis-allow inheritance behavior of indexingRule. To clarify, a query
> like {{SELECT [rep:suggest()] from [nt:unstructured] where suggest('test')}}
> if using some index preparing suggestions on {{nt:base}} would give incorrect
> suggestions as the index would have suggested values from other type of nodes
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3838) IndexPlanner incorrectly lets all full text indices to participate for suggest/spellcheck queries
[
https://issues.apache.org/jira/browse/OAK-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15085594#comment-15085594
]
Vikas Saurabh commented on OAK-3838:
Suggest and spellcheck queries get piggy-backed as native queries (of the form
{{native-lucene=suggest?term=}}). So, if a query wants suggestions on
{{nt:unstructured}} while there's a lucene index on {{nt:base}}, we shouldn't
let this index answer the query - as the index would give suggestion from other
nodes (which are nt:base but not nt:unstructured). In usual cases, such
extraneous results get filtered out by layers receiving rows from index - but
the layers above would simply let all the rows go through.
To avoid this, we want to match {{nodeTypeName}} picked by selector exactly to
indexing rule defined in the index. [~tmueller], is it fine if we expose
{{nodeTypeName}} in {{Filter}} (like we do for mixinTypes, primaryTypes, etc)?
> IndexPlanner incorrectly lets all full text indices to participate for
> suggest/spellcheck queries
> -
>
> Key: OAK-3838
> URL: https://issues.apache.org/jira/browse/OAK-3838
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.4
>
> Attachments: OAK-3838.patch
>
>
> Currently, index planner builds plan for suggest/spellcheck queries even if
> the indices don't have those functionality enabled.
> Also, there's another issue: when suggestion/spell-check come into play, we
> need to dis-allow inheritance behavior of indexingRule. To clarify, a query
> like {{SELECT [rep:suggest()] from [nt:unstructured] where suggest('test')}}
> if using some index preparing suggestions on {{nt:base}} would give incorrect
> suggestions as the index would have suggested values from other type of nodes
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3838) IndexPlanner incorrectly lets all full text indices to participate for suggest/spellcheck queries
[
https://issues.apache.org/jira/browse/OAK-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15085491#comment-15085491
]
Vikas Saurabh commented on OAK-3838:
Sorry for the noise. Reverted it at [r1723300|http://svn.apache.org/r1723300].
Would discuss how to get queried node type and fix later.
> IndexPlanner incorrectly lets all full text indices to participate for
> suggest/spellcheck queries
> -
>
> Key: OAK-3838
> URL: https://issues.apache.org/jira/browse/OAK-3838
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.4
>
> Attachments: OAK-3838.patch
>
>
> Currently, index planner builds plan for suggest/spellcheck queries even if
> the indices don't have those functionality enabled.
> Also, there's another issue: when suggestion/spell-check come into play, we
> need to dis-allow inheritance behavior of indexingRule. To clarify, a query
> like {{SELECT [rep:suggest()] from [nt:unstructured] where suggest('test')}}
> if using some index preparing suggestions on {{nt:base}} would give incorrect
> suggestions as the index would have suggested values from other type of nodes
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3838) IndexPlanner incorrectly lets all full text indices to participate for suggest/spellcheck queries
[
https://issues.apache.org/jira/browse/OAK-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15085305#comment-15085305
]
Marcel Reutegger commented on OAK-3838:
---
I think this commit breaks the build. OSGiIT in oak-run reports:
{noformat}
org.osgi.framework.BundleException: Unresolved constraint in bundle
org.apache.jackrabbit.oak-lucene [29]: Unable to resolve 29.0: missing
requirement [29.0] osgi.wiring.package;
(osgi.wiring.package=org.apache.jackrabbit.oak.query.ast))
{noformat}
The ast package is not exported because it was only used internally in oak-core
so far.
> IndexPlanner incorrectly lets all full text indices to participate for
> suggest/spellcheck queries
> -
>
> Key: OAK-3838
> URL: https://issues.apache.org/jira/browse/OAK-3838
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.4
>
> Attachments: OAK-3838.patch
>
>
> Currently, index planner builds plan for suggest/spellcheck queries even if
> the indices don't have those functionality enabled.
> Also, there's another issue: when suggestion/spell-check come into play, we
> need to dis-allow inheritance behavior of indexingRule. To clarify, a query
> like {{SELECT [rep:suggest()] from [nt:unstructured] where suggest('test')}}
> if using some index preparing suggestions on {{nt:base}} would give incorrect
> suggestions as the index would have suggested values from other type of nodes
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3838) IndexPlanner incorrectly lets all full text indices to participate for suggest/spellcheck queries
[
https://issues.apache.org/jira/browse/OAK-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15084982#comment-15084982
]
Chetan Mehrotra commented on OAK-3838:
--
Some minor comments
# Minor IndexDefinition#evaluateSpellcheckEnabled,
IndexDefinition#evaluateSuggestionEnabled - return on matching condition would
be better as break would only break out of inner loop
# Minor Directly get string value from a given property. Any coercion (if
required) would be done by PropertyValue itself
{code}
+PropertyValue pv =
filter.getPropertyRestriction(definition.getFunctionName()).first;
+String query = String.valueOf(pv.getValue(pv.getType()));
Instead use
+PropertyValue pv =
filter.getPropertyRestriction(definition.getFunctionName()).first;
+String query = pv.getValue(Type.STRING);
{code}
# Also would be good to refactor the new logic in IndexPlanner to a separate
method as its very specific.
> IndexPlanner incorrectly lets all full text indices to participate for
> suggest/spellcheck queries
> -
>
> Key: OAK-3838
> URL: https://issues.apache.org/jira/browse/OAK-3838
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.4
>
> Attachments: OAK-3838.patch
>
>
> Currently, index planner builds plan for suggest/spellcheck queries even if
> the indices don't have those functionality enabled.
> Also, there's another issue: when suggestion/spell-check come into play, we
> need to dis-allow inheritance behavior of indexingRule. To clarify, a query
> like {{SELECT [rep:suggest()] from [nt:unstructured] where suggest('test')}}
> if using some index preparing suggestions on {{nt:base}} would give incorrect
> suggestions as the index would have suggested values from other type of nodes
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3838) IndexPlanner incorrectly lets all full text indices to participate for suggest/spellcheck queries
[
https://issues.apache.org/jira/browse/OAK-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15083479#comment-15083479
]
Vikas Saurabh commented on OAK-3838:
Have committed the patch in trunk at [r1723142|http://svn.apache.org/r1723142].
Not resolving the issue yet though.
> IndexPlanner incorrectly lets all full text indices to participate for
> suggest/spellcheck queries
> -
>
> Key: OAK-3838
> URL: https://issues.apache.org/jira/browse/OAK-3838
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.4
>
> Attachments: OAK-3838.patch
>
>
> Currently, index planner builds plan for suggest/spellcheck queries even if
> the indices don't have those functionality enabled.
> Also, there's another issue: when suggestion/spell-check come into play, we
> need to dis-allow inheritance behavior of indexingRule. To clarify, a query
> like {{SELECT [rep:suggest()] from [nt:unstructured] where suggest('test')}}
> if using some index preparing suggestions on {{nt:base}} would give incorrect
> suggestions as the index would have suggested values from other type of nodes
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
