You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Alexander Klimetschek (JIRA)" <ji...@apache.org> on 2009/07/29 13:30:14 UTC
[jira] Created: (JCR-2233) JSR-283: mix:created/mix:lastModified -
auto-set but allow modification for imports
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.
[jira] Commented: (JCR-2233) JSR-283: mix:created/mix:lastModified
- auto-set but allow modification for imports
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12736606#action_12736606 ]
Stefan Guggisberg commented on JCR-2233:
----------------------------------------
> 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).
we don't support overriding item definitions declared in supertypes
> 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.
[jira] Commented: (JCR-2233) JSR-283: mix:created/mix:lastModified
- auto-set but allow modification for imports
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JCR-2233) JSR-283: mix:created/mix:lastModified
- auto-set but allow modification for imports
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799695#action_12799695 ]
Jukka Zitting commented on JCR-2233:
------------------------------------
Do we need this for Jackrabbit 2.0?
> 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.
[jira] Updated: (JCR-2233) mix:lastModified - auto-set but allow
modification for imports
Posted by "Alexander Klimetschek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexander Klimetschek updated JCR-2233:
---------------------------------------
Summary: mix:lastModified - auto-set but allow modification for imports (was: JSR-283: mix:created/mix:lastModified - auto-set but allow modification for imports)
> Do we need this for Jackrabbit 2.0?
Not necessarily. Auto-setting the jcr:lastModified property could be added later, IMHO. It does not break the spec, because we don't define those properties as protected. Also, implementation would need some testing, which would only block 2.0.
Thus changing title because
- we cannot change the jcr:created behavior without introducing backwards compat issues
- it is no longer directly related to JSR-283
> 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.
[jira] Commented: (JCR-2233) JSR-283: mix:created/mix:lastModified
- auto-set but allow modification for imports
Posted by "Alexander Klimetschek (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JCR-2233) JSR-283: mix:created/mix:lastModified
- auto-set but allow modification for imports
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12737023#action_12737023 ]
Marcel Reutegger commented on JCR-2233:
---------------------------------------
> 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).
events must be triggered for jcr:lastModified! see previous discussion on the dev list:
http://www.nabble.com/behavior-of-jcr:lastModified-in-jackrabbit-2.0-to24082205.html
> 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.
[jira] Updated: (JCR-2233) mix:lastModified - auto-set but allow
modification for imports
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger updated JCR-2233:
----------------------------------
Fix Version/s: (was: 2.0.0)
As discussed, this is not required for the 2.0 release.
> 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
>
> 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.
[jira] Commented: (JCR-2233) JSR-283: mix:created/mix:lastModified
- auto-set but allow modification for imports
Posted by "Alexander Klimetschek (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JCR-2233) JSR-283: mix:created/mix:lastModified
- auto-set but allow modification for imports
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12736575#action_12736575 ]
Tobias Bocanegra commented on JCR-2233:
---------------------------------------
regarding a)
no, the jcr:created was defined protected before and should stay this way. session or workspace imports already respect this and (re)set the values correctly.
regarding b)
this is already the case, i.e. not protected
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.
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
- add/remove mixins, change primary type
most probably not:
- versioning operations
- locking operations
- move (the node itself)
- copy (the node itself)
> 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.
[jira] Commented: (JCR-2233) JSR-283: mix:created/mix:lastModified
- auto-set but allow modification for imports
Posted by "Alexander Klimetschek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12736770#action_12736770 ]
Alexander Klimetschek commented on JCR-2233:
--------------------------------------------
> we don't support overriding item definitions declared in supertypes
Ok, then there is no real backwards compatible solution for jcr:created (and thus createdBy if they shouldn't differ). Actually that's ok for my use-case, the property is not that important that it couldn't be re-set on import.
So this issue is now solely about mix:lastModified.
> 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.