I agree. The createFilter can be moved to the Query, so we don't require
this to be in the Session interface.
I haven't seen many questions about this functionality, so I guess we
shouldn't worry to much about this change.
Vlad
On Mon, Sep 12, 2016 at 6:02 AM, Steve Ebersole
Hi,
We definitely need to address the ResultTranformer.
Only the former method is what we should be exposing, the latter being used
only in one particular use case, so that should be addressed by a different
contract.
This way we could provide a ResultTransformer using a lambda, which is not
Another method I'd like to drop is Session#createFilter. This is method is
easy enough to replace with a call to createQuery instead. Longer term I
can also see Stream or DSL support from our persistent collections to
provide the similar capabilities. But for now its just no real benefit for
Another legacy concept I'd like to revisit as we move to 6.0 is the
Hibernate ResultTransformer. I'd argue that ResultTransformer is no longer
needed, especially in it's current form.
Specifically, ResultTransformer defines 2 distinct ways to transform the
results of a query:
1.
The direction I went for now was to push collection of the parameters to
SQM itself and expose that from SqmStatement#getQueryParameters.
Additionally I have SQM validate the positional parameters per JPA spec
(1-based, contiguous).
I added
