On 16.7.14 6:46 , Robert Munteanu wrote:

I know that /content/ugc is not interesting to my listener, so I can
exclude it by path. However, the basis of the exclusion can be
expressed more directly in the form of a property constraint,
something like [jcr:primaryType=my:ugcNode]. In practice the filtering
is a bit more complex, the condition would be: "Have a parent of type
my:Page until - but excluding - /content". However, I'm not sure if
this can be expressed concisely by a JackrabbitEventFilter or if the
evaluation can be done is an efficient manner by Oak.

Oak has quite powerful filter capabilities for observation. Filters that affect whole subtrees (like sub tree exclusion or inclusion) are the ones that are most beneficial wrt. performance as they allow for skipping whole parts of the tree.

The JackrabbitEventFilter is a dump storage object extending from JCR 2.1's EventFilter. It is used for passing filter parameters, which would otherwise be passed individually when registering an event listener. Using JackrabbitEventFilter for anything more complex than inclusion/exclusion would bend the initial too much IMO. We should probably think of ways to expose the extended filter capabilities through a richer API. A neat idea would be to reuse JCR's query syntax for this. However exposing a simple object model along with a builder would probably be simpler, more flexible, extensible and easier to maintain and use.

- User data exclusions would allow for excluding events with certain user
data. This could be useful if a session wants to bulk write some data
without the respective event handlers being fired. That session would just
need to set the user data to the same value as specified in the exclusion
filter.

What would be an example of user data? Property value constraints?

See ObservationManager.setUserData() and Event.getUserData(). It could be any string and its semantics would be specific to the usage.

Michael


Thanks,

Robert

Reply via email to