[DISCUSS] Improve Sling Query Support

[Daniel Klco <dk...@apache.org>]

Hi,

I was recently working on some code which used
ResourceResolver#findResources to get an Iterator of Resources based on a
relatively simple query.

Unfortunately, due to performance concerns, I ended up having to switch to
the JCR API to specify a limit. In order to make the querying in Apache
Sling more useful, would it make sense to:

 1. Add support for "QueryOptions" as an additional parameter to an
additional findResources method. This would be a Map of options to be
passed to the underlying query engine which would (if supported) influence
the query executed. We could then create a few constants for common
parameters such as limit and offset.
 2. Expose the org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResourceIterator
helper class. This class can be used to easily wrap a NodeIterator as an
Iterator<Resource> however as it is in the internal package it cannot be
referenced from other bundles.

Any thoughts or concerns regarding these two proposals?

Regards,
Dan

Re: [DISCUSS] Improve Sling Query Support

[Carsten Ziegeler <cz...@apache.org>]

I'm a little bit reluctant to go down that road. With that we're even
more tying the query to JCR. If you know that your resource provider is
JCR, then use the JCR API.

If we're doing something about query we should make it a) easier to use
(writing a string based query is a pain) but also b) easier to implement
in the various providers. For example if you want to implement a lets
say Cassandra provider with query, writing the query parser for the
query string is way too complicated.

I made a proposal (SLING-4752) long time ago, there was a lot of heavy
discussions around it, leading us as usual to anywhere. While I think
that the proposal would work for many use cases, it would only allow to
use the most common features of a query. Which in some cases might
create other problems.

Regards
Carsten

Daniel Klco wrote
> Hi,
> 
> I was recently working on some code which used
> ResourceResolver#findResources to get an Iterator of Resources based on a
> relatively simple query.
> 
> Unfortunately, due to performance concerns, I ended up having to switch to
> the JCR API to specify a limit. In order to make the querying in Apache
> Sling more useful, would it make sense to:
> 
>  1. Add support for "QueryOptions" as an additional parameter to an
> additional findResources method. This would be a Map of options to be
> passed to the underlying query engine which would (if supported) influence
> the query executed. We could then create a few constants for common
> parameters such as limit and offset.
>  2. Expose the org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResourceIterator
> helper class. This class can be used to easily wrap a NodeIterator as an
> Iterator<Resource> however as it is in the internal package it cannot be
> referenced from other bundles.
> 
> Any thoughts or concerns regarding these two proposals?
> 
> Regards,
> Dan
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org