You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Mark Streit <mc...@gmail.com> on 2013/05/05 00:05:32 UTC

OperationContext and the Session.query() method

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
*
*

Re: OperationContext and the Session.query() method

Posted by Florian Müller <fm...@apache.org>.
 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 <mc...@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+cmis@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 <mc...@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
>>> > *
>>> > *
>>> >
>>>
>>
>>


Re: OperationContext and the Session.query() method

Posted by Mark Streit <mc...@gmail.com>.
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 <mc...@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+cmis@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 <mc...@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
>> > *
>> > *
>> >
>>
>
>

Re: OperationContext and the Session.query() method

Posted by Mark Streit <mc...@gmail.com>.
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+cmis@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 <mc...@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
> > *
> > *
> >
>

Re: OperationContext and the Session.query() method

Posted by Michael Brackx <mi...@gmail.com>.
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 <mc...@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
> *
> *
>