[ 
https://issues.apache.org/jira/browse/OAK-4940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15581755#comment-15581755
 ] 

Stefan Egli edited comment on OAK-4940 at 10/17/16 9:53 AM:
------------------------------------------------------------

Ok, I would suggest to wait until we -have a use case for- actually implement 
this - atm we'd be collecting it for no-one to actually filter for. So as soon 
as we add this to the filter we might better see if it's good or not so good to 
put the ancestors' node types in the same bucket as the parent (my fear is that 
it lessens filter precision)


was (Author: egli):
Ok, I would suggest to wait until we have a use case for this - atm we'd be 
collecting it for no-one to actually filter for. So as soon as we add this to 
the filter we might better see if it's good or not so good to put the 
ancestors' node types in the same bucket as the parent (my fear is that it 
lessens filter precision)

> Consider collecting grand-parent changes in ChangeSet
> -----------------------------------------------------
>
>                 Key: OAK-4940
>                 URL: https://issues.apache.org/jira/browse/OAK-4940
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.5.12
>            Reporter: Stefan Egli
>             Fix For: 1.6
>
>
> At the moment the ChangeSet, which is populated by ChangeCollectorProvider (a 
> Validator) during a commit, collects changed property names, as well as node 
> name, node type and path of the parent (whereas _parent_ for a property 
> change is its node, while for a node change is actually its parent).
> For improvements such as SLING-6163 it might be valuable to collect 
> grand-parent changes (node name, node type and perhaps path) too. We could 
> extend the ChangeSet with additional, explicit grand-parent sets (ie we 
> should not mix them with the parent changes as that would lessen filtering 
> rate)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to