Mailing-List: contact dev-help@chemistry.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@chemistry.apache.org
Date: Tue, 25 Nov 2014 19:53:13 +0000 (UTC)
From: =?utf-8?Q?Florian_M=C3=BCller_=28JIRA=29?= <jira@apache.org>
To: dev@chemistry.apache.org
Message-ID: <JIRA.12756564.1416437736000.18796.1416945193263@Atlassian.JIRA>
In-Reply-To: <JIRA.12756564.1416437736000@Atlassian.JIRA>
References: <JIRA.12756564.1416437736000@Atlassian.JIRA>
 <JIRA.12756564.1416437736235@arcas>
Subject: [jira] [Updated] (CMIS-870) Inconsistent cardinality -
 getProperties vs updateProperties
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/CMIS-870?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:all-tabpanel ]

Florian M=C3=BCller updated CMIS-870:
--------------------------------
    Affects Version/s:     (was: OpenCMIS 0.12.0)
                       OpenCMIS 0.10.0

> Inconsistent cardinality - getProperties vs updateProperties
> ------------------------------------------------------------
>
>                 Key: CMIS-870
>                 URL: https://issues.apache.org/jira/browse/CMIS-870
>             Project: Chemistry
>          Issue Type: Bug
>          Components: opencmis-commons
>    Affects Versions: OpenCMIS 0.10.0
>         Environment: Tested with Alfresco 5.0.a on Mac OS X using the bro=
wser binding.
>            Reporter: Marco Biscaro
>            Assignee: Florian M=C3=BCller
>            Priority: Minor
>             Fix For: OpenCMIS 0.11.0
>
>
> I think the best way to explain this bug is through API response samples.=
 For example, the following updateProperties call on Alfresco:
> {code}
> POST /alfresco/api/-default-/public/cmis/versions/1.1/browser/root?object=
Id=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=
 aspect) 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?objectI=
d=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=
 an array.
> Debugging the code, I realized that when the updateProperties endpoint is=
 called, the method ServerTypeCacheImpl.getTypeDefinitionForObject is invok=
ed and this method correctly registers all type definitions for secondary o=
bject 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.getTypeDef=
initionForObject method is *not* called, but the type definition is registe=
red by invoking ServerTypeCacheImpl.getTypeDefinition, which does not regis=
ter the secondary object types. When converting to JSON, the cardinality of=
 the property is unknown and it is (incorrectly) returned as an array.
> I think the method getTypeDefinitionForObject should always be called, to=
 correctly register secondary object types and ensure consistency between q=
ueries of the same object.


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