Oak would be collecting the name of the properties (OAK-4907) which got changed in a given commit and that can be used for filtering. This I think should help the MapEntries case and probably the resourceType case also. They can just hint for those property names and then listener would only be called if there is some change in those properties
> I would rather go with a "property names filter hint" - and if we detect other use cases we add another property for that. Makes sense. This would keep things simple and precise > Yes, and as mentioned a check based on a resource type is not that easy, Can you provide some details on what kind of change the impl is interested in. Is it change in the value of resourceType property? Any pseudo code of the kind of logic that listener would be performing. That would help in determining if we can make this case faster Chetan Mehrotra On Sat, Oct 15, 2016 at 7:51 PM, Carsten Ziegeler <cziege...@apache.org> wrote: > Dominik Süß wrote >> For me one of the most interesting filters for "native" filtering would be >> based on ResourceType (& RT changes). Optimally we would even have the >> option to filter by ResourceType and its SubTypes - but detecting the >> subtypes is something that would go beyond a hint (basically preprocessing >> a hint to "unfold" it into all of the subtypes to watch out for). >> >> I guess within the ResourceTypes the best practice would go into the >> direction of SubTyping whenever the group covered is too generic and needs >> to be treated differently. >> > Yes, and as mentioned a check based on a resource type is not that easy, > you need to check the resource type property, the super type property, > maybe the jcr primary node type and then also walk up the resource type > hierarchy. > If Oak would provide a hook for registering these additional checks then > we "maybe" could do it. > > Carsten > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
