chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marco Biscaro (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CMIS-870) Inconsistent cardinality - getProperties vs updateProperties
Date Wed, 19 Nov 2014 22:56:34 GMT
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)

Mime
View raw message