[
https://issues.apache.org/jira/browse/OAK-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13580547#comment-13580547
]
Jukka Zitting commented on OAK-533:
-----------------------------------
Nice work, thanks! A few comments/suggestions:
* I like the {{NodeTypeCommitHook}} base class! It seems like we could further
generalize this approach to unify it with the somewhat similar stuff that goes
on in {{IndexHookManager}}, but that's probably a topic for another issue.
* In {{NodeTypeCommitHook.procesCommit}} we should use something like {{new
ReadOnlyNodeTypeManager.getInstance(after).getNodeType(nodeType).getSubtypes()}}
to find out also all the possible subtypes that could/should trigger
type-related hook functionality. The node type checks later in the code would
then be done using {{Set.contains()}} on the resulting set of types instead of
with {{String.equals()}} on just the explicitly provided type name.
* It would be better if the last modified timestamp and last modifier username
were calculated once at the beginning of {{processCommit()}} for the entire
commit instead of repeatedly for each modified node.
* I'm not sure if the {{AllChangesNodeStateDiff}} mechanism is really needed.
When hitting the {{processChangedNode()}} we already know that the node is
modified, so we could just update the modification properties directly unless
they have been explicitly updated by the client (which we can check without a
content diff by directly comparing the relevant {{getProperty()}} values from
the before and after states).
* Instead of the {{AllChangesNodeStateDiff}}, I'd make the
{{ModifiedNodeStateDiff}} class recurse down the content diff to find all
modified nodes and call {{processChangedNode}} on them. That way the code will
work correctly even if the modified {{mix:lastModified}} nodes aren't direct
children of the root.
> Define behaviour for and implement mix:lastModified
> ---------------------------------------------------
>
> Key: OAK-533
> URL: https://issues.apache.org/jira/browse/OAK-533
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: jcr
> Reporter: Michael Dürig
>
> There has been quite some discussion how to best implement
> {{mix:lastModified}} for Jackrabbit 2:
> https://issues.apache.org/jira/browse/JCR-2116
> https://issues.apache.org/jira/browse/JCR-2233
> http://markmail.org/thread/ygaktajwdz4z4r5m
> I think we should try to do it right from the start in Oak.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
