[jira] [Commented] (OAK-8271) Lucene path transformed result doesn't accomodate wildcards in relative path
[
https://issues.apache.org/jira/browse/OAK-8271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857632#comment-16857632
]
Thomas Mueller commented on OAK-8271:
-
The patch looks good to me.
> I don't think we want to "support" // necessarily
No, we don't need to support this.
> I'm not sure where should we document this though
We could document it here:
* http://jackrabbit.apache.org/oak/docs/query/grammar-xpath.html#dynamic_operand
* http://jackrabbit.apache.org/oak/docs/query/grammar-sql2.html#condition
> Lucene path transformed result doesn't accomodate wildcards in relative path
>
>
> Key: OAK-8271
> URL: https://issues.apache.org/jira/browse/OAK-8271
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Attachments: OAK-8271.patch
>
>
> {{LucenePropertyIndex}} support answering a query with property constraint on
> a relative path if there's an property (non-relative) is indexed on
> {{nt:base}}.
> e.g. with an index def such as
> {noformat}
> + /oak:index/fooIndex/indexRules/nt:base/properties
>+ foo
>- propertyIndex=true
> {noformat}
> we can answer queries such as
> {noformat}
> /jcr:root/a//element(*, some:type)[b/foo='bar']
> /jcr:root/a//element(*, some:type)[b/c/foo='bar']
> {noformat}
> In the same spirit it could also support query with wildcard in relative path
> fragment
> {noformat}
> /jcr:root/a//element(*, some:type)[b/*/foo='bar']
> {noformat}
> but it doesn't work currently.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8271) Lucene path transformed result doesn't accomodate wildcards in relative path
[
https://issues.apache.org/jira/browse/OAK-8271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825958#comment-16825958
]
Vikas Saurabh commented on OAK-8271:
Attaching [^OAK-8271.patch] which takes the mentioned approach for
non-fulltext conditions while retains the earlier approach for fulltext
conditions. It required to tweak an earlier test for property restriction
accordingly.
[~tmueller], as you expected, {{//}} type condition doesn't work but other
conditions that are utilizing wildcard do work out. I'm not sure where should
we document this though (I don't think we want to "support" {{//}} necessarily).
> Lucene path transformed result doesn't accomodate wildcards in relative path
>
>
> Key: OAK-8271
> URL: https://issues.apache.org/jira/browse/OAK-8271
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Attachments: OAK-8271.patch
>
>
> {{LucenePropertyIndex}} support answering a query with property constraint on
> a relative path if there's an property (non-relative) is indexed on
> {{nt:base}}.
> e.g. with an index def such as
> {noformat}
> + /oak:index/fooIndex/indexRules/nt:base/properties
>+ foo
>- propertyIndex=true
> {noformat}
> we can answer queries such as
> {noformat}
> /jcr:root/a//element(*, some:type)[b/foo='bar']
> /jcr:root/a//element(*, some:type)[b/c/foo='bar']
> {noformat}
> In the same spirit it could also support query with wildcard in relative path
> fragment
> {noformat}
> /jcr:root/a//element(*, some:type)[b/*/foo='bar']
> {noformat}
> but it doesn't work currently.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8271) Lucene path transformed result doesn't accomodate wildcards in relative path
[
https://issues.apache.org/jira/browse/OAK-8271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825073#comment-16825073
]
Vikas Saurabh commented on OAK-8271:
[~tmueller], no I didn't try these variations. Afaics, if some of these are
wrong then that should be fixed in query engine (oak-core).
Btw, in the meantime I realized that {{transformPath}} is used in fulltext
constraints too - so the simple diff away won't work right away. My intent is
just that the "filtering" that query engine does can (should) remain there so
that any feature/fixes are automatically incorporated.
PS: Btw, the examples I had in description work with property indexes - I
didn't check if it's due to IndexProvider or QE.
> Lucene path transformed result doesn't accomodate wildcards in relative path
>
>
> Key: OAK-8271
> URL: https://issues.apache.org/jira/browse/OAK-8271
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
>
> {{LucenePropertyIndex}} support answering a query with property constraint on
> a relative path if there's an property (non-relative) is indexed on
> {{nt:base}}.
> e.g. with an index def such as
> {noformat}
> + /oak:index/fooIndex/indexRules/nt:base/properties
>+ foo
>- propertyIndex=true
> {noformat}
> we can answer queries such as
> {noformat}
> /jcr:root/a//element(*, some:type)[b/foo='bar']
> /jcr:root/a//element(*, some:type)[b/c/foo='bar']
> {noformat}
> In the same spirit it could also support query with wildcard in relative path
> fragment
> {noformat}
> /jcr:root/a//element(*, some:type)[b/*/foo='bar']
> {noformat}
> but it doesn't work currently.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8271) Lucene path transformed result doesn't accomodate wildcards in relative path
[
https://issues.apache.org/jira/browse/OAK-8271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825070#comment-16825070
]
Thomas Mueller commented on OAK-8271:
-
I will need to read the code to understand...
Before I do that, did you consider supporting "//" (for "one or multiple")? So
maybe things like the following:
{noformat}
/jcr:root/a//element(*, some:type)[@foo='bar']
/jcr:root/a//element(*, some:type)[*/@foo='bar'] one parent with any name
/jcr:root/a//element(*, some:type)[b/@foo='bar']
/jcr:root/a//element(*, some:type)[b/c/@foo='bar']
/jcr:root/a//element(*, some:type)[*/*/@foo='bar'] exactly two parents with any
name
/jcr:root/a//element(*, some:type)[b/*/@foo='bar']
/jcr:root/a//element(*, some:type)[*/b/@foo='bar']
/jcr:root/a//element(*, some:type)[b//*/@foo='bar'] at least two parents, first
one named b (b/c or b/c/d)
/jcr:root/a//element(*, some:type)[*//d/@foo='bar'] at least two parents, last
one named d (b/d or c/d or a/b/d)
/jcr:root/a//element(*, some:type)[*//@foo='bar'] at least one parent with any
name
/jcr:root/a//element(*, some:type)[a//@foo='bar'] at least one parent, first
one names a
{noformat}
There might be a few that are wrong.
> Lucene path transformed result doesn't accomodate wildcards in relative path
>
>
> Key: OAK-8271
> URL: https://issues.apache.org/jira/browse/OAK-8271
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
>
> {{LucenePropertyIndex}} support answering a query with property constraint on
> a relative path if there's an property (non-relative) is indexed on
> {{nt:base}}.
> e.g. with an index def such as
> {noformat}
> + /oak:index/fooIndex/indexRules/nt:base/properties
>+ foo
>- propertyIndex=true
> {noformat}
> we can answer queries such as
> {noformat}
> /jcr:root/a//element(*, some:type)[b/foo='bar']
> /jcr:root/a//element(*, some:type)[b/c/foo='bar']
> {noformat}
> In the same spirit it could also support query with wildcard in relative path
> fragment
> {noformat}
> /jcr:root/a//element(*, some:type)[b/*/foo='bar']
> {noformat}
> but it doesn't work currently.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8271) Lucene path transformed result doesn't accomodate wildcards in relative path
[
https://issues.apache.org/jira/browse/OAK-8271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825040#comment-16825040
]
Vikas Saurabh commented on OAK-8271:
The issue is that lucene implementation tries to match relative path fragment
with path of property (as stored in index) and returns only if relative path
fragment is a suffix. So, a diff like:
{noformat}
diff --git
a/oak-search/src/main/java/org/apache/jackrabbit/oak/plugins/index/search/spi/query/FulltextIndexPlanner.java
b/oak-search/src/main/java/org/apache/jackrabbit/oak/plugins/index/search/spi/query/FulltextIndexPlanner.java
index 08196b428f..231ac10296 100644
---
a/oak-search/src/main/java/org/apache/jackrabbit/oak/plugins/index/search/spi/query/FulltextIndexPlanner.java
+++
b/oak-search/src/main/java/org/apache/jackrabbit/oak/plugins/index/search/spi/query/FulltextIndexPlanner.java
@@ -1027,10 +1027,7 @@ public class FulltextIndexPlanner {
@Nullable
public String transformPath(String path){
if (isPathTransformed()){
-// get the base path
-// ensure the path ends with the given
-// relative path
-if (!path.endsWith(parentPathSegment)) {
+if (getDepth(path) < parentDepth) {
return null;
}
return getAncestorPath(path, parentDepth);
{noformat}
fixes the issue.
I feel this (fix) is the right approach anyway as this then leaves the
responsibility of matching relative path with whatever we support (wildcard
with prefix maybe) to query engine. [~tmueller] wdyt?
> Lucene path transformed result doesn't accomodate wildcards in relative path
>
>
> Key: OAK-8271
> URL: https://issues.apache.org/jira/browse/OAK-8271
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
>
> {{LucenePropertyIndex}} support answering a query with property constraint on
> a relative path if there's an property (non-relative) is indexed on
> {{nt:base}}.
> e.g. with an index def such as
> {noformat}
> + /oak:index/fooIndex/indexRules/nt:base/properties
>+ foo
>- propertyIndex=true
> {noformat}
> we can answer queries such as
> {noformat}
> /jcr:root/a//element(*, some:type)[b/foo='bar']
> /jcr:root/a//element(*, some:type)[b/c/foo='bar']
> {noformat}
> In the same spirit it could also support query with wildcard in relative path
> fragment
> {noformat}
> /jcr:root/a//element(*, some:type)[b/*/foo='bar']
> {noformat}
> but it doesn't work currently.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
