Ate Douma created JCR-4455: ------------------------------ Summary: 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 Affects Versions: 2.18.2 Reporter: Ate Douma
[~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 (v7.6.3#76005)