jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (Jira)" <j...@apache.org>
Subject [jira] [Updated] (JCR-4455) condition index-rule handling more broken after JCR-4339
Date Wed, 04 Sep 2019 15:54:00 GMT

     [ https://issues.apache.org/jira/browse/JCR-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Julian Reschke updated JCR-4455:
--------------------------------
    Fix Version/s: 2.14.8

> condition index-rule handling more broken after JCR-4339
> --------------------------------------------------------
>
>                 Key: JCR-4455
>                 URL: https://issues.apache.org/jira/browse/JCR-4455
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 2.18.2
>            Reporter: Ate Douma
>            Assignee: Claus Köll
>            Priority: Major
>              Labels: candidate_jcr_2_14
>             Fix For: 2.20, 2.16.5, 2.19.4, 2.18.3, 2.14.8
>
>         Attachments: JCR-4455.patch, exposing-JCR-4455.patch
>
>
> [~c_koell]
> When reviewing the fix applied for JCR-4339 before going through an upgrade to 2.18.2,
I noticed that, while it fixes the reported problem, it does so only in simple ('happy path')
scenarios. Now it is broken when trying to use multiple index-rule definitions for one node
type.
> The logic for finding the applicable indexing rule for a specific property no longer
considers (checks) if the there is a condition for that property. Instead, that check is postponed/moved
to the method *calling* #getApplicableIndexingRule.
>  But this is incorrect because now the #getApplicableIndexingRule method returns the
first *type* matching rule, regardless of the *property* it should be applicable for.
> For example, it is perfectly feasible, and sometimes even needed, to have multiple index-rules
for the same node type, like the following enhanced version of test resource indexing_config6.xml,
which can be used to verify the logic now is broken:
> {code:xml}
> <index-rule nodeType="nt:unstructured">
>     <property>other</property>
> </index-rule>
> <index-rule nodeType="nt:unstructured" condition="@foo = 'high'">
>     <property>foo</property>
> </index-rule>{code}
>  The important points to expose the new bug is:
>  * the index-rule for property other is defined *before* the index-rule for property
foo
>  * (for this example) the index-rule for property other doesn't have a condition
> With the above, the property foo will *not* be indexed, regardless its value, because
the first 'matching' rule returned from #getApplicableIndexingRule for a node of type nt:unstructured
will be the rule for property other. But will always return false on the (now postponed/delegated)
call to rule.isIndexed(propertyName: foo), because *that* rule doesn't has a propertyConfig
for foo (only for other).
> I'll attach a patch (based on trunk) to demonstrate the above failing using the new IndexingConfigurationImplTest#testMatchCondition
test.
> Note that the current #testMatchCondition() test itself also is broken: it actually *does
not* test the intended condition, but tests for it to *not* match using assertFalse instead
of assertTrue.
>  Which indeed is needed to pass the test because the indexing_config6.xml configuration
file itself contains an invalid (incomplete) index-rule.
> Instead of the current content:
> {code:xml}
> <index-rule nodeType="nt:unstructured" condition="@foo = 'high'">
> </index-rule>{code}
> it actually should be: 
> {code:xml}
> <index-rule nodeType="nt:unstructured" condition="@foo = 'high'">
>     <property>foo</property>
> </index-rule>{code}
> to pass the test with assertTrue.
> I'll also fix that test method in my patch, which then however will fail, because of
the above reported problem.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Mime
View raw message