Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Thu, 21 Mar 2013 22:47:15 +0000 (UTC)
From: =?utf-8?Q?Uwe_J=C3=A4ger_=28JIRA=29?= <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: <JIRA.12431681.1248866971565.30969.1363906035397@arcas>
In-Reply-To: <JIRA.12431681.1248866971565@arcas>
References: <JIRA.12431681.1248866971565@arcas>
Subject: [jira] [Commented] (JCR-2233) mix:lastModified - auto-set but allow
 modification for imports
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/JCR-2233?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D136096=
34#comment-13609634 ]=20

Uwe J=C3=A4ger commented on JCR-2233:
--------------------------------

Any plans for having automatic setting of lastModified implemented?

Cheers
Uwe
               =20
> 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 t=
o have jcr:created, jcr:createdBy (from mix:created) and jcr:lastModified, =
jcr:lastModifiedBy (mix:lastModified) not protected, but still automaticall=
y 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 ensuri=
ng correct behaviour when doing synchronizations etc.
> c) In order to take advantage of the automatically-set behaviour mentione=
d in the spec, it would be nice if the repository would set them in the cas=
e the client is not writing those properties. This way you can ensure the p=
roperties are correctly set when you cannot control all client-code modifyi=
ng 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 app=
roach (which is not explicitly forbidden, IIUC).
> For the reference, here is the definition from the latest JSR-283 doc:
> [mix:lastModified] mixin=20
>   - jcr:lastModified (DATE) autocreated protected? OPV?=20
>   - jcr:lastModifiedBy (STRING) autocreated protected? OPV?=20
> [mix:created] mixin=20
>   - jcr:created (DATE) autocreated protected? OPV?=20
>   - jcr:createdBy (STRING) autocreated protected? OPV?=20
> And here is the current cnd definition in JR 2.0:
> http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/re=
sources/org/apache/jackrabbit/core/nodetype/builtin_nodetypes.cnd?view=3Dco

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira