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, 5 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, 5 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, 5 months
Suggestions for alternative due to deprecation of Configuration access in ServiceContributor...
by Scott Marlow
For the WildFly use of ServiceContributor [1], which registers for each
SF/EMF, the 2lc RegionFactoryInitiator + JtaPlatform, I am worried that
we don't yet have a "per app deployment" way to disable the WF
ServiceContributorImpl.
I'm thinking that some applications (e.g. Spring) may not want to use
the WF 2lc RegionFactoryInitiator + JtaPlatform classes. To accomadate
that need, I'm thinking of introducing WF configuration properties for
controlling this:
* wildfly.jpa.jtaplatform will default to true but if set to false, [1]
will not call serviceRegistryBuilder.addInitiator(new
WildFlyCustomJtaPlatformInitiator()).
* wildfly.jpa.regionfactory will default to true but if set to false,
[1] will not call serviceRegistryBuilder.addInitiator(new
WildFlyCustomRegionFactoryInitiator()).
My request is that we keep the
StandardServiceRegistryBuilder.getSettings() call and document that in
the future, instead of removing it, we will change it to return a read
only copy of the configuration settings. Then, I can update [1] to
check for these new properties and know that I can depend on using
StandardServiceRegistryBuilder.getSettings().
An alternative could be to add a new method
StandardServiceRegistryBuilder.getReadOnlySettings().
I'd like to make the WF code change now for WF13, so a quick response is
appreciated! :)
Scott
[1]
https://github.com/scottmarlow/wildfly/blob/WFLY-10427/jpa/hibernate5_3/s...
7 years, 5 months
