Provides query projection for Hibernate with Panache

[loicmathieu]

Description
Provides the same projection capabilities than for MongoDB with Panace.

See PR #4202

[FroMage]

Note that I think we don't need it for all use-cases, because if we removed the bound for find it would just work. We should experiment.

[ahofmeister]

Is this going to be in the next version or anything? Just asking, no pressure. :)

[FroMage]

If we didn't have the bound on find (and its variants) we could do:

String name = Order.find("select name").firstResult();
long max = Order.find("select max(price)").firstResult();

Which is not about projections, but already goes a long way.

[FroMage]

Actually perhaps even:

String name = Order.find("name").firstResult();
long max = Order.find("max(price)").firstResult();

Since this is not ambiguous with queries.

[loicmathieu]

@FroMage if a query starts with select hibernate with Panache will use it as is so it will also needs to have a From clause ... same for your second example the current implementation will add a bad select clause.

Regarding the bound to find, if we didn't add one we will ends up using on of the two following construct for a basic typed usage (the same for your example, if you don't have a bound to find you need to specify the return type in a way) and I didn't like both :

Person person = (Person) Person.find("name", "Loic").firstResult(); // remove the bound and return Object
Person person = Person.<Person>find("name", "Loic").firstResult(); // remove the bound but allow a parameterized return type

Maybe I'm not seeing exactly what you propose ...

[FroMage]

@FroMage if a query starts with select hibernate with Panache will use it as is so it will also needs to have a From clause ... same for your second example the current implementation will add a bad select clause.

Sure, but we can change that.

As for typing, we currently already have this issue, it's nothing new, and it's due to the way Java's type inference works. Right now the inferred bound will be PanacheEntity which is not much more useful. Another way to nudge it is:

PanacheQuery<String> q = Order.find("name");
String name = q.firstResult();

We could totally add a project as you suggest that would essentially return this but with a different type argument, which would indeed make Person.find("name").project(String.class).firstResult() be properly typed.

[loicmathieu]

@FroMage for the records, Quarkus Spring Data compability layer now support returing a different type for a query, this has been implemented by #6691 the fun part is here : https://github.com/quarkusio/quarkus/pull/6691/files#diff-3e72c8149ec469f75ff8ffc49803d6f2R129-R154 it generates a mapper using PanacheQuery.stream().map() ...

[ebullient]

@FroMage for the records, Quarkus Spring Data compability layer now support returing a different type for a query, this has been implemented by #6691 the fun part is here : https://github.com/quarkusio/quarkus/pull/6691/files#diff-3e72c8149ec469f75ff8ffc49803d6f2R129-R154 it generates a mapper using PanacheQuery.stream().map() ...

Yeah.. that was fun. I will admit to being quite pleased to get it working. ;)