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>
6 years, 6 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
6 years, 6 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)?
6 years, 6 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...
6 years, 6 months
WildFly 14 requirements for Hibernate libraries
by Sanne Grinovero
Hi all,
good news first: WildFly 13 will include our latest Hibernate
libraries, in addition to the existing ones.
When booting WildFly 13 with the "-Dee8.preview.mode=true" property
set, it will use:
- Hibernate ORM 5.3
- Hibernate Search 5.10
- Hibernate Validator 6.0
(Validator 6 was available also in WildFly 12)
By default, for users not setting this preview mode, it will use the
older versions which were included in previous WildFly releases -
providing JPA 2.1 and EE7 compatibility only.
We're getting some requirements for WildFly 14 though, which needs to
be ready within 3 months.
In particular:
A] EE8 will be the only mode
So while today users have the ability to opt-in or ORM 5.3 and
companions, this will be enforced as the older libraries are removed.
Not much we need to do, other than further ensuring that people will
not have trouble. It's also an opportunity to get rid of unnecessary
dependencies.
B] we need to finish some backward compatibility work.
We did quite some work to ensure ORM 5.3 would be great at backward
compatibility but we left some pending work, e.g. the Compatibility
Transformer that David proposed is not available yet and it needs some
more details from us, such as a definitive list of the transformations
it will need to perform.
Also, the QE team didn't have a chance to review the work in detail
yet; I'm confident we did most of the work already but they might
raise the bar further or just have some questions, we will need to
work with them. I also hope we'll get more familiar with them and
their processes as clearly this isn't a one-off, we can all benefit
from working more closely with them for all future releases.
C] WildFly 14 is expected to work on both JDK8 and JDK11
Most work to support new JDKs has been done but we need to finish the
last details.
- CI jobs still not entirely working on JDK11
- Javassist might stay as an option but we need to make sure no
feature relies on it, as I don't think Javassist will be supportable
on JDK11
- consequentially, the Byte Buddy based alternative needs to be great
(some issues have been raised)
- some code to work on JDK11 will need to invoke APIs which were not
available in JDK8: are we going to release "multi-release jars"?
- resume the work on modernizing the XML parsers?
In particular, Byte Buddy on JDK11 will need access to the classloader
via VarHandles to enhance entities; I didn't investigate this
thoroughly yet but I believe I won't be able to give these references
to BB while relying exclusively on JDK8 APIs.
If we manage to improve anything by the 28th we can still include
micro-fixes in WildFly 13; in particular, if you are aware of any
blocker let's fix them now so that people can give us more detailed
feedback by actually using the EE8 preview mode.
(This includes possibly planning for some micro releases within a week)
Thanks,
Sanne
6 years, 6 months
