On Tue, Sep 13, 2016 at 9:55 PM Gail Badner wrote:
> Sorry for the late response. I've been looking through the fix for
> HHH-5163 [1] to jog my memory.
>
> Here are some reasons why CacheableResultTransformer is important when
> caching query results:
>
> 1) The same SQL can be generated when as
Sorry for the late response. I've been looking through the fix for HHH-5163
[1] to jog my memory.
Here are some reasons why CacheableResultTransformer is important when
caching query results:
1) The same SQL can be generated when associations are joined as when
associations are fetched, but what
BTW... https://hibernate.atlassian.net/browse/HHH-11104
On Tue, Sep 13, 2016 at 7:05 PM Steve Ebersole wrote:
> Hmmm there is an interesting aspect to Tuple + TupleTransformer.. both
> expect to get the root selection aliases and would naturally expect those
> to match in length to the values to
Hmmm there is an interesting aspect to Tuple + TupleTransformer.. both
expect to get the root selection aliases and would naturally expect those
to match in length to the values to transform. Basically only one can
"consume" the aliases.
I think that because Tuple is a "higher precedence" (it def
So here is the path I am following initially.. It is straightforward to
explain to a user which I like.
In terms of processing each "row" in a result there is the RowTransformer
contract I mentioned earlier, or maybe I mentioned on HipChat. I added the
capability for RowTransformer to be nested,
So again, this all boils down to the interplay with
(Result|Tuple|ResultList)Transformer, dynamic instantiations, and
result-types.
So let's look at some specific cases...
First some cases I think are perfectly valid:
session.createQuery( "select new map(...) ...", Map.class ) - returns a
List>
On Tue, Sep 13, 2016 at 5:23 AM Emmanuel Bernard
wrote:
> My preference would be to keep some form of resultTransformer around,
> especially the first method that is redundant.
>
> And it's mainly because it is very easy to write one and plug. The HQL
> based instantiation is fine when you use it
On Tue, Sep 13, 2016 at 2:26 AM Gunnar Morling wrote:
> > Between dynamic-instantiation, Tuple-handling...
>
> To be sure, WDYM by "tuple-handling"?
>
javax.persistence.Tuple
So I gave just one example earlier of how all of these things do not
necessarily fit together in inherently obvious ways
My preference would be to keep some form of resultTransformer around,
especially the first method that is redundant.
And it's mainly because it is very easy to write one and plug. The HQL
based instantiation is fine when you use it but as Gunnar mentioned,
this is not always the case. What is the
> Between dynamic-instantiation, Tuple-handling...
To be sure, WDYM by "tuple-handling"?
One use case for result transformers are full-text searches executed
through Hibernate Search's Session extension FullTextSession (see [1]).
For full-text searches we don't use HQL/JPQL, so the "new ..." syn
I'd say one can either use the "new .." syntax, or a
ResultTransformer/TupleTransformer but not both at the same time.
IMO you can do your DTO stuff in the transformer which is probably also
one of the few usecases for ResultTransformer.
Am 13.09.2016 um 01:33 schrieb Steve Ebersole:
> If we are
If we are going to support #transformTuple (in whatever form) we need to
decide on a precedence between that, resultClass, dynamic-instantiation, etc
Specifically, what is the meaning of:
session.createQuery( "select new DTO(...) ...", DTO.class )
.setTupleTransformer( () -> ... )
Gail, IIRC one of these methods causes problems with regards to query
result caching. Do I remember that correctly? And if so, do you remember
which one? I'd guess #transformTuples, but I forget the details.
On Mon, Sep 12, 2016 at 6:36 AM Steve Ebersole wrote:
> So your example actually lev
So your example actually leverages both methods... Well technically it
only really needs the latter method (#transformList); you could have done
all that work there - the elements of the passed collection would be the
individual tuples.
On Mon, Sep 12, 2016 at 6:09 AM Vlad Mihalcea
wrote:
>
Sure. I've used it recently to group a tree-like structure as follows:
public class PostCommentScoreResultTransformer
implements ResultTransformer {
private Map postCommentScoreMap = new
HashMap<>();
private List roots = new ArrayList<>();
@Override
public Object transformTu
The former though is specifically what I see no use for. Do you have a
specific use case in mind that cannot be addressed by other mechanisms
(Tuple, dynamic-instantiation, etc)?
On Mon, Sep 12, 2016, 12:38 AM Vlad Mihalcea
wrote:
> Hi,
>
> We definitely need to address the ResultTranformer.
>
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
poss
17 matches
Mail list logo
