When you run a query across multiple backends, you have to aggregate the results. This is non-trivial an in most cases you are better off using an external search index that covers everything. And from my experience, you usually you don't have the use case to search across different providers, e.g. if you have a) a file system provider for bundles and code and b) a database provider providing ecommerce order entries, you never search across both at the same time.
Cheers, Alex > On 28.05.2015, at 11:06, Carsten Ziegeler <cziege...@apache.org> wrote: > > 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
