Just to clarify as it seems people got the proposal wrong: this is about a new API, not an implementation. It's an abstraction on the resource level. Of course with a JCR provider underneath, the search is delegated to that provider. Same with other providers. It should be easy for every provider to implement the api.
Typical use cases are for example the job handling which searches for jobs in the resource tree or the resource resolver implementation looking for vanity paths etc. Right now - although these parts use the resource api - it's not possible to run them with a different provider than jcr. Carsten Am 18.05.15 um 08:17 schrieb Carsten Ziegeler: > The current resource query api has several problems: > - it's using the JCR spec to define a query > - it's not clear which queries are supported by providers > - queries are string based > - implementing queries in a resource provider is way too hard as this > would require to implement the complete jcr query api. > > I've created a draft for a new, object based API at [1]. The main idea > is to use a builder pattern to create Query objects. This are immutable > and have a unique identifier. The QueryManager service can be used to > execute a query in the context of a resource resolver. The manager > delegates the query to the providers. As each Query object has this > identifier, implementations can use this to cache the parsing of the query. > In addition to the query object you can pass in query instructions to > specify a limit or range for the query. > > Obviously this is a reduced set compared to the full fledged jcr search > api, however it should be suitable for the majority of use cases. > > [1] > https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/query/ > > Regards > Carsten > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
