On 30.05.2015, at 01:31, Stefan Seifert <[email protected]> wrote: > >>> And this is a typical case where abstraction fails: performance. Which is >> extremely important for queries. >>> >> Well, this is a broad statement and neither true nor wrong. > > i'm the same opinion as carsten. i did a quick check for the most queries in > our projects from the last years and most of them can be expressed with an > API like this and the code maintainability would benefit from it. and for new > developers its easier to learn a fluent API then a query syntax.
But do you have queries across resource providers? Do you know the implementation complexity and performance limitations you are asking for? If you have different resource providers with their own search index, and you have to aggregate on the resource resolver/tree level, you basically start having JOINs without any indexes, and these will be slow. > and the abstraction may even help improve performance for the unexperienced > ones - there was some time in jackrabbit 2 where the same query in either > xpath or sql syntax was quite differently in performance - if such an > abstraction is implemented in an intelligent way it could always use the most > performant query variant, and the user of the query does not have to care > about those implementation details. of course this makes the implementation > of the abstraction much more complex. "Choosing the most performent query" is absolutely non trivial. And it requires your resource provider implementation to be able to ask it's underlying database/repository to figure that out (before you translate to the particular query itself). Here you'll have tons of places where the abstraction will leak and/or you can't get the right performance. Also, be careful to tell (unexperienced) developers to magically do the most performance query - this just doesn't work that way in practice, especially if you have different backends involved, they will have to understand what's going on. Cheers, Alex > btw. i assume we do not remove the old support for directly passing a query > string to the resource resolver, but add the additional support for the > abstraction? this would allow experienced developers who now they are only > using JCR still use direct JCR queries against the resource resolver. > > stefan
