CMIS query bug in community Alfresco

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

henryh

Hi,

When sending query over REST /alfresco/api/-default-/public/cmis/versions/1.1/atom/query?q=

And using IN_TREE() function for example like this: SELECT D.cmisbjectId FROM cmis:document as D WHERE IN_TREE(D,'3c6897d5-44bb-4471-84b0-15b8d82adf89')&maxItems=1

Response XML contains <cmisra:numitems> -tag which has actual ammount of documents which can be found without maxItems parameter limitation. In my case it would be 3 cmisbjectId's

But, when same query is send by using IN_FOLDER function like this: SELECT D.cmisbjectId FROM cmis:document as D WHERE IN_FOLDER(D,'3c6897d5-44bb-4471-84b0-15b8d82adf89')&maxItems=1

Response XML contains <cmisra:numitems> -tag with the value of maxItems instead of actual count of items which can be found with the query, which is again 3 cmisbjectId's in my case because all documents are in root of that single folder.

 I consider this is as a bug because, it could be nice to know how many documents search returns if executed without maxItems limit. At this way we can first check if response is going to be huge and do some evasive actions before actually executing the query.

henryh

Found the issue and fixed in a source code....

When Alfresco`s search engine`s programming interface receives a query, then (not in all potential cases, but at least in those when CMIS query is executed) it first tries to run a query against the database. It successfully runs only in simple cases, like not using functions or using IN_FOLDER for single folder without boolean operators like OR. In more 'complex' cases it fails to query directly from DB.

When the exception is caught, which happens when IN_TREE or boolean operators with IN_FOLDER are used, then the search is performed against Solr index. And here is the difference: direct DB search implementation sets this numItems value from a result-set which is already filtered by some criteria i.e. using mentioned maxItems parameter, whilst Solr index search implementation sets numItems value from an unfiltered result set. That is why <cmisra:numItems> had value "1" in case of simple queries and the actual number of items in case when queries had been more complex.

Just in case if someone wants to fix this in original source codes.