chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <f...@apache.org>
Subject Re: OperationContext and the Session.query() method
Date Tue, 07 May 2013 11:21:45 GMT
 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 <mcs130@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 <mcs130@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
>>> > *
>>> > *
>>> >
>>>
>>
>>


Mime
View raw message