Hi, On Wed, Jun 24, 2015 at 9:01 PM Alexander Klimetschek <[email protected]> wrote:
> On 23.06.2015, at 15:22, Justin Edelson <[email protected]> wrote: > >> > 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. > > > > Yes, I know this is the SPI of the QueryBuilder. My point is that because > > the current Sling Query API is all strongly typed, there's no way to > extend > > it with custom predicates like this. > > Oh, you refered to "Sling query API". I thought with "query API" you meant > the "AEM querybuilder API" :) > Yes... the wording is very complicated because both are "Query APIs" and both have something called a "QueryBuilder". Not surprised I missed qualifying one or two :) > > My comments were independent from the current sling query API proposal. > > > Perhaps this extensibility is not desired in Sling, but IMHO it certainly > > is one advantage of the (AEM) QueryBuilder. > > > > And if we don't have it in Sling, it only makes the developer decision as > > to what query abstraction to use that much more complicated. > > Right. > > >> Could be a new predicate: > >> > >> compare.left=jcr:title > >> compare.right=jcr:description > >> > > > > It could be in the AEM QueryBuilder, but this isn't something the Sling > > Query API can support. > > Ok. > > >> 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. > > > > I'm not sure why the performance would be suboptimal in this case unless > > sorting was involved. > > A true join, like "where a.value = b.value", with a and b coming from > different resource providers. > Ah, that kind of join. Yes, I agree. > > Also, the overhead of separate index lookups (instead of 1 index, you look > at N = number of resource providers), especially for full text searches, > should not be neglected. > Agree, but I (and perhaps you disagree) would think this behavior would be totally understandable and we could make it transparent what was happening, i.e. have a 'show plan' output. > > And sorting is not that uncommon :) Especially if you have different > buckets (resource providers) - do you always want to return them in their > rp registration order? What use case would be solved by that and ok with it? > > > This predicate list would map to three queries (in > > the JCR + Mongo use case): > > > > //element(*, dam:Asset)[@jcr:contains(., 'Management') > > //element(*, nt:base)[@sling:resourceType='some/resource/type' and > > @jcr:contains(., 'Management') > > { 'sling:resourceType' : { $eq : 'some/resource/type' } }, { $text : > > 'Management' } > > > > And you wouldn't actually need to execute all three queries at once > (unless > > you needed sizing information) - just return some kind of lazy executor > > which went through each result set before executing one query. > > > > The performance for this would be as good as could be expected. > > Depending on 3 separately configured search indexes that work completely > different… which sounds difficult to me, and a central, external search > index should be much more manageable and efficient. > > > But let's be clear - query is always going to be a highly leaky > > abstraction. Even querying against the JCR API directly is very leaky at > > this point in Oak because you really need to know the indexes available > in > > the system in order to know that a query is going to perform well. Ditto > > with MongoDB or any other queryable system. > > Sure. > > > I don't disagree that a centralized index would be a better functional > > match, albeit with additional operational complexity. I don't think > there's > > anything in the model I proposed which would preclude the > ResourceResolver > > from handing the query off directly to Solr instead of passing it down to > > the ResourceProviders. > > Which would not require a new sling query API. > How do you see this working with the existing Sling API (i.e. before this addition)? Would it look like: resourceResolver.findResources("SOLR", <some solar syntax query>) ?? Regards, Justin > > Cheers, > Alex
