Mailing-List: contact dev-help@chemistry.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@chemistry.apache.org
Date: Fri, 27 Apr 2012 19:02:49 +0000 (UTC)
From: =?utf-8?Q?Florian_M=C3=BCller_=28JIRA=29?= <jira@apache.org>
To: dev@chemistry.apache.org
Message-ID: 
 <529421960.3922.1335553369353.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <719274734.3670.1335548570737.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CMIS-528) AbstractCmisObject.updateProperties
 newObjectId handing when refresh=true
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CMIS-528?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D132638=
89#comment-13263889 ]=20

Florian M=C3=BCller commented on CMIS-528:
-------------------------------------

In order to be consistent, the object id of a CmisObject should never chang=
e. Once you have fetched an object, you can refresh it and you always get t=
he current data of the object you have fetched in the first place.
That's a basic principle. I don't think there is a wrong or right here.
If you like to get the updated object, use the other updateProperties() met=
hod.

If the modification of a document triggered the creation of a new version, =
it very likely that the versioning properties (cmis:isLatestVersion, cmis:i=
sMajorVersion, cmis:isLatestMajorVersion) of the origin document version ha=
ve been changed.
Some repositories also change the cmis:lastModifiedBy and cmis:lastModifica=
tionDate properties of the origin document.
If the modification created a PWC, also the version series properties (cmis=
:isVersionSeriesCheckedOut, cmis:versionSeriesCheckedOutBy, cmis:versionSer=
iesCheckedOutId) are changed.
It's also very likely that allowable actions changed and some repositories =
are modifying the ACL and maybe the policies of the origin version in this =
case.
Some repositories maintain relationships only on the latest version. So, th=
ose might have changed too on the origin object.

There are good reasons to update the origin document.
               =20
> AbstractCmisObject.updateProperties newObjectId handing when refresh=3Dtr=
ue
> -------------------------------------------------------------------------
>
>                 Key: CMIS-528
>                 URL: https://issues.apache.org/jira/browse/CMIS-528
>             Project: Chemistry
>          Issue Type: Bug
>          Components: opencmis-client
>    Affects Versions: OpenCMIS 0.7.0
>            Reporter: Chris Hubick
>            Priority: Minor
>
> There is a method: public ObjectId AbstractCmisObject.updateProperties(Ma=
p<String, ?> properties, boolean refresh) for which the Javadoc (on CmisObj=
ect) says:
> @param refresh indicates if the object should be refresh after the update
> @return the object id of the updated object (a repository might have crea=
ted a new object)
> One would logically expect then, if you supply refresh=3Dtrue, that when =
the update operation upon this object has completed, that it will then cont=
ain those property values just set.  This would imply that if a new object =
id *is* returned for the object containing those updated values, that the A=
bstractCmisObject object will be updated to point to that new id?
> That does not appear to be the case within the method implementation, whi=
ch appears to refresh the object with the property values from the *old* ob=
ject id.
> Even if it's intended that the AbstractCmisObject *not* be pointed to the=
 updated id, it would then seem prudent to check if a new id was issued, an=
d skip the refresh call in that case?
> Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira