[
https://issues.apache.org/jira/browse/OAK-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14353231#comment-14353231
]
Michael Dürig commented on OAK-2262:
------------------------------------
As Oak doesn't keep track of the operation performed we can only provide sort
of a consolidated approximation of what has happened to a multi valued
property. The algorithm for calculating the sets of the indices of the
{{changed}}, {{added}} and {{removed}} properties might look something like
this:
{code}
for (int k = 0; k < min(beforeCount, afterCount); k++) {
if (!beforeValue[k].equals(afterValue[k])) {
changed.add(k);
}
}
if (beforeCount > afterCount) {
for (int k = afterCount; k < beforeCount; k++) {
removed.add(k);
}
} else if (afterCount > beforeCount) {
for (int k = beforeCount; k < afterCount; k++) {
added.add(k);
}
}
{code}
Of course this would reflect e.g. a deleting followed by an addition as a
change.
[~teofili], let me know whether this works for your case and whether we can
tweak this in a way that better suites you.
> Add metadata about the changed value to a PROPERTY_CHANGED event on a
> multivalued property
> ------------------------------------------------------------------------------------------
>
> Key: OAK-2262
> URL: https://issues.apache.org/jira/browse/OAK-2262
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, jcr
> Affects Versions: 1.1.2
> Reporter: Tommaso Teofili
> Assignee: Michael Dürig
> Labels: observation
> Fix For: 1.1.8
>
>
> When getting _PROPERTY_CHANGED_ events on non-multivalued properties only one
> value can have actually changed so that handlers of such events do not need
> any further information to process it and eventually work on the changed
> value; on the other hand _PROPERTY_CHANGED_ events on multivalued properties
> (e.g. String[]) may relate to any of the values and that brings a source of
> uncertainty on event handlers processing such changes because there's no mean
> to understand which property value had been changed and therefore to them to
> react accordingly.
> A workaround for that is to create Oak specific _Observers_ which can deal
> with the diff between before and after state and create a specific event
> containing the "diff", however this would add a non trivial load to the
> repository because of the _Observer_ itself and because of the additional
> events being generated while it'd be great if the 'default' events would have
> metadata e.g. of the changed value index or similar information that can help
> understanding which value has been changed (added, deleted, updated).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
