jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vikas Saurabh (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OAK-4636) PropertyIndexLookup#getIndexNode should be more tolerant towards property types
Date Tue, 09 Aug 2016 01:17:20 GMT

     [ 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)

Mime
View raw message