[
https://issues.apache.org/jira/browse/CMIS-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14169216#comment-14169216
]
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: https://issues.apache.org/jira/browse/CMIS-855
> 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
(v6.3.4#6332)
