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
> 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
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
Hi all,
Sanne kindly pointed out to me the latest proposal by the OpenJDK team
around JDK 9 module and how they would handle frameworks needing access
to non exported types (Hibernate, dependency injection, etc).
If you are remotely into JDK9, please read it and provide feedback.
http://mail.open
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
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
Is there a more or less stable version of Hibernate 6 that can be used
for early testing?
I'd like to provide feedback from an integration point of view.
Are there any Hibernate 6 builds in a Maven repository?
If not, is there a plan for Alpha releases? I'd like to make sure my
schedule is clear
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>
It is still a WIP and is not yet buildable. But you can follow the
progress: https://github.com/sebersole/hibernate-core/tree/wip/6.0
On Tue, Sep 13, 2016 at 9:10 AM Christian Beikov
wrote:
> Is there a more or less stable version of Hibernate 6 that can be used
> for early testing?
> I'd like
Since Hibernate ORM 5.2, the method getTransaction() on Session needs
to behave according to EntityManager spec, which implies that it has
to throw an exception in certain circumstances which depend on the
configuration.
Hibernate Search used this method in various places, for example to
integrate
Hi!
As usual, the NoORM team meeting minutes.
16:26 < jbott> Meeting ended Tue Sep 13 14:25:49 2016 UTC. Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:26 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-09-
NIce! I never knew of this plugin, but there is a Gradle plugin for it as
well.
On Tue, Sep 13, 2016 at 9:33 AM Sanne Grinovero wrote:
> Since Hibernate ORM 5.2, the method getTransaction() on Session needs
> to behave according to EntityManager spec, which implies that it has
> to throw an exc
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,
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
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
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
16 matches
Mail list logo
