[
https://issues.apache.org/jira/browse/JCR-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12736795#action_12736795
]
Tobias Bocanegra commented on JCR-2233:
---------------------------------------
> > - add/remove mixins, change primary type
> not sure... it's a change of the "schema", not the content
i agree - i thought it depends on the use case, but i can't think of any, right
now :-)
> Subtree modification handling would be cool, but it would require a traversal
> up to the
> root node on each node/property add/remove/modify to find parents with a >
> mix:lastModified mixin.
> This wouldn't be difficult, but could slow down things (!?).
not difficult, by slow. and might result in unexpected behaviors, such as
properties are modified that are outside of the "scope" of you modifications.
> 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.
