[
https://issues.apache.org/jira/browse/JCR-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12736602#action_12736602
]
Alexander Klimetschek commented on JCR-2233:
--------------------------------------------
> regarding a)
> no, the jcr:created was defined protected before and should stay this way.
Ok, but it was only defined protected for nt:file and nt:version. I am only
talking about the mix:created mixin and only nt:file inherits from it (nt:file
-> nt:hierarchyNode -> mix:created). Couldn't we make mix:created non-protected
and override the jcr:created property definition in nt:file to be protected to
ensure backwards compatibility? Looks ugly, but enhances compatibility and
consistency (if we do c below).
> session or workspace imports already respect this and (re)set the values
> correctly.
According to JCR-2195 protected properties are currently skipped completely.
And I was also thinking of custom "imports" that use the normal Node/Property
write methods.
> regarding c)
> as a simple implementation, i suggest to update the jcr:lastModified(By)
> properties if a significant
> modification is performed on the node (but not it's sub tree) and the
> property was not modified transiently.
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 (!?).
> it is to define what is considered as a significant modification.
> most probably:
>- add/remove child node (includes move/copy underneath)
>- add/remove/update properties
ack
> - add/remove mixins, change primary type
not sure... it's a change of the "schema", not the content
> most probably not:
>- versioning operations
>- locking operations
>- move (the node itself)
>- copy (the node itself)
ack
> 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.
