Chemistry
  1. Chemistry
  2. CMIS-528

AbstractCmisObject.updateProperties newObjectId handing when refresh=true

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: OpenCMIS 0.7.0
    • Fix Version/s: None
    • Component/s: opencmis-client
    • Labels:
      None

      Description

      There is a method: public ObjectId AbstractCmisObject.updateProperties(Map<String, ?> properties, boolean refresh) for which the Javadoc (on CmisObject) 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 created a new object)

      One would logically expect then, if you supply refresh=true, that when the update operation upon this object has completed, that it will then contain 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 AbstractCmisObject object will be updated to point to that new id?

      That does not appear to be the case within the method implementation, which appears to refresh the object with the property values from the old object 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, and skip the refresh call in that case?

      Thanks.

        Activity

        Hide
        Chris Hubick added a comment -

        It would appear that this issue also exists in other methods, such as DocumentImpl.setContentStream(ContentStream contentStream, boolean overwrite, boolean refresh).

        Show
        Chris Hubick added a comment - It would appear that this issue also exists in other methods, such as DocumentImpl.setContentStream(ContentStream contentStream, boolean overwrite, boolean refresh).
        Hide
        Florian Müller added a comment -

        In order to be consistent, the object id of a CmisObject should never change. Once you have fetched an object, you can refresh it and you always get the 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() method.

        If the modification of a document triggered the creation of a new version, it very likely that the versioning properties (cmis:isLatestVersion, cmis:isMajorVersion, cmis:isLatestMajorVersion) of the origin document version have been changed.
        Some repositories also change the cmis:lastModifiedBy and cmis:lastModificationDate properties of the origin document.
        If the modification created a PWC, also the version series properties (cmis:isVersionSeriesCheckedOut, cmis:versionSeriesCheckedOutBy, cmis:versionSeriesCheckedOutId) 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, those might have changed too on the origin object.

        There are good reasons to update the origin document.

        Show
        Florian Müller added a comment - In order to be consistent, the object id of a CmisObject should never change. Once you have fetched an object, you can refresh it and you always get the 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() method. If the modification of a document triggered the creation of a new version, it very likely that the versioning properties (cmis:isLatestVersion, cmis:isMajorVersion, cmis:isLatestMajorVersion) of the origin document version have been changed. Some repositories also change the cmis:lastModifiedBy and cmis:lastModificationDate properties of the origin document. If the modification created a PWC, also the version series properties (cmis:isVersionSeriesCheckedOut, cmis:versionSeriesCheckedOutBy, cmis:versionSeriesCheckedOutId) 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, those might have changed too on the origin object. There are good reasons to update the origin document.
        Hide
        Chris Hubick added a comment -

        Ok, that's fair. Some clarifications to this effect within the Javadoc for 'refresh' might be nice Much Thanks.

        Show
        Chris Hubick added a comment - Ok, that's fair. Some clarifications to this effect within the Javadoc for 'refresh' might be nice Much Thanks.
        Hide
        Florian Müller added a comment -

        I will rework the JavaDoc.

        Show
        Florian Müller added a comment - I will rework the JavaDoc.

          People

          • Assignee:
            Florian Müller
            Reporter:
            Chris Hubick
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development