Breaking JBossStandAloneJtaPlatform backwards compatibility
by Sanne Grinovero
Hi Scott,
I see you changed JBossStandAloneJtaPlatform to use a new API in WildFly;
this breaks all existing applications using a generic "JBoss -
standalone" platform which isn't using the very latest WildFly.
I see that in many cases this type is auto-detected - and while
JBossStandAloneJtaPlatform causes an exception this is swallowed by
the HibernatePersistenceProvider as any exception is only mentioned at
debug level (line 61).
So two questions:
- could this be reverted and you introduce some new-gen
WildflyStandAloneJtaPlatform instead?
- bootstrap exceptions: may I change those to error level?
Thanks,
Sanne
7 years, 10 months
HIbernate OGM 5.4.0.Beta1 is out
by Fabio Massimo Ercoli
HIbernate OGM 5.4.0.Beta1 is ready!
Some improvement was the version upgrade for Hibernate ORM 5.3.0.Final and
Hibernate Search (5.10.0.Final),
the support for Infinispan Remote native and JPQL queries (without
requiring Hibernate Search)
and the use of cluster counters for local caches when generating sequences
with Infinispan Embedded.
All the details in the blog post:
*http://in.relation.to/2018/05/25/hibernate-ogm-5-4-Beta1-released/
<http://in.relation.to/2018/05/25/hibernate-ogm-5-4-Beta1-released/>*
Thanks, Fabio
--
FABIO MASSIMO ERCOLI
HIBERNATE TEAM
fabio.ercoli(a)redhat.com fabio(a)hibernate.org
<https://red.ht/sig>
7 years, 10 months
Preparing the 5.3.1 release
by Sanne Grinovero
Hi Steve,
are we free to release a 5.3.1 this weekend?
As I mentioned in the parallel thread "WildFly 14 requirements for
Hibernate libraries", we can still get some fixes for WildFly 13 but
the deadline is this weekend.
I think you and Andrea can keep the focus on the ORM6 meeting;
everyone else chipped in some fixes already.
Thanks,
Sanne
7 years, 10 months
Multiple ResultSets from JDBC execution
by Steve Ebersole
Execution of procedure calls, function calls and anonymous blocks can all
lead to JDBC returning us multiple ResultSets.
To account for this (for the first 2 anyway) JPA allows defining multiple
ResultSetMapping references for the StoredProcesdureQuery. Alternatively,
it allows specifying multiple "result classes". However, JPA is silently
on how a provider is to treat these. Specifically, are these "aggregated"
into a single "row reader"? Or do they represent individual row readers
specific to each expected ResultSet? In other words, are the ResultSets
heterogeneous or homogeneous?
At the moment, Hibernate treats these by building a single aggregated row
reader that it applies to reading all ResultSets. Like I said, JPA is
silent on what this "means" (and the TCK does not test it) so we are free
to interpret this as we see fit.
In retrospect I think the multiple ResultSetMappping case is probably best
interpreted using the "distinct row reader per ResultSet" approach. I'm
not so convinced that is always the best interpretation of the multiple
result classes case. But I also think these should probably be handled
consistently.
So what is everybody's preference here? Which interpretation do we pick?
Worth it to make this configurable (per-SF + per-Query)?
7 years, 10 months
