Thanks for your feedback Stefan, more inline...
Am 21.05.15 um 13:00 schrieb Stefan Seifert:
>
> 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?
Yes, I had it this way in my first draft, but for some reason (which I
can't rememeber...) decided against. Make moving is better.
>
> 2. it would be useful not only to filter by property values, but by
> node/resource name as well (e.g. resource name = X)
ah good one.
>
> 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.
Yep
>
> 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.)
ok
>
> 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")?
Haven't thought about this one yet, but I guess a special signature
sounds better.
>
> 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.
I'm not sure if we should go there, so your use case is searching for a
resource which has a child resource that has a property foo=bar (or
something like that)?
>
> 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?
The main idea is to cover most search use cases, looking for example at
the queries we have in the Sling code base, I guess we can cover all of
those. So the set should be implementable by all providers. We could
make this mandatory. Having optional parts is always problematic as
you never know if something is supported or not, and even asking before
if something is supported doesn't help if you get back a "no".
Therefore I personally would like to keep this simply and therefore
implementable by everyone.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
