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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> 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 >> > * >> > * >> > >> > >
