[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path
[
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-7254:
Labels: indexingPatch mohit (was: indexingPatch)
> Indexes with excludedPaths, or includedPaths should not be picked for queries
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Labels: indexingPatch, mohit
> Fix For: 1.16.0
>
> Attachments:
> 0001-OAK-7254-Indexes-with-excludedPaths-or-includedPaths.patch,
> OAK-7254-B.patch, OAK-7254-C.patch
>
>
> Queries that don't have a clear path restriction should not use indexes that
> have excludedPaths or includedPaths set, except in some exceptional cases (to
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be
> used, at least not if a different index is available. Currently it is used
> currently, actually in _favor_ of another index, if the property "status" is
> commonly used in /etc. Because of that, the index that doesn't have
> excludedPath has a higher cost (as it indexes the property "status" in /etc,
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path
[
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-7254:
Attachment: OAK-7254-C.patch
> Indexes with excludedPaths, or includedPaths should not be picked for queries
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Labels: indexingPatch
> Fix For: 1.16.0
>
> Attachments:
> 0001-OAK-7254-Indexes-with-excludedPaths-or-includedPaths.patch,
> OAK-7254-B.patch, OAK-7254-C.patch
>
>
> Queries that don't have a clear path restriction should not use indexes that
> have excludedPaths or includedPaths set, except in some exceptional cases (to
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be
> used, at least not if a different index is available. Currently it is used
> currently, actually in _favor_ of another index, if the property "status" is
> commonly used in /etc. Because of that, the index that doesn't have
> excludedPath has a higher cost (as it indexes the property "status" in /etc,
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path
[
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-7254:
Attachment: OAK-7254-B.patch
> Indexes with excludedPaths, or includedPaths should not be picked for queries
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Labels: indexingPatch
> Fix For: 1.16.0
>
> Attachments:
> 0001-OAK-7254-Indexes-with-excludedPaths-or-includedPaths.patch,
> OAK-7254-B.patch
>
>
> Queries that don't have a clear path restriction should not use indexes that
> have excludedPaths or includedPaths set, except in some exceptional cases (to
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be
> used, at least not if a different index is available. Currently it is used
> currently, actually in _favor_ of another index, if the property "status" is
> commonly used in /etc. Because of that, the index that doesn't have
> excludedPath has a higher cost (as it indexes the property "status" in /etc,
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path
[
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohit Kataria updated OAK-7254:
---
Attachment: 0001-OAK-7254-Indexes-with-excludedPaths-or-includedPaths.patch
> Indexes with excludedPaths, or includedPaths should not be picked for queries
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Labels: indexingPatch
> Fix For: 1.16.0
>
> Attachments:
> 0001-OAK-7254-Indexes-with-excludedPaths-or-includedPaths.patch
>
>
> Queries that don't have a clear path restriction should not use indexes that
> have excludedPaths or includedPaths set, except in some exceptional cases (to
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be
> used, at least not if a different index is available. Currently it is used
> currently, actually in _favor_ of another index, if the property "status" is
> commonly used in /etc. Because of that, the index that doesn't have
> excludedPath has a higher cost (as it indexes the property "status" in /etc,
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path
[
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-7254:
Labels: indexingPatch (was: )
> Indexes with excludedPaths, or includedPaths should not be picked for queries
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Labels: indexingPatch
> Fix For: 1.16.0
>
>
> Queries that don't have a clear path restriction should not use indexes that
> have excludedPaths or includedPaths set, except in some exceptional cases (to
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be
> used, at least not if a different index is available. Currently it is used
> currently, actually in _favor_ of another index, if the property "status" is
> commonly used in /etc. Because of that, the index that doesn't have
> excludedPath has a higher cost (as it indexes the property "status" in /etc,
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path
[
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7254:
--
Fix Version/s: (was: 1.14.0)
> Indexes with excludedPaths, or includedPaths should not be picked for queries
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.16.0
>
>
> Queries that don't have a clear path restriction should not use indexes that
> have excludedPaths or includedPaths set, except in some exceptional cases (to
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be
> used, at least not if a different index is available. Currently it is used
> currently, actually in _favor_ of another index, if the property "status" is
> commonly used in /etc. Because of that, the index that doesn't have
> excludedPath has a higher cost (as it indexes the property "status" in /etc,
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path
[
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7254:
--
Fix Version/s: 1.16.0
> Indexes with excludedPaths, or includedPaths should not be picked for queries
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.14.0, 1.16.0
>
>
> Queries that don't have a clear path restriction should not use indexes that
> have excludedPaths or includedPaths set, except in some exceptional cases (to
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be
> used, at least not if a different index is available. Currently it is used
> currently, actually in _favor_ of another index, if the property "status" is
> commonly used in /etc. Because of that, the index that doesn't have
> excludedPath has a higher cost (as it indexes the property "status" in /etc,
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path
[
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-7254:
Sprint: (was: L16)
> Indexes with excludedPaths, or includedPaths should not be picked for queries
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.14.0
>
>
> Queries that don't have a clear path restriction should not use indexes that
> have excludedPaths or includedPaths set, except in some exceptional cases (to
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be
> used, at least not if a different index is available. Currently it is used
> currently, actually in _favor_ of another index, if the property "status" is
> commonly used in /etc. Because of that, the index that doesn't have
> excludedPath has a higher cost (as it indexes the property "status" in /etc,
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path
[
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7254:
--
Fix Version/s: (was: 1.12.0)
> Indexes with excludedPaths, or includedPaths should not be picked for queries
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.14.0
>
>
> Queries that don't have a clear path restriction should not use indexes that
> have excludedPaths or includedPaths set, except in some exceptional cases (to
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be
> used, at least not if a different index is available. Currently it is used
> currently, actually in _favor_ of another index, if the property "status" is
> commonly used in /etc. Because of that, the index that doesn't have
> excludedPath has a higher cost (as it indexes the property "status" in /etc,
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path
[
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7254:
--
Fix Version/s: 1.14.0
> Indexes with excludedPaths, or includedPaths should not be picked for queries
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.12.0, 1.14.0
>
>
> Queries that don't have a clear path restriction should not use indexes that
> have excludedPaths or includedPaths set, except in some exceptional cases (to
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be
> used, at least not if a different index is available. Currently it is used
> currently, actually in _favor_ of another index, if the property "status" is
> commonly used in /etc. Because of that, the index that doesn't have
> excludedPath has a higher cost (as it indexes the property "status" in /etc,
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path
[
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7254:
--
Fix Version/s: (was: 1.10.0)
> Indexes with excludedPaths, or includedPaths should not be picked for queries
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.12
>
>
> Queries that don't have a clear path restriction should not use indexes that
> have excludedPaths or includedPaths set, except in some exceptional cases (to
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be
> used, at least not if a different index is available. Currently it is used
> currently, actually in _favor_ of another index, if the property "status" is
> commonly used in /etc. Because of that, the index that doesn't have
> excludedPath has a higher cost (as it indexes the property "status" in /etc,
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path
[
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7254:
--
Fix Version/s: 1.12
> Indexes with excludedPaths, or includedPaths should not be picked for queries
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.10.0, 1.12
>
>
> Queries that don't have a clear path restriction should not use indexes that
> have excludedPaths or includedPaths set, except in some exceptional cases (to
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be
> used, at least not if a different index is available. Currently it is used
> currently, actually in _favor_ of another index, if the property "status" is
> commonly used in /etc. Because of that, the index that doesn't have
> excludedPath has a higher cost (as it indexes the property "status" in /etc,
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path
[
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-7254:
Sprint: L16
> Indexes with excludedPaths, or includedPaths should not be picked for queries
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Matt Ryan
>Priority: Critical
> Fix For: 1.10
>
>
> Queries that don't have a clear path restriction should not use indexes that
> have excludedPaths or includedPaths set, except in some exceptional cases (to
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be
> used, at least not if a different index is available. Currently it is used
> currently, actually in _favor_ of another index, if the property "status" is
> commonly used in /etc. Because of that, the index that doesn't have
> excludedPath has a higher cost (as it indexes the property "status" in /etc,
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path
[
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-7254:
Priority: Critical (was: Major)
> Indexes with excludedPaths, or includedPaths should not be picked for queries
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
>Reporter: Thomas Mueller
>Priority: Critical
> Fix For: 1.10
>
>
> Queries that don't have a clear path restriction should not use indexes that
> have excludedPaths or includedPaths set, except in some exceptional cases (to
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be
> used, at least not if a different index is available. Currently it is used
> currently, actually in _favor_ of another index, if the property "status" is
> commonly used in /etc. Because of that, the index that doesn't have
> excludedPath has a higher cost (as it indexes the property "status" in /etc,
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
