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" :)
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.
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.
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.
Cheers,
Alex
