[jira] [Updated] (OAK-4636) PropertyIndexLookup#getIndexNode should be more tolerant towards property types
[
https://issues.apache.org/jira/browse/OAK-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4636:
---
Labels: (was: candidate_oak_1_0)
> PropertyIndexLookup#getIndexNode should be more tolerant towards property
> types
> ---
>
> Key: OAK-4636
> URL: https://issues.apache.org/jira/browse/OAK-4636
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.6, 1.0.33, 1.4.6, 1.2.18, 1.5.8
>
>
> Currently, {{PropertyIndexLookup#getIndexNode}} \[0] uses
> {{NodeState#getNames}} for {{propertyNames}} \[1] and {{declaringNodeTypes}}
> \[2]. That means that these properties need to be either of {{Name}} or
> {{Name\[]}} types. While that's ok and probably useful as well - this can
> potentially be used for validation and javadoc for getNames says that the
> implementation is free to use an optimized path.
> That being said, at least in one case (issue 768 in ensure oak index \[3])
> the values get set as {{String/String\[]}} instead which can very easily
> render useful indices like {{nodetype}} useless for the running system.
> I see 2 ways around it:
> * PropertyIndexLookup can be more resilient and accept non-Name-type too. For
> optimal case, we can probably try getNames() first and then fallback to
> getProperties with potential to cast (and may be log a warning for mistake in
> property type)
> * Proactively validate that properties such as declNodeTypes etc must have
> {{Name/Name\[]}} during commit
> I'm ok with any of the approach... but current scenario is too silent in
> failing... saving the change doesn't cause any issue... cost calculation
> while picking index simply ignore such indices.
> /cc [~tmueller], [~chetanm]
> \[0]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L159
> \[1]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L171
> \[2]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L179
> \[3]: https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/768
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4636) PropertyIndexLookup#getIndexNode should be more tolerant towards property types
[
https://issues.apache.org/jira/browse/OAK-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4636:
---
Fix Version/s: 1.0.33
> PropertyIndexLookup#getIndexNode should be more tolerant towards property
> types
> ---
>
> Key: OAK-4636
> URL: https://issues.apache.org/jira/browse/OAK-4636
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.6, 1.0.33, 1.4.6, 1.2.18, 1.5.8
>
>
> Currently, {{PropertyIndexLookup#getIndexNode}} \[0] uses
> {{NodeState#getNames}} for {{propertyNames}} \[1] and {{declaringNodeTypes}}
> \[2]. That means that these properties need to be either of {{Name}} or
> {{Name\[]}} types. While that's ok and probably useful as well - this can
> potentially be used for validation and javadoc for getNames says that the
> implementation is free to use an optimized path.
> That being said, at least in one case (issue 768 in ensure oak index \[3])
> the values get set as {{String/String\[]}} instead which can very easily
> render useful indices like {{nodetype}} useless for the running system.
> I see 2 ways around it:
> * PropertyIndexLookup can be more resilient and accept non-Name-type too. For
> optimal case, we can probably try getNames() first and then fallback to
> getProperties with potential to cast (and may be log a warning for mistake in
> property type)
> * Proactively validate that properties such as declNodeTypes etc must have
> {{Name/Name\[]}} during commit
> I'm ok with any of the approach... but current scenario is too silent in
> failing... saving the change doesn't cause any issue... cost calculation
> while picking index simply ignore such indices.
> /cc [~tmueller], [~chetanm]
> \[0]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L159
> \[1]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L171
> \[2]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L179
> \[3]: https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/768
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4636) PropertyIndexLookup#getIndexNode should be more tolerant towards property types
[
https://issues.apache.org/jira/browse/OAK-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4636:
---
Fix Version/s: 1.2.18
> PropertyIndexLookup#getIndexNode should be more tolerant towards property
> types
> ---
>
> Key: OAK-4636
> URL: https://issues.apache.org/jira/browse/OAK-4636
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Labels: candidate_oak_1_0
> Fix For: 1.6, 1.4.6, 1.2.18, 1.5.8
>
>
> Currently, {{PropertyIndexLookup#getIndexNode}} \[0] uses
> {{NodeState#getNames}} for {{propertyNames}} \[1] and {{declaringNodeTypes}}
> \[2]. That means that these properties need to be either of {{Name}} or
> {{Name\[]}} types. While that's ok and probably useful as well - this can
> potentially be used for validation and javadoc for getNames says that the
> implementation is free to use an optimized path.
> That being said, at least in one case (issue 768 in ensure oak index \[3])
> the values get set as {{String/String\[]}} instead which can very easily
> render useful indices like {{nodetype}} useless for the running system.
> I see 2 ways around it:
> * PropertyIndexLookup can be more resilient and accept non-Name-type too. For
> optimal case, we can probably try getNames() first and then fallback to
> getProperties with potential to cast (and may be log a warning for mistake in
> property type)
> * Proactively validate that properties such as declNodeTypes etc must have
> {{Name/Name\[]}} during commit
> I'm ok with any of the approach... but current scenario is too silent in
> failing... saving the change doesn't cause any issue... cost calculation
> while picking index simply ignore such indices.
> /cc [~tmueller], [~chetanm]
> \[0]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L159
> \[1]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L171
> \[2]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L179
> \[3]: https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/768
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4636) PropertyIndexLookup#getIndexNode should be more tolerant towards property types
[
https://issues.apache.org/jira/browse/OAK-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4636:
---
Labels: candidate_oak_1_0 (was: candidate_oak_1_0 candidate_oak_1_2)
> PropertyIndexLookup#getIndexNode should be more tolerant towards property
> types
> ---
>
> Key: OAK-4636
> URL: https://issues.apache.org/jira/browse/OAK-4636
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Labels: candidate_oak_1_0
> Fix For: 1.6, 1.4.6, 1.2.18, 1.5.8
>
>
> Currently, {{PropertyIndexLookup#getIndexNode}} \[0] uses
> {{NodeState#getNames}} for {{propertyNames}} \[1] and {{declaringNodeTypes}}
> \[2]. That means that these properties need to be either of {{Name}} or
> {{Name\[]}} types. While that's ok and probably useful as well - this can
> potentially be used for validation and javadoc for getNames says that the
> implementation is free to use an optimized path.
> That being said, at least in one case (issue 768 in ensure oak index \[3])
> the values get set as {{String/String\[]}} instead which can very easily
> render useful indices like {{nodetype}} useless for the running system.
> I see 2 ways around it:
> * PropertyIndexLookup can be more resilient and accept non-Name-type too. For
> optimal case, we can probably try getNames() first and then fallback to
> getProperties with potential to cast (and may be log a warning for mistake in
> property type)
> * Proactively validate that properties such as declNodeTypes etc must have
> {{Name/Name\[]}} during commit
> I'm ok with any of the approach... but current scenario is too silent in
> failing... saving the change doesn't cause any issue... cost calculation
> while picking index simply ignore such indices.
> /cc [~tmueller], [~chetanm]
> \[0]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L159
> \[1]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L171
> \[2]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L179
> \[3]: https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/768
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4636) PropertyIndexLookup#getIndexNode should be more tolerant towards property types
[
https://issues.apache.org/jira/browse/OAK-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4636:
---
Labels: candidate_oak_1_0 candidate_oak_1_2 (was: candidate_oak_1_0
candidate_oak_1_2 candidate_oak_1_4)
> PropertyIndexLookup#getIndexNode should be more tolerant towards property
> types
> ---
>
> Key: OAK-4636
> URL: https://issues.apache.org/jira/browse/OAK-4636
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2
> Fix For: 1.6, 1.4.6, 1.5.8
>
>
> Currently, {{PropertyIndexLookup#getIndexNode}} \[0] uses
> {{NodeState#getNames}} for {{propertyNames}} \[1] and {{declaringNodeTypes}}
> \[2]. That means that these properties need to be either of {{Name}} or
> {{Name\[]}} types. While that's ok and probably useful as well - this can
> potentially be used for validation and javadoc for getNames says that the
> implementation is free to use an optimized path.
> That being said, at least in one case (issue 768 in ensure oak index \[3])
> the values get set as {{String/String\[]}} instead which can very easily
> render useful indices like {{nodetype}} useless for the running system.
> I see 2 ways around it:
> * PropertyIndexLookup can be more resilient and accept non-Name-type too. For
> optimal case, we can probably try getNames() first and then fallback to
> getProperties with potential to cast (and may be log a warning for mistake in
> property type)
> * Proactively validate that properties such as declNodeTypes etc must have
> {{Name/Name\[]}} during commit
> I'm ok with any of the approach... but current scenario is too silent in
> failing... saving the change doesn't cause any issue... cost calculation
> while picking index simply ignore such indices.
> /cc [~tmueller], [~chetanm]
> \[0]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L159
> \[1]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L171
> \[2]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L179
> \[3]: https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/768
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4636) PropertyIndexLookup#getIndexNode should be more tolerant towards property types
[
https://issues.apache.org/jira/browse/OAK-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4636:
---
Fix Version/s: (was: 1.6.)
1.4.6
1.6
> PropertyIndexLookup#getIndexNode should be more tolerant towards property
> types
> ---
>
> Key: OAK-4636
> URL: https://issues.apache.org/jira/browse/OAK-4636
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2
> Fix For: 1.6, 1.4.6, 1.5.8
>
>
> Currently, {{PropertyIndexLookup#getIndexNode}} \[0] uses
> {{NodeState#getNames}} for {{propertyNames}} \[1] and {{declaringNodeTypes}}
> \[2]. That means that these properties need to be either of {{Name}} or
> {{Name\[]}} types. While that's ok and probably useful as well - this can
> potentially be used for validation and javadoc for getNames says that the
> implementation is free to use an optimized path.
> That being said, at least in one case (issue 768 in ensure oak index \[3])
> the values get set as {{String/String\[]}} instead which can very easily
> render useful indices like {{nodetype}} useless for the running system.
> I see 2 ways around it:
> * PropertyIndexLookup can be more resilient and accept non-Name-type too. For
> optimal case, we can probably try getNames() first and then fallback to
> getProperties with potential to cast (and may be log a warning for mistake in
> property type)
> * Proactively validate that properties such as declNodeTypes etc must have
> {{Name/Name\[]}} during commit
> I'm ok with any of the approach... but current scenario is too silent in
> failing... saving the change doesn't cause any issue... cost calculation
> while picking index simply ignore such indices.
> /cc [~tmueller], [~chetanm]
> \[0]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L159
> \[1]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L171
> \[2]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L179
> \[3]: https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/768
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4636) PropertyIndexLookup#getIndexNode should be more tolerant towards property types
[
https://issues.apache.org/jira/browse/OAK-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4636:
---
Labels: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4 (was: )
> PropertyIndexLookup#getIndexNode should be more tolerant towards property
> types
> ---
>
> Key: OAK-4636
> URL: https://issues.apache.org/jira/browse/OAK-4636
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.5.8, 1.6.
>
>
> Currently, {{PropertyIndexLookup#getIndexNode}} \[0] uses
> {{NodeState#getNames}} for {{propertyNames}} \[1] and {{declaringNodeTypes}}
> \[2]. That means that these properties need to be either of {{Name}} or
> {{Name\[]}} types. While that's ok and probably useful as well - this can
> potentially be used for validation and javadoc for getNames says that the
> implementation is free to use an optimized path.
> That being said, at least in one case (issue 768 in ensure oak index \[3])
> the values get set as {{String/String\[]}} instead which can very easily
> render useful indices like {{nodetype}} useless for the running system.
> I see 2 ways around it:
> * PropertyIndexLookup can be more resilient and accept non-Name-type too. For
> optimal case, we can probably try getNames() first and then fallback to
> getProperties with potential to cast (and may be log a warning for mistake in
> property type)
> * Proactively validate that properties such as declNodeTypes etc must have
> {{Name/Name\[]}} during commit
> I'm ok with any of the approach... but current scenario is too silent in
> failing... saving the change doesn't cause any issue... cost calculation
> while picking index simply ignore such indices.
> /cc [~tmueller], [~chetanm]
> \[0]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L159
> \[1]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L171
> \[2]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/PropertyIndexLookup.java#L179
> \[3]: https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/768
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
