[hibernate-dev] Could we have a Hibernate 5.3 compatibility layer that includes the ORM 5.1 Hibernate Session class

[Sanne Grinovero]

Hi Scott,

remember ORM 6.0 doesn't exist yet. Technically 5.3 doesn't exist yet
either, but it's close.

I'd start working to get 5.3 included so that we can address all
integration issues, and additional unknowns caused by having multiple
versions. If when we're all done fixing such problems 6.0 will be out,
we'll re-evaluate the situation.

In the meantime we'll check if 6.0 is going to be strickly compatible
with 5.3: hard to answer on that in a definitive way when neither is
ready. Unless Steve knows of some *public API* which definitely needs
to break between 5.3 to 6.0? AFAIR last time we had such a
conversation there was no clear agreement on what extensions should be
considered public API *in the scope of WildFly's requirements*. Scott,
do you have an update on that, or maybe refresh our memories?

Thanks,
Sanne


On 8 February 2018 at 19:54, Scott Marlow <smarlow at redhat.com> wrote:
>
>
> On 02/08/2018 01:50 PM, Steve Ebersole wrote:
>>
>> What is meant by "(JPA/native application) compatible with the Hibernate
>> ORM versions that we include"?
>
>
> It means that for a while, we can only upgrade WildFly to newer Hibernate
> ORM versions that are compatible with one of the two Hibernate versions that
> we include with WildFly 12+.
>
>>
>> Both 5.3 and 6.0 are JPA 2.2, but 5.1 is JPA 2.1.  Does that mean they
>> violate that requirement?
>
>
> I think the 5.3 versus 6.0 question, is more will applications written
> against the (application level) Hibernate 5.3 ORM classes, work correctly
> against 6.0.  For determining which classes exactly, are application level
> classes, the Hibernate team should decide that.
>
> If the design for Hibernate ORM code changes, misses an application
> compatibility issue that we miss, that cannot be avoided.  However, when the
> WildFly team looks at the latest/greatest version of Hibernate ORM to
> include, we will face pressure against bringing in any newer ORM version
> that requires application coding/configuration changes.
>
>
>>
>>
>> On Thu, Feb 8, 2018 at 12:30 PM Scott Marlow <smarlow at redhat.com
>> <mailto:smarlow at redhat.com>> wrote:
>>
>>
>>
>>     On 01/31/2018 10:49 AM, Steve Ebersole wrote:
>>      > Not to mention, I'm really not even sure what this request
>>     "means".  As
>>      > we all understand 5.1 -> 5.2 unified
>>     SessionFactory/EntityManagerFactory
>>      > and Session/EntityManager, and that caused us to have to make
>>     changes to
>>      > certain method signatures - most notably `Session#getFlushMode`
>>     was one
>>      > of the problems.  Session defined that returning a FlushMode;
>> however
>>      > JPA also defined this same method, although poorly named IMO since
>> it
>>      > instead returns JPA's FlushModeType (so why the method is not
>> called
>>      > `#getFlushModeType` is beyond me.  Anyway the point is that there
>>     is no
>>      > way to rectify these - there is no way that we can define a
>> contract
>>      > that simultaneously conforms to both.
>>      >
>>      > As Sanne said, and as we all agreed during f2f, the best approach
>>     is to
>>      > have both versions available for use.
>>
>>     Which Hibernate ORM release would be best for the second version that
>> we
>>     include?  ORM 5.3 or 6.0?
>>
>>     Agreed that we will still include ORM 5.1, in WildFly.  For the second
>>     ORM version that we include (whatever the version is), we have an
>>     additional requirement now.  Future releases of WildFly need to be
>>     (JPA/native application) compatible with the Hibernate ORM versions
>> that
>>     we include.
>>
>>     We will be releasing WildFly more frequently, and want users to be
>> able
>>     to able to keep up with our pace, as we release more often.
>>
>>     Scott
>>
>