Am 29.05.15 um 01:16 schrieb Alexander Klimetschek: > 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. > I agree with this, however users of the resource api do not know which provider is serving the resources. That's the hole point of an abstraction.
Carsten > 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 > > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
