chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller (JIRA) <>
Subject [jira] [Commented] (CMIS-855) Different result of OperationContext.getFilterString and OperationContext.getFilter
Date Mon, 13 Oct 2014 12:15:35 GMT


Florian Müller commented on CMIS-855:

getFilterString() is used to generate the string that is sent to the server. It adds the properties
cmis:objectId, cmis:objectTypeId, and cmis:baseTypeId (if not already present in the filter)
because that is the minimal set of properties OpenCMIS needs to build a Java object. Applications
usually don't need this method. It's not necessary to parse this string because an easier
to use convenience method (getFilter()) is available.

The JavaDoc clearly states the difference. So, I don't understand why this should be a bug.

> Different result of OperationContext.getFilterString and OperationContext.getFilter
> -----------------------------------------------------------------------------------
>                 Key: CMIS-855
>                 URL:
>             Project: Chemistry
>          Issue Type: Bug
>          Components: opencmis-client
>    Affects Versions: OpenCMIS 0.12.0
>            Reporter: Sascha Egerer
> There are two methods in the OperationContext that return the content of the "filter"
property. But they return a different result and it's not clear to me why.
> The getFilterString dynamically adds PropertyIds::OBJECT_ID, PropertyIds::BASE_TYPE_ID
and PropertyIds::OBJECT_TYPE_ID to the result.
> If loadSecondaryTypeProperties is true the value PropertyIds::SECONDARY_OBJECT_TYPE_IDS
is also added.
> I don't see any reason why this is only implemented in the "string" method and not also
in the getFilter method which returns a Collection.

This message was sent by Atlassian JIRA

View raw message