I'm a little bit reluctant to go down that road. With that we're even more tying the query to JCR. If you know that your resource provider is JCR, then use the JCR API.
If we're doing something about query we should make it a) easier to use (writing a string based query is a pain) but also b) easier to implement in the various providers. For example if you want to implement a lets say Cassandra provider with query, writing the query parser for the query string is way too complicated. I made a proposal (SLING-4752) long time ago, there was a lot of heavy discussions around it, leading us as usual to anywhere. While I think that the proposal would work for many use cases, it would only allow to use the most common features of a query. Which in some cases might create other problems. Regards Carsten Daniel Klco wrote > Hi, > > I was recently working on some code which used > ResourceResolver#findResources to get an Iterator of Resources based on a > relatively simple query. > > Unfortunately, due to performance concerns, I ended up having to switch to > the JCR API to specify a limit. In order to make the querying in Apache > Sling more useful, would it make sense to: > > 1. Add support for "QueryOptions" as an additional parameter to an > additional findResources method. This would be a Map of options to be > passed to the underlying query engine which would (if supported) influence > the query executed. We could then create a few constants for common > parameters such as limit and offset. > 2. Expose the > org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResourceIterator > helper class. This class can be used to easily wrap a NodeIterator as an > Iterator<Resource> however as it is in the internal package it cannot be > referenced from other bundles. > > Any thoughts or concerns regarding these two proposals? > > Regards, > Dan > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
