chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller (JIRA) <j...@apache.org>
Subject [jira] [Assigned] (CMIS-870) Inconsistent cardinality - getProperties vs updateProperties
Date Thu, 20 Nov 2014 09:08:34 GMT

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

Florian Müller reassigned CMIS-870:
-----------------------------------

    Assignee: Florian Müller

> 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.12.0
>         Environment: Tested with Alfresco 5.0.a on Mac OS X using the browser binding.
>            Reporter: Marco Biscaro
>            Assignee: Florian Müller
>            Priority: Minor
>
> 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?objectId=207ba708-714e-4740-96f8-5cfeabc9003f
> cmisaction=update&propertyId[0]=cm:title&propertyValue[0]=DocTitle
> {
>   "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ítulo",
>       "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?objectId=207ba708-714e-4740-96f8-5cfeabc9003f&cmisselector=properties
> {
>   (...)
>   "cm:title": {
>     "id": "cm:title",
>     "localName": "title",
>     "displayName": "Título",
>     "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 invoked and this method correctly
registers all type definitions for secondary object 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.getTypeDefinitionForObject
method is *not* called, but the type definition is registered by invoking ServerTypeCacheImpl.getTypeDefinition,
which does not register 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 queries of the same object.



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

Mime
View raw message