hello carsten.
some feedback:
1. Query can reference further Queryies for nesting with and/or expressions. in
this case the sort* methods do not make sense. perhaps the two sort methods
should be moved to QueryInstructions?
2. it would be useful not only to filter by property values, but by
node/resource name as well (e.g. resource name = X)
3. I suppose the isA could not only mean a resource type but a JCR primary type
as well if the resource provider supports it? to clarify in javadocs.
4. perhaps we should not use arrays in public interfaces as output values, they
have always the problem with immutability (e.g. Query.getPaths etc.)
5. full text search on any property (jcr:contains) - is this possible with
.property("*").approx("searchterm")? or perhaps something like
.anyProperty().approx("searchtearm") - or a special signature like
.anyPropertyApprox("searchtearm")?
6. property conditions with deep property paths should be supported as well -
if the underlying provider supports it. so .property() could optionally accept
a path to a deeper property. to clarify in javadocs.
7. all in all this query supports a lot of features, although not all as it is
possible with XPath etc. what happens if a resource provider can only support a
subset of those features?
stefan
>-----Original Message-----
>From: Carsten Ziegeler [mailto:[email protected]]
>Sent: Monday, May 18, 2015 8:17 AM
>To: Sling Developers
>Subject: [RT] New resource query API
>
>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
>[email protected]
