chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Streit <mcs...@gmail.com>
Subject Re: OperationContext and the Session.query() method
Date Tue, 07 May 2013 02:26:25 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message