Add FluentQuery support to QuerydslPredicateExecutor and QueryByExampleExecutor

[mp911de]

FluentQuery allows extending a query specification initially defined by a Example probe or a Querydsl Predicate and fetching the actual result through a functional programming model:

interface PersonRepository extends QuerydslPredicateExecutor<Person> {
  <S extends T, R> R findBy(Predicate predicate, Function<FluentQuery.FetchableFluentQuery<S>, R> queryFunction);
}

PersonRepository repo = …;

List<PersonProjection> result = repo.findBy(QPerson.person.name.eq("Walter"), q -> q.sort(Sort.by("lastname")).as(PersonProjection.class).project("firstname", "lastname").all());

Stream<PersonProjection> result = repo.findBy(QPerson.person.name.eq("Walter"), FetchableFluentQuery::stream);

Closes #2228

[michael-simons]

The addition in general seems nice, but I wonder why you don't default the methods and throw an UnsupportedOperationException ?

[michael-simons]

Why not defaulting it?

[michael-simons]

Same.

[mp911de]

This extension provides much more flexibility and is a pre-requisite to turn the other methods into default ones. We do not want to raise false expectations in terms of supported API to then throw an exception if e.g. streaming or projections aren't supported.

All default repository methods are invoked on the interface as we do not delicate these calls into the actual implementations.

[michael-simons]

But the change here will break all other modules.
What if a module cant or wont implement them and adds just stub throwing an exception?

[michael-simons]

Another option might be an additional FluentQuerydslPredicateExecutor ?

[mp911de]

But the change here will break all other modules.
What if a module cant or wont implement them and adds just stub throwing an exception?

That's a consequence of the current arrangement. Modules can still throw an UnsupportedOperationException in that case.

Another option might be an additional FluentQuerydslPredicateExecutor ?

Introducing another set of interfaces (for imperative/reactive and Querydsl/Query-by-Example) break the concise programming model as the fluent method cannot be discovered from the marker interface that introduced Querydsl/Query-by-Example functionality to a repository. Each module would have to consider additional marker interfaces to contribute further fragments. As a consequence, we end up with a much more complex arrangement.

[michael-simons]

That's a consequence of the current arrangement. Modules can still throw an UnsupportedOperationException in that case.

I don't understand this sentiment in connection with your original above:

We do not want to raise false expectations in terms of supported API to then throw an exception if e.g. streaming or projections aren't supported.

So either commons or a module will throw an exception and leave unfulfilled expectations. Doesn't make much sense to me.

Note that I am totally in for this new feature, but breaking all modules with the reasoning here doesn't work for me.

[michael-simons]

Please add a note to the relevant FluentQuery.* interfaces that the builders are immutable in the sense that each step returning a FluentQuery.* again returns a complete new instance and does not modify the target.

[mp911de]

That's merged now.