Mailing-List: contact dev-help@chemistry.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@chemistry.apache.org
Date: Wed, 19 Nov 2014 22:56:34 +0000 (UTC)
From: "Marco Biscaro (JIRA)" <jira@apache.org>
To: dev@chemistry.apache.org
Message-ID: <JIRA.12756564.1416437736000.539868.1416437794402@Atlassian.JIRA>
In-Reply-To: <JIRA.12756564.1416437736000@Atlassian.JIRA>
References: <JIRA.12756564.1416437736000@Atlassian.JIRA>
 <JIRA.12756564.1416437736235@arcas>
Subject: [jira] [Created] (CMIS-870) Inconsistent cardinality -
 getProperties vs updateProperties
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Marco Biscaro created CMIS-870:
----------------------------------

             Summary: Inconsistent cardinality - getProperties vs updatePro=
perties
                 Key: CMIS-870
                 URL: https://issues.apache.org/jira/browse/CMIS-870
             Project: Chemistry
          Issue Type: Bug
          Components: opencmis-commons
    Affects Versions: OpenCMIS 0.12.0
         Environment: Tested with Alfresco 5.0.a on Mac OS X using the brow=
ser binding.
            Reporter: Marco Biscaro
            Priority: Minor


I think the best way to explain this bug is through API response samples. F=
or example, the following updateProperties call on Alfresco:

{code}
POST /alfresco/api/-default-/public/cmis/versions/1.1/browser/root?objectId=
=3D207ba708-714e-4740-96f8-5cfeabc9003f

cmisaction=3Dupdate&propertyId[0]=3Dcm:title&propertyValue[0]=3DDocTitle


{
  "properties": {
    (...)
    "cmis:secondaryObjectTypeIds": {
      "id": "cmis:secondaryObjectTypeIds",
      "localName": "secondaryObjectTypeIds",
      "displayName": "Secondary Object Type Ids",
      "queryName": "cmis:secondaryObjectTypeIds",
      "type": "id",
      "cardinality": "multi",
      "value": [
        "P:cm:titled",
        "P:cm:author",
        "P:sys:localized"
      ]
    },
    (...)
    "cm:title": {
      "id": "cm:title",
      "localName": "title",
      "displayName": "T=C3=ADtulo",
      "queryName": "cm:title",
      "type": "string",
      "cardinality": "single",
      "value": "DocTitle"
    },
    (...)
  }
}
{code}

The response above is correct. The cm:title property (part of P:cm:titled a=
spect) has cardinality single and is returned as a string.

The problem lies on the getProperties action. For example:

{code}
GET /alfresco/api/-default-/public/cmis/versions/1.1/browser/root?objectId=
=3D207ba708-714e-4740-96f8-5cfeabc9003f&cmisselector=3Dproperties


{
  (...)
  "cm:title": {
    "id": "cm:title",
    "localName": "title",
    "displayName": "T=C3=ADtulo",
    "queryName": "cm:title",
    "type": "string",
    "value": [
      "DocTitle"
    ]
  },
  (...)
}
{code}

As you can see, the cardinality is undefined and the value is returned as a=
n array.

Debugging the code, I realized that when the updateProperties endpoint is c=
alled, the method ServerTypeCacheImpl.getTypeDefinitionForObject is invoked=
 and this method correctly registers all type definitions for secondary obj=
ect types. This makes it possible to correctly determine the cardinality of=
 the property when converting the response to JSON.

However, when getProperties is called, the ServerTypeCacheImpl.getTypeDefin=
itionForObject method is *not* called, but the type definition is registere=
d by invoking ServerTypeCacheImpl.getTypeDefinition, which does not registe=
r the secondary object types. When converting to JSON, the cardinality of t=
he property is unknown and it is (incorrectly) returned as an array.

I think the method getTypeDefinitionForObject should always be called, to c=
orrectly register secondary object types and ensure consistency between que=
ries of the same object.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)