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,
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
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-
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
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
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>
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
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
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
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
16 matches
Mail list logo
