Re: OperationContext and the Session.query() method

[Florian Müller]

Hi Mark,

The query() method uses some elements of an OperationContext object. 
For example the flags if Allowable Action or relationships should be 
included are taken from it. But the property filter is definitely 
ignored. The SELECT statement solely controls, which properties are 
requested.

Maybe the queryObjects() method works better in your scenario. It 
requires an OperationContext object and uses the property filter.



- Florian


Is there any chance that this MIGHT be an issue we are seeing with 
Alfresco
and its implementation?  I know it's doubtful.  Everything I have 
read thus
far, seems to imply that this *should *work.

I know that the recent Manning book on CMIS (a MEAP edition) shows 
examples
of the OperationContext being used, but specifically it is using it 
with
the getChildren() method of a cmis:Folder instance and not the
Session.query() method.

Otherwise, obviously, it is the way I'm interpreting this that is 
wrong.

Thanks

On Sun, May 5, 2013 at 8:48 AM, Mark Streit <mcs...@gmail.com> wrote:

Yes - we looked at that too and that could work but we were trying 
to
avoid having to specify the "columns" specifically since we have a 
few of
these types of queries and thought the OperationContext might help.

We have a couple of Enums that list the properties and I was able to 
load
a HashSet from the Enums dynamically in a loop.  I could then set 
the
HashSet as the argument on the OperationContext using the
setFilter(Set<String>) method and that all seemed to be OK.   The 
query()
method on the CMIS Session works fine but when I was able to print 
the
values for properties I did not include - it seemed that something 
was
either not working as expected or I misinterpreted how this works.

Most examples I've seen show this OperationContext with the use of 
the
Folder.getChildren() construct and we are NOT using that get the 
list of
cmis:Document objects from the target Folder.  We are using the 
CMIS-SQL
approach that includes the IN_FOLDER predicate.

Perhaps the 2 approaches make a difference, I don't know.  The fact 
that
the query() method has 2 forms, with and without an OperationContext 
made
me think that would work.  It was only an attempt to improve 
performance of
the service call on repository.

Thanks


Mark *
*


On Sun, May 5, 2013 at 8:24 AM, Michael Brackx <
michael.javaone+c...@gmail.com> wrote:

I don't know about alfresco, but in general you can limit the 
properties
with the select list.
For example
SELECT cmis:objectId, cmis:name FROM acme:document

Michael

On Sun, May 5, 2013 at 12:05 AM, Mark Streit <mcs...@gmail.com> 
wrote:

> Hello,
>
> I know I must be missing something so perhaps someone can help 
clarify.
>
>
>    1. We are currently using Apache Chemistry 0.8.0 (OpenCmis) 
quite
>    successfully thus far, building an application that uses 
Alfresco
4.1.3
>    Enterprise as the repository solution.
>    2. Our content model is the OOTB CMIS model with a handful of 
String
and
>    date properties added using the appropriate xzy_model.xml and
extensions
>    mechanism specific to Alfresco.
>    3. We are able to use the CMIS SQL language to retrieve lists 
of
>    documents from cmis:Folder objects without any problems.  
Syntax, for
>    example, of of one of the queries looks like this:
>
>
> String queryString = "SELECT * FROM acme:document WHERE
>

IN_FOLDER('workspace://SpacesStore/ad1kjhd5-01fc-43ad-af31-0d7dada9ec57')
> ORDER BY acme:category DESC";
>
>
> The Java code (used for current testing) that sends the query to 
the
> repository looks like this:
>
>
> ItemIterable<QueryResult> queryResult;
>
> try {
>
>     queryResult = this.cmisSession.*query*(queryString, false, 
this.*
> minimalOperationContext*).getPage(cmisQueryPageLimit);
>
> }
>
>
> ...
>
> ...
>
>
>  // below is similar to output lines found in Chemistry 
GettingStarted
> samples...
>
>
>  if (queryResult != null) {
> *LOGGER.info*("***queryResult.getTotalNumItems()
> " +
>
>     queryResult.getTotalNumItems());
>     int byteCount = 0;
>     int i = 1;
>     for (QueryResult qr : queryResult) {
>     LOGGER.info("--------------------------------------------\n" 
+ i +
" ,
> " +
>
>     
qr.getPropertyByQueryName("cmis:objectTypeId").getFirstValue() + "
, "
> +
>
>     qr.getPropertyByQueryName("cmis:name").getFirstValue() + " , 
" +
>
>     
qr.getPropertyByQueryName("cmis:creationDate").getFirstValue() + "
, "
> +
>
>     qr.getPropertyByQueryName("cmis:objectId").getFirstValue() + 
" , " +
>
>     qr.getPropertyByQueryName("acme:category").getFirstValue() + 
" , " +
>
>     qr.getPropertyByQueryName("acme:subCategory").getFirstValue() 
+ " ,
" +
>
>

qr.getPropertyByQueryName("cmis:contentStreamFileName").getFirstValue()
> + " , " +
>
>

qr.getPropertyByQueryName("cmis:contentStreamMimeType").getFirstValue()
> + " , " +
>
>

qr.getPropertyByQueryName("cmis:contentStreamLength").getFirstValue());
> }
>
>  }
>
>
> It was suggested that we might see a performance improvement in
searches by
> using the OperationContext to reduce the set of properties pulled 
back
on
> each cmis:Document instance.
>
> The OperationContext *minimalOperationContext *was set like this 
below,
>  where I  am specifying only these few properties of the model to
retrieve:
>
>          cmisSession = sessionFactory.createSession(parameters);
>
>
>          // only setting a few properties to retrieve for a 
test...
>
>          Set<String> filterSet = new HashSet<String>();
>          filterSet.add("cmis:objectId");
>          filterSet.add("cmis:name");
>          filterSet.add("cmis:creationDate");
>          filterSet.add("cmis:contentStreamLength");
>
>
>          OperationContext *minimalOperationContext *=
> cmisSession.createOperationContext();
>          minimalOperationContext.setFilter(filterSet);
>          minimalOperationContext.setIncludeAcls(false);
>          
minimalOperationContext.setIncludeAllowableActions(false);
>          minimalOperationContext.setIncludePolicies(false);
>
>
>
 
minimalOperationContext.setIncludeRelationships(IncludeRelationships.NONE);
>          
minimalOperationContext.setRenditionFilterString("cmis:none");
>          minimalOperationContext.setIncludePathSegments(false);
>          minimalOperationContext.setOrderBy(null);
>          minimalOperationContext.setCacheEnabled(false);
>
>
> Now here is the puzzle.  I would actually *not expect *the lines 
that
are
> output from the LOGGER.info() to have included any of the 
properties
that
> were NOT included in the OperationContext specified.  However, 
the
output
> is showing EVERY property specified in the LOGGER.info() above 
... as
> though the OperationContext is getting ignored.  Or... am I 
totally
missing
> how this is supposed to work?
>
> Thanks
>
> Mark
> *
> *
>