> On 22.06.2015, at 15:49, Justin Edelson <[email protected]> wrote: > IIUC, the core problem we are trying to solve is to provide a query syntax > indepdent of any particular ResourceResolver implementation. While, to be > honest, this is not a problem I have personally run into using Sling for > the past 6 years,
That's my main concern as well. An edge case creating a ton of complexity with probably leaky abstractions (inevitable little tricks to pass through query language/resource provider specific stuff, the AEM query builder experienced this already with the @orderby statement and fn: functions). > One thing which concerns me about the current Query API is that it appears > to be completely non-extensible. How, for example, would one implement > something like > https://docs.adobe.com/docs/en/cq/5-6-1/javadoc/com/day/cq/search/eval/RelativeDateRangePredicateEvaluator.html This is not the Query API. This is the SPI. But yes, you would need a way to have a different SPI per resource provider. Currently a PredicateEvaluator [1] has a single getXpathExpression(). [1] https://docs.adobe.com/docs/en/aem/6-1/ref/javadoc/com/day/cq/search/eval/PredicateEvaluator.html > ? If I'm reading this correctly, the date math has to be done by the > caller. Which isn't that problematic at first, but the code would be > significantly more verbose than > > relativedaterange.property=jcr:lastModified > relativedaterange.lowerBound=-1d Some of that common parsing logic should be shared, of course, used by the different SPIs. > What is potentially problematic about not having this type of extensibility > is that it prevents specific implementations from providing the best > implementation possible. Yep, the AEM querybuilder so far was not designed for different underlying query languages / engines, this would be something to look into. Its design goal was to allow customers to plugin own predicate evaluators mainly for making client side queries short and descriptive, and have them "expanded" into the full, maybe more complex xpath query involving multiple predicates or some custom parsing as the date example. Taken plain, this would lead to a matrix of things, predicate evaluators X query languages (resource providers). Not sure if this is desirable. > Here's a better example: JCR is unable to compare two properties, i.e. give > me all nodes where property foo equals the value of property bar. But > MongoDB *can* do this (it isn't super-efficient, but it is possible). I can > almost see how you would do this with the new Query API, but it would be > ugly at best. Or, more broadly, how would the MongoDB $where operator be > supported? Could be a new predicate: compare.left=jcr:title compare.right=jcr:description > 1) A map of key/value pairs is turned into a PredicateGroup object. > 2) The PredicateGroup (which is a nested tree) at this point represents the > query statement. > 3) Each ResourceProvider analyzes the predicates and decides whether or not > it knows how to evaluate all of them. If it can't, it should return no > results (this is debatable, but I think it makes sense). The only exception > is where you had an or clause, i.e. this query: > > fulltext=Management > group.p.or=true > group.1_jcrType=dam:Asset > group.2_resourceType=some/resource/type Yep, these tend to be joins. Once you join/merge results across different resource providers, you will never be able to get acceptable performance. And the implementation is no longer resource provider specific, since you need someone on the resource resolver level to understand the query. Here a central search index (Solr, ElasticSearch etc.) is the right solution anyway. And that's what I am preaching, anyone who actually has the use case of searching across multiple resource providers with the same query language should do this. If the use case is "one resource provider" only, then IMO you can live with rp specific query languages, and the current findResources() is fine (as long as you can put the query statement in a single string). > 4) The ResourceProvider uses PredicateEvaluators to map each predicate to > its native query syntax. For this to work, each ResourceProvider would > expose its own PredicateEvaluator interface (in theory, > a ResourceProvider doesn't need to do this if the evaluation process isn't > intended to be pluggable). The PredicateEvaluator SPI could be rp specific and not part of the sling resource query API. Cheers, Alex
