[
https://issues.apache.org/jira/browse/OAK-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-5011:
-----------------------------
Attachment: OAK-5011.patch
Attaching [^OAK-5011.patch] with a suggestion for how this aggregation could
look like
> Add event aggregation support to observation filtering
> ------------------------------------------------------
>
> Key: OAK-5011
> URL: https://issues.apache.org/jira/browse/OAK-5011
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, jcr
> Affects Versions: 1.5.12
> Reporter: Stefan Egli
> Assignee: Stefan Egli
> Attachments: OAK-5011.patch
>
>
> Currently the observation filtering 'subsystem' allows only the creation of
> events with the path and identifier set to the parent of where the change
> happened. To support features like JCR-4046 we need some sort of event
> 'aggregation'. The idea is that while the change happened somewhere in a
> subtree it would still be reported with the {{event.getIdentifier()}} set on
> some parent/aggregator node (the {{event.getPath()}} would still be the
> actual change).
> To support this, the suggestion is to add a {{EventAggregator}} to the
> {{FilterBuilder}} which would be invoked right before the actual event is
> being created, but after the filtering happened, so it would only affect how
> the event looks like, not whether or not the event is generated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
