Marco Biscaro created CMIS-870:
----------------------------------
Summary: 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
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)
