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