[
https://issues.apache.org/jira/browse/JCR-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12736873#action_12736873
]
Alexander Klimetschek commented on JCR-2233:
--------------------------------------------
> and might result in unexpected behaviors, such as properties are modified
> that are outside of the "scope" of you modifications.
I thought so as well, but actually this would not be a big problem, as the
client won't have to take care of calling save() for that. So the only thing
that might happen unexpectedly would be observation events, but I am not sure
if these should be triggered in that case (only for the content modified by the
client, but not the jcr:lastModified of the parent).
> JSR-283: mix:created/mix:lastModified - auto-set but allow modification for
> imports
> -----------------------------------------------------------------------------------
>
> Key: JCR-2233
> URL: https://issues.apache.org/jira/browse/JCR-2233
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core, JCR 2.0
> Reporter: Alexander Klimetschek
> Priority: Minor
> Fix For: 2.0.0
>
>
> Following the discussion in JCR-2116, I propose it would be a good idea to
> have jcr:created, jcr:createdBy (from mix:created) and jcr:lastModified,
> jcr:lastModifiedBy (mix:lastModified) not protected, but still automatically
> set those properties in case they were not modified by the client.
> Three advantages:
> a) This allows for importing content with these properties, where eg. the
> jcr:created should point to the original creation date of the content, not
> when it was imported.
> b) Same for jcr:lastModified, which often must be set manually for ensuring
> correct behaviour when doing synchronizations etc.
> c) In order to take advantage of the automatically-set behaviour mentioned in
> the spec, it would be nice if the repository would set them in the case the
> client is not writing those properties. This way you can ensure the
> properties are correctly set when you cannot control all client-code
> modifying the content (eg. webdav).
> Question: would this be in line with the spec? I would say, yes, since we say
> we don't implement "protected", which is allowed, but add a hybrid approach
> (which is not explicitly forbidden, IIUC).
> For the reference, here is the definition from the latest JSR-283 doc:
> [mix:lastModified] mixin
> - jcr:lastModified (DATE) autocreated protected? OPV?
> - jcr:lastModifiedBy (STRING) autocreated protected? OPV?
> [mix:created] mixin
> - jcr:created (DATE) autocreated protected? OPV?
> - jcr:createdBy (STRING) autocreated protected? OPV?
> And here is the current cnd definition in JR 2.0:
> http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/nodetype/builtin_nodetypes.cnd?view=co
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
