From sanne at hibernate.org  Thu Feb  1 05:50:56 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 1 Feb 2018 10:50:56 +0000
Subject: [hibernate-dev] 5.3.0 release tomorrow
In-Reply-To: <CAFdSV9v-GpkW=Me=pJAqJtM00mXnU2qdzFx90ZoZ2V1tqfS2=g@mail.gmail.com>
References: <CAFdSV9thmwk+R-o70qnOAZwHHxGmQm2fry28ChS1cwhjV_td0Q@mail.gmail.com>
	<06cca534-ddef-ce5e-31cd-ee418094c360@hibernate.org>
	<CALt0+o-x2q9wd-4fu5oAAVsoHbUB7Rn60FKAeUegECH9sumvAg@mail.gmail.com>
	<CAFdSV9tLbfVkC9XQLGvVsSs2HFD+nYZJvv15WUs30qc_VmU6tA@mail.gmail.com>
	<CALt0+o-=L_YMZsxGc0yHDmnsj+d0cQhT-U73nG36nuNNFosEJg@mail.gmail.com>
	<CAFdSV9u27qemYq6TcKj-RYe5=s02E8vUySJcRmi7nwAkeOVPRQ@mail.gmail.com>
	<CALt0+o9opZHuDUHDDhw+Vddy-RAPfeR=zU8Y7sAnJ=3c637mmw@mail.gmail.com>
	<CAFdSV9v-GpkW=Me=pJAqJtM00mXnU2qdzFx90ZoZ2V1tqfS2=g@mail.gmail.com>
Message-ID: <CAFm4XO3ax70-9PXOTbjGnxLq7FGJX_HiJAhDVUFpb22yLJCpVQ@mail.gmail.com>

On 1 February 2018 at 02:03, Steve Ebersole <steve at hibernate.org> wrote:
> I am waiting until I hear back from Joel from Sonatype regarding disabling
> the JBoss Nexus -> OSSRH sync for ORM artifacts before I can release.

Just curious: is that a requirement to start releasing on OSSRH?

I was assuming that simply not pushing new things to JBoss Nexus would
have been enough for it to not fetch new things from it..

It would be nice to be able to start moving to OSSRH gradually, while
having the current Nexus still available as a fallback option.

Thanks,
Sanne



>
> On Wed, Jan 31, 2018 at 10:06 AM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> On Wed, Jan 31, 2018 at 4:54 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Yes, I agree.  As it is, it is very likely that in 2 weeks we will have
>>> ORM 5.3.0.CR1.  So even if you did do a OGM release at that time we are
>>> going to be limited in what exactly we can change if we find changes are
>>> needed.
>>>
>>> Interestingly this goes back to earlier discussions about "release
>>> early/often" for the purpose of identifying regressions.  Granted there
>>> y'all were talking about 5.2, but the same happens here from the ORM
>>> perspective in 5.3.  We need to not be dragging version non-stable releases
>>> out as we continue to wait for +1's from all integrators (Search, OGM,
>>> Spring, etc).
>>>
>>
>> Yes, for a lot of reasons (good and bad) we were really bad with the ORM
>> 5.2 support in OGM.
>>
>> We are very aware of that and the idea is to not do that again :).
>>
>> We (probably Davide) will let you know about our progress soon.
>>
>> --
>> Guillaume
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Thu Feb  1 08:28:26 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 1 Feb 2018 15:28:26 +0200
Subject: [hibernate-dev] 5.3.0 release tomorrow
In-Reply-To: <CAFdSV9v-GpkW=Me=pJAqJtM00mXnU2qdzFx90ZoZ2V1tqfS2=g@mail.gmail.com>
References: <CAFdSV9thmwk+R-o70qnOAZwHHxGmQm2fry28ChS1cwhjV_td0Q@mail.gmail.com>
	<06cca534-ddef-ce5e-31cd-ee418094c360@hibernate.org>
	<CALt0+o-x2q9wd-4fu5oAAVsoHbUB7Rn60FKAeUegECH9sumvAg@mail.gmail.com>
	<CAFdSV9tLbfVkC9XQLGvVsSs2HFD+nYZJvv15WUs30qc_VmU6tA@mail.gmail.com>
	<CALt0+o-=L_YMZsxGc0yHDmnsj+d0cQhT-U73nG36nuNNFosEJg@mail.gmail.com>
	<CAFdSV9u27qemYq6TcKj-RYe5=s02E8vUySJcRmi7nwAkeOVPRQ@mail.gmail.com>
	<CALt0+o9opZHuDUHDDhw+Vddy-RAPfeR=zU8Y7sAnJ=3c637mmw@mail.gmail.com>
	<CAFdSV9v-GpkW=Me=pJAqJtM00mXnU2qdzFx90ZoZ2V1tqfS2=g@mail.gmail.com>
Message-ID: <CA+gWKMDoqNUCcFXOA9fOCbVxU4Z6Xkf2ejdTQeAyfXvrvuTkNQ@mail.gmail.com>

Hi Steve,

Is it ok to commit on the master branch today or should we wait for 5.3 to
be released?

Vlad

On Thu, Feb 1, 2018 at 4:03 AM, Steve Ebersole <steve at hibernate.org> wrote:

> I am waiting until I hear back from Joel from Sonatype regarding disabling
> the JBoss Nexus -> OSSRH sync for ORM artifacts before I can release.
>
> On Wed, Jan 31, 2018 at 10:06 AM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
> > On Wed, Jan 31, 2018 at 4:54 PM, Steve Ebersole <steve at hibernate.org>
> > wrote:
> >
> >> Yes, I agree.  As it is, it is very likely that in 2 weeks we will have
> >> ORM 5.3.0.CR1.  So even if you did do a OGM release at that time we are
> >> going to be limited in what exactly we can change if we find changes are
> >> needed.
> >>
> >> Interestingly this goes back to earlier discussions about "release
> >> early/often" for the purpose of identifying regressions.  Granted there
> >> y'all were talking about 5.2, but the same happens here from the ORM
> >> perspective in 5.3.  We need to not be dragging version non-stable
> releases
> >> out as we continue to wait for +1's from all integrators (Search, OGM,
> >> Spring, etc).
> >>
> >
> > Yes, for a lot of reasons (good and bad) we were really bad with the ORM
> > 5.2 support in OGM.
> >
> > We are very aware of that and the idea is to not do that again :).
> >
> > We (probably Davide) will let you know about our progress soon.
> >
> > --
> > Guillaume
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Feb  1 08:34:00 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 01 Feb 2018 13:34:00 +0000
Subject: [hibernate-dev] 5.3.0 release tomorrow
In-Reply-To: <CA+gWKMDoqNUCcFXOA9fOCbVxU4Z6Xkf2ejdTQeAyfXvrvuTkNQ@mail.gmail.com>
References: <CAFdSV9thmwk+R-o70qnOAZwHHxGmQm2fry28ChS1cwhjV_td0Q@mail.gmail.com>
	<06cca534-ddef-ce5e-31cd-ee418094c360@hibernate.org>
	<CALt0+o-x2q9wd-4fu5oAAVsoHbUB7Rn60FKAeUegECH9sumvAg@mail.gmail.com>
	<CAFdSV9tLbfVkC9XQLGvVsSs2HFD+nYZJvv15WUs30qc_VmU6tA@mail.gmail.com>
	<CALt0+o-=L_YMZsxGc0yHDmnsj+d0cQhT-U73nG36nuNNFosEJg@mail.gmail.com>
	<CAFdSV9u27qemYq6TcKj-RYe5=s02E8vUySJcRmi7nwAkeOVPRQ@mail.gmail.com>
	<CALt0+o9opZHuDUHDDhw+Vddy-RAPfeR=zU8Y7sAnJ=3c637mmw@mail.gmail.com>
	<CAFdSV9v-GpkW=Me=pJAqJtM00mXnU2qdzFx90ZoZ2V1tqfS2=g@mail.gmail.com>
	<CA+gWKMDoqNUCcFXOA9fOCbVxU4Z6Xkf2ejdTQeAyfXvrvuTkNQ@mail.gmail.com>
Message-ID: <CAFdSV9tuVNGvZ8G_pzReCB6zWvBCCZ8X+TCoEkrP+TNpo-T2Mw@mail.gmail.com>

If it's stuff that's ready to go, go for it.  I'll send out an email when
I'm ready to start.

On Thu, Feb 1, 2018, 7:28 AM Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> Hi Steve,
>
> Is it ok to commit on the master branch today or should we wait for 5.3 to
> be released?
>
> Vlad
> On Thu, Feb 1, 2018 at 4:03 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I am waiting until I hear back from Joel from Sonatype regarding disabling
>> the JBoss Nexus -> OSSRH sync for ORM artifacts before I can release.
>>
>> On Wed, Jan 31, 2018 at 10:06 AM Guillaume Smet <guillaume.smet at gmail.com
>> >
>> wrote:
>>
>
>> > On Wed, Jan 31, 2018 at 4:54 PM, Steve Ebersole <steve at hibernate.org>
>> > wrote:
>> >
>> >> Yes, I agree.  As it is, it is very likely that in 2 weeks we will have
>> >> ORM 5.3.0.CR1.  So even if you did do a OGM release at that time we are
>> >> going to be limited in what exactly we can change if we find changes
>> are
>> >> needed.
>> >>
>> >> Interestingly this goes back to earlier discussions about "release
>> >> early/often" for the purpose of identifying regressions.  Granted there
>> >> y'all were talking about 5.2, but the same happens here from the ORM
>> >> perspective in 5.3.  We need to not be dragging version non-stable
>> releases
>> >> out as we continue to wait for +1's from all integrators (Search, OGM,
>> >> Spring, etc).
>> >>
>> >
>> > Yes, for a lot of reasons (good and bad) we were really bad with the ORM
>> > 5.2 support in OGM.
>> >
>> > We are very aware of that and the idea is to not do that again :).
>> >
>> > We (probably Davide) will let you know about our progress soon.
>> >
>> > --
>> > Guillaume
>> >
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From mihalcea.vlad at gmail.com  Thu Feb  1 08:39:53 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 1 Feb 2018 15:39:53 +0200
Subject: [hibernate-dev] Should EntityManager#refresh retain an existing
	lock?
In-Reply-To: <CAFDzhiRbG=VWKvMuf9h+fQX=3mAkrCTxKtY72MQWj90orFdGMg@mail.gmail.com>
References: <CAFDzhiS-T-bNbPAS3zqUmvVL1YE9XxeinZRTn5kg_9tGfCn8+g@mail.gmail.com>
	<CAFm4XO00KFXuhB6j9ZFrac8mwfZ5xbxs-TJm55uMoCJbu30qgg@mail.gmail.com>
	<CAFDzhiSEsBgwLC6t8J6tH3FRnL5EbkHYHDi-xoX+js9dE3ajSQ@mail.gmail.com>
	<CAFdSV9sy9DZdtfP30KyetAVavfO9+4ZrjytBOidwOd3pkvEWZA@mail.gmail.com>
	<CAFDzhiRbG=VWKvMuf9h+fQX=3mAkrCTxKtY72MQWj90orFdGMg@mail.gmail.com>
Message-ID: <CA+gWKMCar73Y2LThNaFZSKjaWyTt_REncaVhmWP1XVva0Dr8-Q@mail.gmail.com>

Hi Gail,

Steve is right. Database locks cannot be released unless you end the
transaction and that's how it works on any RDBMS, either in 2PL Mode or
MVCC.

As for optimistic locks:

1. LockModeType.OPTIMISTIC

The check is done at the end of the end of the transaction. Refresh will
only update the version, but the check should still be done so we should
not probably switch to LockModeTypeNONE.

2. OPTIMISTIC_FORCE_INCREMENT,

This one triggers a version increment in a different entity, so it should
not be affected by the refresh of our entity.

Vlad

On Thu, Feb 1, 2018 at 1:12 AM, Gail Badner <gbadner at redhat.com> wrote:

> OK, sounds good.
>
> Thanks,
> Gail
>
> On Wed, Jan 31, 2018 at 2:38 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > It is possible to call EntityManager#lock(Object entity, LockModeType
> >> lockMode) with a lower-level lock, but that request will be ignored.
> >> Hibernate will only upgrade a lock.
> >>
> >
> > Sure, this is in keeping with most (all?) databases - a transaction can
> > only acquire more restrictive locks.
> >
> >
> >
> >> I think that clarifies retaining the same lock-level for the entity when
> >> calling EntityManager#refresh(Object entity).
> >>
> >> If no one has any comments that disagree with this in the next couple of
> >> days, I'll go with that.
> >>
> >
> > That's the correct handling.
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Thu Feb  1 08:41:58 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 1 Feb 2018 15:41:58 +0200
Subject: [hibernate-dev] 5.3.0 release tomorrow
In-Reply-To: <CAFdSV9tuVNGvZ8G_pzReCB6zWvBCCZ8X+TCoEkrP+TNpo-T2Mw@mail.gmail.com>
References: <CAFdSV9thmwk+R-o70qnOAZwHHxGmQm2fry28ChS1cwhjV_td0Q@mail.gmail.com>
	<06cca534-ddef-ce5e-31cd-ee418094c360@hibernate.org>
	<CALt0+o-x2q9wd-4fu5oAAVsoHbUB7Rn60FKAeUegECH9sumvAg@mail.gmail.com>
	<CAFdSV9tLbfVkC9XQLGvVsSs2HFD+nYZJvv15WUs30qc_VmU6tA@mail.gmail.com>
	<CALt0+o-=L_YMZsxGc0yHDmnsj+d0cQhT-U73nG36nuNNFosEJg@mail.gmail.com>
	<CAFdSV9u27qemYq6TcKj-RYe5=s02E8vUySJcRmi7nwAkeOVPRQ@mail.gmail.com>
	<CALt0+o9opZHuDUHDDhw+Vddy-RAPfeR=zU8Y7sAnJ=3c637mmw@mail.gmail.com>
	<CAFdSV9v-GpkW=Me=pJAqJtM00mXnU2qdzFx90ZoZ2V1tqfS2=g@mail.gmail.com>
	<CA+gWKMDoqNUCcFXOA9fOCbVxU4Z6Xkf2ejdTQeAyfXvrvuTkNQ@mail.gmail.com>
	<CAFdSV9tuVNGvZ8G_pzReCB6zWvBCCZ8X+TCoEkrP+TNpo-T2Mw@mail.gmail.com>
Message-ID: <CA+gWKMD07G-rg_D1AP3GQt_EF+NPKaUP6urqO8Ov3+SN7PPjRA@mail.gmail.com>

Thanks,

I was having some Pull Requests which I pushed to 5.2.13 and wanted to have
them in 5.3 as well.

I will add them now.

Vlad

On Thu, Feb 1, 2018 at 3:34 PM, Steve Ebersole <steve at hibernate.org> wrote:

> If it's stuff that's ready to go, go for it.  I'll send out an email when
> I'm ready to start.
>
> On Thu, Feb 1, 2018, 7:28 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi Steve,
>>
>> Is it ok to commit on the master branch today or should we wait for 5.3
>> to be released?
>>
>> Vlad
>> On Thu, Feb 1, 2018 at 4:03 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> I am waiting until I hear back from Joel from Sonatype regarding
>>> disabling
>>> the JBoss Nexus -> OSSRH sync for ORM artifacts before I can release.
>>>
>>> On Wed, Jan 31, 2018 at 10:06 AM Guillaume Smet <
>>> guillaume.smet at gmail.com>
>>> wrote:
>>>
>>
>>> > On Wed, Jan 31, 2018 at 4:54 PM, Steve Ebersole <steve at hibernate.org>
>>> > wrote:
>>> >
>>> >> Yes, I agree.  As it is, it is very likely that in 2 weeks we will
>>> have
>>> >> ORM 5.3.0.CR1.  So even if you did do a OGM release at that time we
>>> are
>>> >> going to be limited in what exactly we can change if we find changes
>>> are
>>> >> needed.
>>> >>
>>> >> Interestingly this goes back to earlier discussions about "release
>>> >> early/often" for the purpose of identifying regressions.  Granted
>>> there
>>> >> y'all were talking about 5.2, but the same happens here from the ORM
>>> >> perspective in 5.3.  We need to not be dragging version non-stable
>>> releases
>>> >> out as we continue to wait for +1's from all integrators (Search, OGM,
>>> >> Spring, etc).
>>> >>
>>> >
>>> > Yes, for a lot of reasons (good and bad) we were really bad with the
>>> ORM
>>> > 5.2 support in OGM.
>>> >
>>> > We are very aware of that and the idea is to not do that again :).
>>> >
>>> > We (probably Davide) will let you know about our progress soon.
>>> >
>>> > --
>>> > Guillaume
>>> >
>>>
>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>

From mihalcea.vlad at gmail.com  Thu Feb  1 08:43:53 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 1 Feb 2018 15:43:53 +0200
Subject: [hibernate-dev] Minor changes to the website
In-Reply-To: <CALt0+o-W_XDLf22gsDoMODimX8KLaazPHL3i7wBGNQGuHib0vA@mail.gmail.com>
References: <CALt0+o-W_XDLf22gsDoMODimX8KLaazPHL3i7wBGNQGuHib0vA@mail.gmail.com>
Message-ID: <CA+gWKMAi3C=fS9dbESdUH8u9c_UbZzHBbUWwgwq+YT1XcmDaRQ@mail.gmail.com>

Great job Guillaume,

It looks awesome.

Vlad

On Wed, Jan 31, 2018 at 2:15 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> Just so you know, I just made a few minor changes to the website:
> - in the Releases dymanic submenu, you now have a label stating "latest
> stable"/"development" to make it clearer what the versions are (it's
> especially useful at this point of the ORM development for instance as 5.3
> is the latest but not yet considered stable)
> - I made the Documentation entry menu of ORM dynamic with a submenu
> following the same principles as for Releases. It avoids going to the
> latest then using the dropdown at the top (I kept the dropdown anyway)
>
> In passing, I also added a placeholder page for the ORM 5.3 doc stating it
> will be available soon.
>
> HTH
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Feb  1 12:24:00 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 01 Feb 2018 17:24:00 +0000
Subject: [hibernate-dev] 5.3.0 release tomorrow
In-Reply-To: <CA+gWKMD07G-rg_D1AP3GQt_EF+NPKaUP6urqO8Ov3+SN7PPjRA@mail.gmail.com>
References: <CAFdSV9thmwk+R-o70qnOAZwHHxGmQm2fry28ChS1cwhjV_td0Q@mail.gmail.com>
	<06cca534-ddef-ce5e-31cd-ee418094c360@hibernate.org>
	<CALt0+o-x2q9wd-4fu5oAAVsoHbUB7Rn60FKAeUegECH9sumvAg@mail.gmail.com>
	<CAFdSV9tLbfVkC9XQLGvVsSs2HFD+nYZJvv15WUs30qc_VmU6tA@mail.gmail.com>
	<CALt0+o-=L_YMZsxGc0yHDmnsj+d0cQhT-U73nG36nuNNFosEJg@mail.gmail.com>
	<CAFdSV9u27qemYq6TcKj-RYe5=s02E8vUySJcRmi7nwAkeOVPRQ@mail.gmail.com>
	<CALt0+o9opZHuDUHDDhw+Vddy-RAPfeR=zU8Y7sAnJ=3c637mmw@mail.gmail.com>
	<CAFdSV9v-GpkW=Me=pJAqJtM00mXnU2qdzFx90ZoZ2V1tqfS2=g@mail.gmail.com>
	<CA+gWKMDoqNUCcFXOA9fOCbVxU4Z6Xkf2ejdTQeAyfXvrvuTkNQ@mail.gmail.com>
	<CAFdSV9tuVNGvZ8G_pzReCB6zWvBCCZ8X+TCoEkrP+TNpo-T2Mw@mail.gmail.com>
	<CA+gWKMD07G-rg_D1AP3GQt_EF+NPKaUP6urqO8Ov3+SN7PPjRA@mail.gmail.com>
Message-ID: <CAFdSV9sDLsftRxik=Vy9axszajfoP1w7Fg4mh737HVxcVkQhtQ@mail.gmail.com>

Starting release

On Thu, Feb 1, 2018 at 7:42 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Thanks,
>
> I was having some Pull Requests which I pushed to 5.2.13 and wanted to
> have them in 5.3 as well.
>
> I will add them now.
>
> Vlad
>
> On Thu, Feb 1, 2018 at 3:34 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> If it's stuff that's ready to go, go for it.  I'll send out an email when
>> I'm ready to start.
>>
>> On Thu, Feb 1, 2018, 7:28 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi Steve,
>>>
>>> Is it ok to commit on the master branch today or should we wait for 5.3
>>> to be released?
>>>
>>> Vlad
>>> On Thu, Feb 1, 2018 at 4:03 AM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> I am waiting until I hear back from Joel from Sonatype regarding
>>>> disabling
>>>> the JBoss Nexus -> OSSRH sync for ORM artifacts before I can release.
>>>>
>>>> On Wed, Jan 31, 2018 at 10:06 AM Guillaume Smet <
>>>> guillaume.smet at gmail.com>
>>>> wrote:
>>>>
>>>
>>>> > On Wed, Jan 31, 2018 at 4:54 PM, Steve Ebersole <steve at hibernate.org>
>>>> > wrote:
>>>> >
>>>> >> Yes, I agree.  As it is, it is very likely that in 2 weeks we will
>>>> have
>>>> >> ORM 5.3.0.CR1.  So even if you did do a OGM release at that time we
>>>> are
>>>> >> going to be limited in what exactly we can change if we find changes
>>>> are
>>>> >> needed.
>>>> >>
>>>> >> Interestingly this goes back to earlier discussions about "release
>>>> >> early/often" for the purpose of identifying regressions.  Granted
>>>> there
>>>> >> y'all were talking about 5.2, but the same happens here from the ORM
>>>> >> perspective in 5.3.  We need to not be dragging version non-stable
>>>> releases
>>>> >> out as we continue to wait for +1's from all integrators (Search,
>>>> OGM,
>>>> >> Spring, etc).
>>>> >>
>>>> >
>>>> > Yes, for a lot of reasons (good and bad) we were really bad with the
>>>> ORM
>>>> > 5.2 support in OGM.
>>>> >
>>>> > We are very aware of that and the idea is to not do that again :).
>>>> >
>>>> > We (probably Davide) will let you know about our progress soon.
>>>> >
>>>> > --
>>>> > Guillaume
>>>> >
>>>>
>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>

From guillaume.smet at gmail.com  Thu Feb  1 18:18:59 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 2 Feb 2018 00:18:59 +0100
Subject: [hibernate-dev] NoORM IRC meeting minutes
Message-ID: <CALt0+o-aHYuZfjjAwA-9zjOY8JAev+c0MGMEb6A+_093_tKBug@mail.gmail.com>

Hi,

Just happened to me that I forgot to send the email with the minutes of
this week's NoORM meeting.

Here they are:
15:55 < jbott> Meeting ended Tue Jan 30 14:55:28 2018 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:55 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-01-30-14.00.html
15:55 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-01-30-14.00.txt
15:55 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-01-30-14.00.log.html

-- 
Guillaume

From steve at hibernate.org  Thu Feb  1 20:26:02 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 02 Feb 2018 01:26:02 +0000
Subject: [hibernate-dev] hibernate.org ORM release series page
Message-ID: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>

Now that I've moved ORM publishing to Bintray some of the layout of
hibernate.org in regards to releases is not-so-nice.  Most of this comes
into play in the `project-releases-series.html.haml` file use as the layout
for these "series" pages.

Specifically:

   1. Some of the text injected is just wrong.  "Maven artifacts of
   Hibernate ORM are published to Maven Central and to the JBoss Maven
   Repository. Refer to the Maven Getting Started guide on the Jboss Wiki for
   more information on how to configure Maven."  Most of that is now
   inaccurate.
   2. One of the niceties of moving to Bintray is having a singular URL to
   refer to the artifacts included in the release.  E.g.
   https://bintray.com/hibernate/artifacts/hibernate-orm/5.3.0.Beta2.  The
   layout here though is set up to list out each artifact individually.

I'd like to change this for ORM 5.3 moving forward such that the "Maven,
Gradle..." section simply points to the Bintray URL, as well as changing
that text to be ore accurate.  Is this going to be as simple as adding a
new layout (`project-releases-series-bintray.html.haml`?) and using that as
the layout for http://hibernate.org/orm/releases/5.3/ ?

From yoann at hibernate.org  Fri Feb  2 02:32:20 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Fri, 02 Feb 2018 07:32:20 +0000
Subject: [hibernate-dev] hibernate.org ORM release series page
In-Reply-To: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>
References: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>
Message-ID: <CAEqagpp=S_wmVx7HjtqH1Mwk51fxYyGMmCD+dbKqkthHMC_dwQ@mail.gmail.com>

>  Is this going to be as simple as adding a
new layout (`project-releases-series-bintray.html.haml`?) and using that as
the layout for http://hibernate.org/orm/releases/5.3/ ?

It should be, yes. Though a better option might be to introduce switches
based on the project, especially if you only want to change the "Maven,
gradle..." section and the URL for specific releases. That way, the other
parts of the page would still stay the same.

Anyway... We also have issues with the Nexus links, so I'll try to fix both
issues, push to staging and report here. Then you can iterate on what I
started (wording, ...).

On Fri, 2 Feb 2018 at 02:26 Steve Ebersole <steve at hibernate.org> wrote:

> Now that I've moved ORM publishing to Bintray some of the layout of
> hibernate.org in regards to releases is not-so-nice.  Most of this comes
> into play in the `project-releases-series.html.haml` file use as the layout
> for these "series" pages.
>
> Specifically:
>
>    1. Some of the text injected is just wrong.  "Maven artifacts of
>    Hibernate ORM are published to Maven Central and to the JBoss Maven
>    Repository. Refer to the Maven Getting Started guide on the Jboss Wiki
> for
>    more information on how to configure Maven."  Most of that is now
>    inaccurate.
>    2. One of the niceties of moving to Bintray is having a singular URL to
>    refer to the artifacts included in the release.  E.g.
>    https://bintray.com/hibernate/artifacts/hibernate-orm/5.3.0.Beta2.  The
>    layout here though is set up to list out each artifact individually.
>
> I'd like to change this for ORM 5.3 moving forward such that the "Maven,
> Gradle..." section simply points to the Bintray URL, as well as changing
> that text to be ore accurate.  Is this going to be as simple as adding a
> new layout (`project-releases-series-bintray.html.haml`?) and using that as
> the layout for http://hibernate.org/orm/releases/5.3/ ?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From fercoli at redhat.com  Fri Feb  2 03:24:02 2018
From: fercoli at redhat.com (Fabio Massimo Ercoli)
Date: Fri, 2 Feb 2018 09:24:02 +0100
Subject: [hibernate-dev] Hiberante OGM Infinispan Remote dialect - Execute
 the command queue as a single Infispan Remote Server Task
Message-ID: <CAFiQRE87L6HrNZc+P+so2PXhm4=n7a2dz5roTqkfneJNA97_aQ@mail.gmail.com>

I'm Fabio, nice to meet you.

Speaking of the current implementation of the Infinispan remote dialect of
Hibernate OGM, working on issue OGM-1206 and talking with Davide I noticed
that the unit of work commands are executed (flushed to datastore) at the
end of the transaction itself.
In particular I noticed that the commands are stored in a transaction
scoped object of type org.hibernate.ogm.dialect.batch.spi.OperationsQueue.

Instead of perfom one remote invocation for each command in the method
 org.hibernate.ogm.dialect.impl.BatchOperationsDelegator::executeBatch
maybe we could invoke a proper Infispan Remote Server Task to execute the
command queue on server side as a bulk operation.

Moving the execution of the server-side command list (Infinispan) we would
have the advantage of reducing remote interactions. Moreover and above all
the execution of the command queue would be a transactional work unit, on
which could be apply a Repeteable Read isolation level, for instance.

The solution would not solve the need for an XA client instead, but it
could be adopted by customers interested in local transactions.

What do you think about it?
Can I open a Jira issue?

Fabio

-- 

FABIO MASSIMO ERCOLI

Senior Software Engineer - Hibernate & Data Platform

Red Hat <https://www.redhat.com/>

fabio.ercoli at redhat.com    M: (+39)-329.8681441
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>

From steve at hibernate.org  Fri Feb  2 08:19:04 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 02 Feb 2018 13:19:04 +0000
Subject: [hibernate-dev] hibernate.org ORM release series page
In-Reply-To: <CAEqagpp=S_wmVx7HjtqH1Mwk51fxYyGMmCD+dbKqkthHMC_dwQ@mail.gmail.com>
References: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>
	<CAEqagpp=S_wmVx7HjtqH1Mwk51fxYyGMmCD+dbKqkthHMC_dwQ@mail.gmail.com>
Message-ID: <CAFdSV9s4NfNdj5uzNg0U0=TuHFiHriS45NcPe51VamfAH8xbOw@mail.gmail.com>

IIUC, a "switch based on the project" is not going to be enough.  For the
orm project we'd also then need to know whether a series is "5.3 or later":

if ( page.project == "orm" && series >= 5.3 ) {
// bintray
...
}
else {
// as before
}

I'm not sure how to do that `series >= 5.3` piece.  I guess I'll look at
what you do on staging



On Fri, Feb 2, 2018 at 1:32 AM Yoann Rodiere <yoann at hibernate.org> wrote:

> >  Is this going to be as simple as adding a
> new layout (`project-releases-series-bintray.html.haml`?) and using that
> as
> the layout for http://hibernate.org/orm/releases/5.3/ ?
>
> It should be, yes. Though a better option might be to introduce switches
> based on the project, especially if you only want to change the "Maven,
> gradle..." section and the URL for specific releases. That way, the other
> parts of the page would still stay the same.
>
> Anyway... We also have issues with the Nexus links, so I'll try to fix
> both issues, push to staging and report here. Then you can iterate on what
> I started (wording, ...).
>
> On Fri, 2 Feb 2018 at 02:26 Steve Ebersole <steve at hibernate.org> wrote:
>
>> Now that I've moved ORM publishing to Bintray some of the layout of
>> hibernate.org in regards to releases is not-so-nice.  Most of this comes
>> into play in the `project-releases-series.html.haml` file use as the
>> layout
>> for these "series" pages.
>>
>> Specifically:
>>
>>    1. Some of the text injected is just wrong.  "Maven artifacts of
>
>
>>    Hibernate ORM are published to Maven Central and to the JBoss Maven
>>    Repository. Refer to the Maven Getting Started guide on the Jboss Wiki
>> for
>>    more information on how to configure Maven."  Most of that is now
>>    inaccurate.
>>
>    2. One of the niceties of moving to Bintray is having a singular URL to
>
>
>>    refer to the artifacts included in the release.  E.g.
>>    https://bintray.com/hibernate/artifacts/hibernate-orm/5.3.0.Beta2.
>> The
>>    layout here though is set up to list out each artifact individually.
>>
>> I'd like to change this for ORM 5.3 moving forward such that the "Maven,
>> Gradle..." section simply points to the Bintray URL, as well as changing
>> that text to be ore accurate.  Is this going to be as simple as adding a
>> new layout (`project-releases-series-bintray.html.haml`?) and using that
>> as
>> the layout for http://hibernate.org/orm/releases/5.3/ ?
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> --
> Yoann Rodiere
> yoann at hibernate.org / yrodiere at redhat.com
> Software Engineer
> Hibernate NoORM team
>

From sanne at hibernate.org  Fri Feb  2 08:40:27 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 2 Feb 2018 13:40:27 +0000
Subject: [hibernate-dev] hibernate.org ORM release series page
In-Reply-To: <CAFdSV9s4NfNdj5uzNg0U0=TuHFiHriS45NcPe51VamfAH8xbOw@mail.gmail.com>
References: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>
	<CAEqagpp=S_wmVx7HjtqH1Mwk51fxYyGMmCD+dbKqkthHMC_dwQ@mail.gmail.com>
	<CAFdSV9s4NfNdj5uzNg0U0=TuHFiHriS45NcPe51VamfAH8xbOw@mail.gmail.com>
Message-ID: <CAFm4XO15ewG+0oH5h2P8-PH1f1+84Fqy0k3TVJoH42MosFTyyg@mail.gmail.com>

Couldn't we just have "All Hibernate libraries are available in Maven Central" ?

I'd like to keep things simple, both for us and for users.

On 2 February 2018 at 13:19, Steve Ebersole <steve at hibernate.org> wrote:
> IIUC, a "switch based on the project" is not going to be enough.  For the
> orm project we'd also then need to know whether a series is "5.3 or later":
>
> if ( page.project == "orm" && series >= 5.3 ) {
> // bintray
> ...
> }
> else {
> // as before
> }
>
> I'm not sure how to do that `series >= 5.3` piece.  I guess I'll look at
> what you do on staging
>
>
>
> On Fri, Feb 2, 2018 at 1:32 AM Yoann Rodiere <yoann at hibernate.org> wrote:
>
>> >  Is this going to be as simple as adding a
>> new layout (`project-releases-series-bintray.html.haml`?) and using that
>> as
>> the layout for http://hibernate.org/orm/releases/5.3/ ?
>>
>> It should be, yes. Though a better option might be to introduce switches
>> based on the project, especially if you only want to change the "Maven,
>> gradle..." section and the URL for specific releases. That way, the other
>> parts of the page would still stay the same.
>>
>> Anyway... We also have issues with the Nexus links, so I'll try to fix
>> both issues, push to staging and report here. Then you can iterate on what
>> I started (wording, ...).
>>
>> On Fri, 2 Feb 2018 at 02:26 Steve Ebersole <steve at hibernate.org> wrote:
>>
>>> Now that I've moved ORM publishing to Bintray some of the layout of
>>> hibernate.org in regards to releases is not-so-nice.  Most of this comes
>>> into play in the `project-releases-series.html.haml` file use as the
>>> layout
>>> for these "series" pages.
>>>
>>> Specifically:
>>>
>>>    1. Some of the text injected is just wrong.  "Maven artifacts of
>>
>>
>>>    Hibernate ORM are published to Maven Central and to the JBoss Maven
>>>    Repository. Refer to the Maven Getting Started guide on the Jboss Wiki
>>> for
>>>    more information on how to configure Maven."  Most of that is now
>>>    inaccurate.
>>>
>>    2. One of the niceties of moving to Bintray is having a singular URL to
>>
>>
>>>    refer to the artifacts included in the release.  E.g.
>>>    https://bintray.com/hibernate/artifacts/hibernate-orm/5.3.0.Beta2.
>>> The
>>>    layout here though is set up to list out each artifact individually.
>>>
>>> I'd like to change this for ORM 5.3 moving forward such that the "Maven,
>>> Gradle..." section simply points to the Bintray URL, as well as changing
>>> that text to be ore accurate.  Is this going to be as simple as adding a
>>> new layout (`project-releases-series-bintray.html.haml`?) and using that
>>> as
>>> the layout for http://hibernate.org/orm/releases/5.3/ ?
>>>
>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> --
>> Yoann Rodiere
>> yoann at hibernate.org / yrodiere at redhat.com
>> Software Engineer
>> Hibernate NoORM team
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at gmail.com  Fri Feb  2 08:44:01 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 2 Feb 2018 14:44:01 +0100
Subject: [hibernate-dev] hibernate.org ORM release series page
In-Reply-To: <CAFdSV9s4NfNdj5uzNg0U0=TuHFiHriS45NcPe51VamfAH8xbOw@mail.gmail.com>
References: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>
	<CAEqagpp=S_wmVx7HjtqH1Mwk51fxYyGMmCD+dbKqkthHMC_dwQ@mail.gmail.com>
	<CAFdSV9s4NfNdj5uzNg0U0=TuHFiHriS45NcPe51VamfAH8xbOw@mail.gmail.com>
Message-ID: <CALt0+o_Ft2=CHfdXox0_47uJFSHV3NghzQoqc+BLF8xGtE-CyA@mail.gmail.com>

On Fri, Feb 2, 2018 at 2:19 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I'm not sure how to do that `series >= 5.3` piece.  I guess I'll look at
> what you do on staging


What I have done so far to manage this sort of things is to add metadata to
the series files.

-- 
Guillaume

From yoann at hibernate.org  Fri Feb  2 09:06:30 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Fri, 02 Feb 2018 14:06:30 +0000
Subject: [hibernate-dev] hibernate.org ORM release series page
In-Reply-To: <CALt0+o_Ft2=CHfdXox0_47uJFSHV3NghzQoqc+BLF8xGtE-CyA@mail.gmail.com>
References: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>
	<CAEqagpp=S_wmVx7HjtqH1Mwk51fxYyGMmCD+dbKqkthHMC_dwQ@mail.gmail.com>
	<CAFdSV9s4NfNdj5uzNg0U0=TuHFiHriS45NcPe51VamfAH8xbOw@mail.gmail.com>
	<CALt0+o_Ft2=CHfdXox0_47uJFSHV3NghzQoqc+BLF8xGtE-CyA@mail.gmail.com>
Message-ID: <CAEqagprHd3iuMh2FyhKJUW1SEUhLwyKMrenOr4-34_nBeZSJmw@mail.gmail.com>

> IIUC, a "switch based on the project" is not going to be enough.  For the
orm project we'd also then need to know whether a series is "5.3 or later":

It's even worse, as 5.3.0.Beta1 is on the JBoss Nexus but Beta2 is on
Bintray,,,

Anyway, I managed to get something. It's on staging, please give some
feedback - preferably "it's wonderful, let's keep it that way" or "nice,
but I'll make some changes, please merge" ;)

   - http://staging.hibernate.org/orm/releases/5.3/
   - http://staging.hibernate.org/search/releases/5.9/
   - http://staging.hibernate.org/validator/releases/6.0/
   - http://staging.hibernate.org/validator/releases/5.4/
   - http://staging.hibernate.org/ogm/releases/5.2/

@Guillaume, all: I also changed the links of other projects to point to
Maven Central instead of the JBoss Nexus, because the JBoss Nexus requires
authentication. And, well, also because... Nexus.

On Fri, 2 Feb 2018 at 14:44 Guillaume Smet <guillaume.smet at gmail.com> wrote:

> On Fri, Feb 2, 2018 at 2:19 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I'm not sure how to do that `series >= 5.3` piece.  I guess I'll look at
>> what you do on staging
>
>
> What I have done so far to manage this sort of things is to add metadata
> to the series files.
>
> --
> Guillaume
>
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From guillaume.smet at gmail.com  Fri Feb  2 09:36:04 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 2 Feb 2018 15:36:04 +0100
Subject: [hibernate-dev] hibernate.org ORM release series page
In-Reply-To: <CAEqagprHd3iuMh2FyhKJUW1SEUhLwyKMrenOr4-34_nBeZSJmw@mail.gmail.com>
References: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>
	<CAEqagpp=S_wmVx7HjtqH1Mwk51fxYyGMmCD+dbKqkthHMC_dwQ@mail.gmail.com>
	<CAFdSV9s4NfNdj5uzNg0U0=TuHFiHriS45NcPe51VamfAH8xbOw@mail.gmail.com>
	<CALt0+o_Ft2=CHfdXox0_47uJFSHV3NghzQoqc+BLF8xGtE-CyA@mail.gmail.com>
	<CAEqagprHd3iuMh2FyhKJUW1SEUhLwyKMrenOr4-34_nBeZSJmw@mail.gmail.com>
Message-ID: <CALt0+o8mbp3BX0_Pa5q9vfYO9VC_TWuEkPS+xmtRJ0wfJm-JPA@mail.gmail.com>

On Fri, Feb 2, 2018 at 3:06 PM, Yoann Rodiere <yoann at hibernate.org> wrote:

> @Guillaume, all: I also changed the links of other projects to point to
> Maven Central instead of the JBoss Nexus, because the JBoss Nexus requires
> authentication. And, well, also because... Nexus.
>

Frankly, I find the new Maven Central links (we used JBoss Nexus before
that) you created far more useful than the Bintray page.

Compare:
https://search.maven.org/#search%7Cga%7C1%7Cg%3Aorg.hibernate.validator%20AND%20a%3Ahibernate-validator%2A%20AND%20v%3A6.0.7.Final
with
https://bintray.com/hibernate//artifacts/hibernate-orm/5.3.0.Beta2#

One goes straight to the point and for the other, it's not that obvious.

And this page is very nice too:
https://search.maven.org/#artifactdetails%7Corg.hibernate.validator%7Chibernate-validator-relocation%7C6.0.7.Final%7Cpom

On Bintray, the first artifact presented is agroal which is a bit weird
(yeah I know, alphabetical order but we do better on our pages).

If it were me I would vote for having this layout
http://staging.hibernate.org/validator/releases/6.0/ + the link to
search.maven.org for all the projects. I don't think the Bintray page is
better than what you did with search.maven.org.

By the way, Bintray should test its UI with Firefox too, it's full of
annoying usability bugs (I experienced 2 just by checking the ORM page)...

-- 
Guillaume

From steve at hibernate.org  Fri Feb  2 10:00:48 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 02 Feb 2018 15:00:48 +0000
Subject: [hibernate-dev] hibernate.org ORM release series page
In-Reply-To: <CALt0+o8mbp3BX0_Pa5q9vfYO9VC_TWuEkPS+xmtRJ0wfJm-JPA@mail.gmail.com>
References: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>
	<CAEqagpp=S_wmVx7HjtqH1Mwk51fxYyGMmCD+dbKqkthHMC_dwQ@mail.gmail.com>
	<CAFdSV9s4NfNdj5uzNg0U0=TuHFiHriS45NcPe51VamfAH8xbOw@mail.gmail.com>
	<CALt0+o_Ft2=CHfdXox0_47uJFSHV3NghzQoqc+BLF8xGtE-CyA@mail.gmail.com>
	<CAEqagprHd3iuMh2FyhKJUW1SEUhLwyKMrenOr4-34_nBeZSJmw@mail.gmail.com>
	<CALt0+o8mbp3BX0_Pa5q9vfYO9VC_TWuEkPS+xmtRJ0wfJm-JPA@mail.gmail.com>
Message-ID: <CAFdSV9sp=NS_9adGUoLTkRtoJGRJxuOH7PE5xogVNvJ9Kghifg@mail.gmail.com>

On Fri, Feb 2, 2018 at 8:36 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> On Fri, Feb 2, 2018 at 3:06 PM, Yoann Rodiere <yoann at hibernate.org> wrote:
>
>> @Guillaume, all: I also changed the links of other projects to point to
>> Maven Central instead of the JBoss Nexus, because the JBoss Nexus requires
>> authentication. And, well, also because... Nexus.
>>
>
> Frankly, I find the new Maven Central links (we used JBoss Nexus before
> that) you created far more useful than the Bintray page.
>
> Compare:
>
> https://search.maven.org/#search%7Cga%7C1%7Cg%3Aorg.hibernate.validator%20AND%20a%3Ahibernate-validator%2A%20AND%20v%3A6.0.7.Final
> with
> https://bintray.com/hibernate//artifacts/hibernate-orm/5.3.0.Beta2#
>
>
See you cheated though.  You "just happened" to use a project that has a
dedicated groupId.  If we used a dedicated groupId for ORM
(`org.hibernate.orm` e.g.) then its not a big deal either way.

Craft the same search for ORM and compare (1) the display and (2) the
complexity needed to build the search.

If you don't like the release/version-specific view Bintray offers then
fine - that's your point of view.  I just happen to completely disagree.



One goes straight to the point and for the other, it's not that obvious.
>
> And this page is very nice too:
> https://search.maven.org/#artifactdetails%7Corg.hibernate.validator%7Chibernate-validator-relocation%7C6.0.7.Final%7Cpom
>
> On Bintray, the first artifact presented is agroal which is a bit weird
> (yeah I know, alphabetical order but we do better on our pages).
>
> If it were me I would vote for having this layout
> http://staging.hibernate.org/validator/releases/6.0/ + the link to
> search.maven.org for all the projects. I don't think the Bintray page is
> better than what you did with search.maven.org.
>
> By the way, Bintray should test its UI with Firefox too, it's full of
> annoying usability bugs (I experienced 2 just by checking the ORM page)...
>

Bintray is in fact in the middle of a UI/UX rewrite, so...

And selecting the "main" artifact used in the drop down is one of those
items

From yoann at hibernate.org  Fri Feb  2 10:10:25 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Fri, 02 Feb 2018 15:10:25 +0000
Subject: [hibernate-dev] hibernate.org ORM release series page
In-Reply-To: <CAFdSV9sp=NS_9adGUoLTkRtoJGRJxuOH7PE5xogVNvJ9Kghifg@mail.gmail.com>
References: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>
	<CAEqagpp=S_wmVx7HjtqH1Mwk51fxYyGMmCD+dbKqkthHMC_dwQ@mail.gmail.com>
	<CAFdSV9s4NfNdj5uzNg0U0=TuHFiHriS45NcPe51VamfAH8xbOw@mail.gmail.com>
	<CALt0+o_Ft2=CHfdXox0_47uJFSHV3NghzQoqc+BLF8xGtE-CyA@mail.gmail.com>
	<CAEqagprHd3iuMh2FyhKJUW1SEUhLwyKMrenOr4-34_nBeZSJmw@mail.gmail.com>
	<CALt0+o8mbp3BX0_Pa5q9vfYO9VC_TWuEkPS+xmtRJ0wfJm-JPA@mail.gmail.com>
	<CAFdSV9sp=NS_9adGUoLTkRtoJGRJxuOH7PE5xogVNvJ9Kghifg@mail.gmail.com>
Message-ID: <CAEqagpq_MC+WvcVY_Zd3Vz3rh6=K4YoNdJMNK93fKox+TBgBqA@mail.gmail.com>

So... It's a yes for the current state of staging (with Bintray links)?

On Fri, 2 Feb 2018 at 16:07 Steve Ebersole <steve at hibernate.org> wrote:

> On Fri, Feb 2, 2018 at 8:36 AM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> On Fri, Feb 2, 2018 at 3:06 PM, Yoann Rodiere <yoann at hibernate.org>
>> wrote:
>>
>>> @Guillaume, all: I also changed the links of other projects to point to
>>> Maven Central instead of the JBoss Nexus, because the JBoss Nexus requires
>>> authentication. And, well, also because... Nexus.
>>>
>>
>> Frankly, I find the new Maven Central links (we used JBoss Nexus before
>> that) you created far more useful than the Bintray page.
>>
>> Compare:
>>
>> https://search.maven.org/#search%7Cga%7C1%7Cg%3Aorg.hibernate.validator%20AND%20a%3Ahibernate-validator%2A%20AND%20v%3A6.0.7.Final
>> with
>> https://bintray.com/hibernate//artifacts/hibernate-orm/5.3.0.Beta2#
>>
>>
> See you cheated though.  You "just happened" to use a project that has a
> dedicated groupId.  If we used a dedicated groupId for ORM
> (`org.hibernate.orm` e.g.) then its not a big deal either way.
>
> Craft the same search for ORM and compare (1) the display and (2) the
> complexity needed to build the search.
>
> If you don't like the release/version-specific view Bintray offers then
> fine - that's your point of view.  I just happen to completely disagree.
>
>
>
> One goes straight to the point and for the other, it's not that obvious.
>>
>> And this page is very nice too:
>> https://search.maven.org/#artifactdetails%7Corg.hibernate.validator%7Chibernate-validator-relocation%7C6.0.7.Final%7Cpom
>>
>> On Bintray, the first artifact presented is agroal which is a bit weird
>> (yeah I know, alphabetical order but we do better on our pages).
>>
>> If it were me I would vote for having this layout
>> http://staging.hibernate.org/validator/releases/6.0/ + the link to
>> search.maven.org for all the projects. I don't think the Bintray page is
>> better than what you did with search.maven.org.
>>
>> By the way, Bintray should test its UI with Firefox too, it's full of
>> annoying usability bugs (I experienced 2 just by checking the ORM page)...
>>
>
> Bintray is in fact in the middle of a UI/UX rewrite, so...
>
> And selecting the "main" artifact used in the drop down is one of those
> items
>
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From steve at hibernate.org  Fri Feb  2 10:15:49 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 02 Feb 2018 15:15:49 +0000
Subject: [hibernate-dev] hibernate.org ORM release series page
In-Reply-To: <CAEqagprHd3iuMh2FyhKJUW1SEUhLwyKMrenOr4-34_nBeZSJmw@mail.gmail.com>
References: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>
	<CAEqagpp=S_wmVx7HjtqH1Mwk51fxYyGMmCD+dbKqkthHMC_dwQ@mail.gmail.com>
	<CAFdSV9s4NfNdj5uzNg0U0=TuHFiHriS45NcPe51VamfAH8xbOw@mail.gmail.com>
	<CALt0+o_Ft2=CHfdXox0_47uJFSHV3NghzQoqc+BLF8xGtE-CyA@mail.gmail.com>
	<CAEqagprHd3iuMh2FyhKJUW1SEUhLwyKMrenOr4-34_nBeZSJmw@mail.gmail.com>
Message-ID: <CAFdSV9ufuScuiwuFcYzhA5rRg=1CtsTGPZF8TyUhCwi5O_vMvQ@mail.gmail.com>

There is one thing that should change though - that initial Bintray link
really ought to go to the Bintray hibernate-orm package.  We already have
the version-specific Bintray links below.

Thanks for working on this.  Should I make those changes on top of yours?

On Fri, Feb 2, 2018 at 8:06 AM Yoann Rodiere <yoann at hibernate.org> wrote:

> > IIUC, a "switch based on the project" is not going to be enough.  For
> the orm project we'd also then need to know whether a series is "5.3 or
> later":
>
> It's even worse, as 5.3.0.Beta1 is on the JBoss Nexus but Beta2 is on
> Bintray,,,
>
> Anyway, I managed to get something. It's on staging, please give some
> feedback - preferably "it's wonderful, let's keep it that way" or "nice,
> but I'll make some changes, please merge" ;)
>
>    - http://staging.hibernate.org/orm/releases/5.3/
>    - http://staging.hibernate.org/search/releases/5.9/
>    - http://staging.hibernate.org/validator/releases/6.0/
>    - http://staging.hibernate.org/validator/releases/5.4/
>    - http://staging.hibernate.org/ogm/releases/5.2/
>
> @Guillaume, all: I also changed the links of other projects to point to
> Maven Central instead of the JBoss Nexus, because the JBoss Nexus requires
> authentication. And, well, also because... Nexus.
>
> On Fri, 2 Feb 2018 at 14:44 Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> On Fri, Feb 2, 2018 at 2:19 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> I'm not sure how to do that `series >= 5.3` piece.  I guess I'll look at
>>> what you do on staging
>>
>>
>> What I have done so far to manage this sort of things is to add metadata
>> to the series files.
>>
>> --
>> Guillaume
>>
> --
> Yoann Rodiere
> yoann at hibernate.org / yrodiere at redhat.com
> Software Engineer
> Hibernate NoORM team
>

From guillaume.smet at gmail.com  Fri Feb  2 10:22:21 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 2 Feb 2018 16:22:21 +0100
Subject: [hibernate-dev] hibernate.org ORM release series page
In-Reply-To: <CAFdSV9sp=NS_9adGUoLTkRtoJGRJxuOH7PE5xogVNvJ9Kghifg@mail.gmail.com>
References: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>
	<CAEqagpp=S_wmVx7HjtqH1Mwk51fxYyGMmCD+dbKqkthHMC_dwQ@mail.gmail.com>
	<CAFdSV9s4NfNdj5uzNg0U0=TuHFiHriS45NcPe51VamfAH8xbOw@mail.gmail.com>
	<CALt0+o_Ft2=CHfdXox0_47uJFSHV3NghzQoqc+BLF8xGtE-CyA@mail.gmail.com>
	<CAEqagprHd3iuMh2FyhKJUW1SEUhLwyKMrenOr4-34_nBeZSJmw@mail.gmail.com>
	<CALt0+o8mbp3BX0_Pa5q9vfYO9VC_TWuEkPS+xmtRJ0wfJm-JPA@mail.gmail.com>
	<CAFdSV9sp=NS_9adGUoLTkRtoJGRJxuOH7PE5xogVNvJ9Kghifg@mail.gmail.com>
Message-ID: <CALt0+o9Vyu2nkuxgf8k3UFG9Sh3VdBL=t3kJrjfV-0t3ok6img@mail.gmail.com>

On Fri, Feb 2, 2018 at 4:00 PM, Steve Ebersole <steve at hibernate.org> wrote:

> See you cheated though.  You "just happened" to use a project that has a
> dedicated groupId.  If we used a dedicated groupId for ORM
> (`org.hibernate.orm` e.g.) then its not a big deal either way.
>

I didn't cheat. I gave a random link. Yoann made it work for the old
Validator releases which use the shared org.hibernate groupId:
http://staging.hibernate.org/validator/releases/5.4/


> Craft the same search for ORM and compare (1) the display and (2) the
> complexity needed to build the search.
>
> If you don't like the release/version-specific view Bintray offers then
> fine - that's your point of view.  I just happen to completely disagree.
>

Yeah, well, all the not so interesting/general information are taking all
the screen and you have to scroll to see the artifact you were looking for
at the bottom of the page.

Add to that a bug with Firefox that makes you go to the top of the page
everytime you click on the artifact dropdown. (Maybe you can ping them
about it if you have contacts there)

Yeah, sorry, I'm not impressed.

Bintray is in fact in the middle of a UI/UX rewrite, so...
>
> And selecting the "main" artifact used in the drop down is one of those
> items
>

OK, let's hope it's going to be better then.

@Yoann so +1 from me for the new behavior of the NoORM projects, it works
great.

-- 
Guillaume

From yoann at hibernate.org  Fri Feb  2 10:24:11 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Fri, 02 Feb 2018 15:24:11 +0000
Subject: [hibernate-dev] hibernate.org ORM release series page
In-Reply-To: <CALt0+o9Vyu2nkuxgf8k3UFG9Sh3VdBL=t3kJrjfV-0t3ok6img@mail.gmail.com>
References: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>
	<CAEqagpp=S_wmVx7HjtqH1Mwk51fxYyGMmCD+dbKqkthHMC_dwQ@mail.gmail.com>
	<CAFdSV9s4NfNdj5uzNg0U0=TuHFiHriS45NcPe51VamfAH8xbOw@mail.gmail.com>
	<CALt0+o_Ft2=CHfdXox0_47uJFSHV3NghzQoqc+BLF8xGtE-CyA@mail.gmail.com>
	<CAEqagprHd3iuMh2FyhKJUW1SEUhLwyKMrenOr4-34_nBeZSJmw@mail.gmail.com>
	<CALt0+o8mbp3BX0_Pa5q9vfYO9VC_TWuEkPS+xmtRJ0wfJm-JPA@mail.gmail.com>
	<CAFdSV9sp=NS_9adGUoLTkRtoJGRJxuOH7PE5xogVNvJ9Kghifg@mail.gmail.com>
	<CALt0+o9Vyu2nkuxgf8k3UFG9Sh3VdBL=t3kJrjfV-0t3ok6img@mail.gmail.com>
Message-ID: <CAEqagpras-9b+53Gdzdid71_Kqngrzmg3EZHwVbhHtvnVj-WBw@mail.gmail.com>

> Should I make those changes on top of yours?

I will do it and merge.

Thanks all for the feedback.

On Fri, 2 Feb 2018 at 16:23 Guillaume Smet <guillaume.smet at gmail.com> wrote:

> On Fri, Feb 2, 2018 at 4:00 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> See you cheated though.  You "just happened" to use a project that has a
>> dedicated groupId.  If we used a dedicated groupId for ORM
>> (`org.hibernate.orm` e.g.) then its not a big deal either way.
>>
>
> I didn't cheat. I gave a random link. Yoann made it work for the old
> Validator releases which use the shared org.hibernate groupId:
> http://staging.hibernate.org/validator/releases/5.4/
>
>
>> Craft the same search for ORM and compare (1) the display and (2) the
>> complexity needed to build the search.
>>
>> If you don't like the release/version-specific view Bintray offers then
>> fine - that's your point of view.  I just happen to completely disagree.
>>
>
> Yeah, well, all the not so interesting/general information are taking all
> the screen and you have to scroll to see the artifact you were looking for
> at the bottom of the page.
>
> Add to that a bug with Firefox that makes you go to the top of the page
> everytime you click on the artifact dropdown. (Maybe you can ping them
> about it if you have contacts there)
>
> Yeah, sorry, I'm not impressed.
>
> Bintray is in fact in the middle of a UI/UX rewrite, so...
>>
>> And selecting the "main" artifact used in the drop down is one of those
>> items
>>
>
> OK, let's hope it's going to be better then.
>
> @Yoann so +1 from me for the new behavior of the NoORM projects, it works
> great.
>
> --
> Guillaume
>
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From steve at hibernate.org  Fri Feb  2 10:27:08 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 02 Feb 2018 15:27:08 +0000
Subject: [hibernate-dev] hibernate.org ORM release series page
In-Reply-To: <CALt0+o9Vyu2nkuxgf8k3UFG9Sh3VdBL=t3kJrjfV-0t3ok6img@mail.gmail.com>
References: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>
	<CAEqagpp=S_wmVx7HjtqH1Mwk51fxYyGMmCD+dbKqkthHMC_dwQ@mail.gmail.com>
	<CAFdSV9s4NfNdj5uzNg0U0=TuHFiHriS45NcPe51VamfAH8xbOw@mail.gmail.com>
	<CALt0+o_Ft2=CHfdXox0_47uJFSHV3NghzQoqc+BLF8xGtE-CyA@mail.gmail.com>
	<CAEqagprHd3iuMh2FyhKJUW1SEUhLwyKMrenOr4-34_nBeZSJmw@mail.gmail.com>
	<CALt0+o8mbp3BX0_Pa5q9vfYO9VC_TWuEkPS+xmtRJ0wfJm-JPA@mail.gmail.com>
	<CAFdSV9sp=NS_9adGUoLTkRtoJGRJxuOH7PE5xogVNvJ9Kghifg@mail.gmail.com>
	<CALt0+o9Vyu2nkuxgf8k3UFG9Sh3VdBL=t3kJrjfV-0t3ok6img@mail.gmail.com>
Message-ID: <CAFdSV9vSmffw3ffuwRghqWi+jOE60G5LG1Q8NTGWgCSq_5DGUw@mail.gmail.com>

>
> Yeah, sorry, I'm not impressed.
>

Pretty sure you are still more impressed with it than I am with Nexus ;)


Bintray is in fact in the middle of a UI/UX rewrite, so...
>>
>> And selecting the "main" artifact used in the drop down is one of those
>> items
>>
>
> OK, let's hope it's going to be better then.
>

Of course you reported the problem right?  So, you know, it "gets better"...

From guillaume.smet at gmail.com  Fri Feb  2 10:43:51 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 2 Feb 2018 16:43:51 +0100
Subject: [hibernate-dev] hibernate.org ORM release series page
In-Reply-To: <CAFdSV9vSmffw3ffuwRghqWi+jOE60G5LG1Q8NTGWgCSq_5DGUw@mail.gmail.com>
References: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>
	<CAEqagpp=S_wmVx7HjtqH1Mwk51fxYyGMmCD+dbKqkthHMC_dwQ@mail.gmail.com>
	<CAFdSV9s4NfNdj5uzNg0U0=TuHFiHriS45NcPe51VamfAH8xbOw@mail.gmail.com>
	<CALt0+o_Ft2=CHfdXox0_47uJFSHV3NghzQoqc+BLF8xGtE-CyA@mail.gmail.com>
	<CAEqagprHd3iuMh2FyhKJUW1SEUhLwyKMrenOr4-34_nBeZSJmw@mail.gmail.com>
	<CALt0+o8mbp3BX0_Pa5q9vfYO9VC_TWuEkPS+xmtRJ0wfJm-JPA@mail.gmail.com>
	<CAFdSV9sp=NS_9adGUoLTkRtoJGRJxuOH7PE5xogVNvJ9Kghifg@mail.gmail.com>
	<CALt0+o9Vyu2nkuxgf8k3UFG9Sh3VdBL=t3kJrjfV-0t3ok6img@mail.gmail.com>
	<CAFdSV9vSmffw3ffuwRghqWi+jOE60G5LG1Q8NTGWgCSq_5DGUw@mail.gmail.com>
Message-ID: <CALt0+o__pjyzh-_Yo37uWHczCBJ8TJNQaqvwK4L3grK6KKC8xg@mail.gmail.com>

On Fri, Feb 2, 2018 at 4:27 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Pretty sure you are still more impressed with it than I am with Nexus ;)
>

That's the message I wanted to convey: we don't use the Nexus UI anymore
with the changes made by Yoann.

And that doesn't prevent you from using Bintray for publishing. Just that
we would link to Central instead of Bintray in the website.

But it's your project so do whatever you want. I just wanted to point out
the other improvements made by Yoann, which, IMHO, make the NoORM
experience better than the ORM one with Bintray now. But as mentioned it's
just MHO.

Of course you reported the problem right?  So, you know, it "gets better"...
>

Yeah, one thing really great is that there is a big Feedback button :).

-- 
Guillaume

From yoann at hibernate.org  Fri Feb  2 11:02:26 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Fri, 02 Feb 2018 16:02:26 +0000
Subject: [hibernate-dev] hibernate.org ORM release series page
In-Reply-To: <CALt0+o__pjyzh-_Yo37uWHczCBJ8TJNQaqvwK4L3grK6KKC8xg@mail.gmail.com>
References: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>
	<CAEqagpp=S_wmVx7HjtqH1Mwk51fxYyGMmCD+dbKqkthHMC_dwQ@mail.gmail.com>
	<CAFdSV9s4NfNdj5uzNg0U0=TuHFiHriS45NcPe51VamfAH8xbOw@mail.gmail.com>
	<CALt0+o_Ft2=CHfdXox0_47uJFSHV3NghzQoqc+BLF8xGtE-CyA@mail.gmail.com>
	<CAEqagprHd3iuMh2FyhKJUW1SEUhLwyKMrenOr4-34_nBeZSJmw@mail.gmail.com>
	<CALt0+o8mbp3BX0_Pa5q9vfYO9VC_TWuEkPS+xmtRJ0wfJm-JPA@mail.gmail.com>
	<CAFdSV9sp=NS_9adGUoLTkRtoJGRJxuOH7PE5xogVNvJ9Kghifg@mail.gmail.com>
	<CALt0+o9Vyu2nkuxgf8k3UFG9Sh3VdBL=t3kJrjfV-0t3ok6img@mail.gmail.com>
	<CAFdSV9vSmffw3ffuwRghqWi+jOE60G5LG1Q8NTGWgCSq_5DGUw@mail.gmail.com>
	<CALt0+o__pjyzh-_Yo37uWHczCBJ8TJNQaqvwK4L3grK6KKC8xg@mail.gmail.com>
Message-ID: <CAEqagpq-Zp8Yw3428VAeixAmdxj0J0rWrkFhfmMVaDNKdLaqBA@mail.gmail.com>

Merged to production. Steve, you can add 5.3.0.Beta2 the usual way,
whenever you're ready.

On Fri, 2 Feb 2018 at 16:44 Guillaume Smet <guillaume.smet at gmail.com> wrote:

> On Fri, Feb 2, 2018 at 4:27 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Pretty sure you are still more impressed with it than I am with Nexus ;)
>>
>
> That's the message I wanted to convey: we don't use the Nexus UI anymore
> with the changes made by Yoann.
>
> And that doesn't prevent you from using Bintray for publishing. Just that
> we would link to Central instead of Bintray in the website.
>
> But it's your project so do whatever you want. I just wanted to point out
> the other improvements made by Yoann, which, IMHO, make the NoORM
> experience better than the ORM one with Bintray now. But as mentioned it's
> just MHO.
>
> Of course you reported the problem right?  So, you know, it "gets
>> better"...
>>
>
> Yeah, one thing really great is that there is a big Feedback button :).
>
> --
> Guillaume
>
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From guillaume.smet at gmail.com  Fri Feb  2 11:13:51 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 2 Feb 2018 17:13:51 +0100
Subject: [hibernate-dev] hibernate.org ORM release series page
In-Reply-To: <CALt0+o9Vyu2nkuxgf8k3UFG9Sh3VdBL=t3kJrjfV-0t3ok6img@mail.gmail.com>
References: <CAFdSV9tqrS-PyyLyUoV-Rs-7rL9p540KfR31mu6gmw+rTFQwnQ@mail.gmail.com>
	<CAEqagpp=S_wmVx7HjtqH1Mwk51fxYyGMmCD+dbKqkthHMC_dwQ@mail.gmail.com>
	<CAFdSV9s4NfNdj5uzNg0U0=TuHFiHriS45NcPe51VamfAH8xbOw@mail.gmail.com>
	<CALt0+o_Ft2=CHfdXox0_47uJFSHV3NghzQoqc+BLF8xGtE-CyA@mail.gmail.com>
	<CAEqagprHd3iuMh2FyhKJUW1SEUhLwyKMrenOr4-34_nBeZSJmw@mail.gmail.com>
	<CALt0+o8mbp3BX0_Pa5q9vfYO9VC_TWuEkPS+xmtRJ0wfJm-JPA@mail.gmail.com>
	<CAFdSV9sp=NS_9adGUoLTkRtoJGRJxuOH7PE5xogVNvJ9Kghifg@mail.gmail.com>
	<CALt0+o9Vyu2nkuxgf8k3UFG9Sh3VdBL=t3kJrjfV-0t3ok6img@mail.gmail.com>
Message-ID: <CALt0+o9FR5NFsPN0Yy_RDgaYuVzzkegzLszjPBx6N-EqhrS5YA@mail.gmail.com>

On Fri, Feb 2, 2018 at 4:22 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> On Fri, Feb 2, 2018 at 4:00 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> See you cheated though.  You "just happened" to use a project that has a
>> dedicated groupId.  If we used a dedicated groupId for ORM
>> (`org.hibernate.orm` e.g.) then its not a big deal either way.
>>
>
> I didn't cheat. I gave a random link. Yoann made it work for the old
> Validator releases which use the shared org.hibernate groupId:
> http://staging.hibernate.org/validator/releases/5.4/
>

Just for the record, the ORM case is a bit more complicated as the
artifacts don't start with hibernate-orm.

It can easily be worked around though by filtering out the other artifacts
as in this example:
https://search.maven.org/#search|ga|1|g%3Aorg.hibernate%20AND%20a%3Ahibernate-*%20AND%20NOT%20a%3Ahibernate-validator*%20AND%20NOT%20a%3Ahibernate-search*%20AND%20v%3A5.3.0.Beta1

(just wanted to log this in case we need this later)

-- 
Guillaume

From lalmeras at gmail.com  Fri Feb  2 12:00:54 2018
From: lalmeras at gmail.com (Laurent Almeras)
Date: Fri, 2 Feb 2018 18:00:54 +0100
Subject: [hibernate-dev] Some insight about HHH-12101 / remove HQL-style
	positional parameters
Message-ID: <45104e7b-6032-db91-14dd-7ba0f6405641@gmail.com>

Hi,

Testing Hibernate 9.3.0.Beta2, I run into this issue:


===============
  Cannot define positional and named parameterSpecs : select 
queuedTaskHolder
from org.iglooproject.jpa.more.business.task.model.QueuedTaskHolder 
queuedTaskHolder
where queuedTaskHolder.status in (:x1_0, :x1_1, :x1_2, :x1_3) and 
queuedTaskHolder.queueId = ?2
===============


Hibernate complains that query contains both named and positional 
parameters (note that this query use to work on Hibernate 5.2.x).

This new behavior is linked to:

* this commit: 
https://github.com/hibernate/hibernate-orm/commit/5e0274adbbd3e0aa3092c29a765fd203c8279126
* this issue: https://hibernate.atlassian.net/browse/HHH-12116
* and this parent issue: https://hibernate.atlassian.net/browse/HHH-12101

I also find that you already talk about this behavior on this same 
mailing-list: 
http://lists.jboss.org/pipermail/hibernate-dev/2016-September/015460.html


I think that allowing this behavior was not a good idea, so I don't have 
any hope that you consider this as a bug. But I think it should be 
noticed in the release note 
(http://in.relation.to/2018/01/18/hibernate-orm-530-beta1-release/) or 
in this ticket (https://hibernate.atlassian.net/browse/HHH-12101) as a 
side-effect.


On my side, I run in this issue because I use QueryDSL-jpa, and the 
query I give as an example is buggy because it mixes a IN statement 
(named parameter) dans an EQUAL statement (positional parameter).

Is there anyone following both Hibernate and QueryDSL here that is 
already aware or working on this issue ?


Thanks

Laurent Almeras


From lalmeras at gmail.com  Fri Feb  2 16:36:41 2018
From: lalmeras at gmail.com (Laurent Almeras)
Date: Fri, 2 Feb 2018 22:36:41 +0100
Subject: [hibernate-dev] Some insight about HHH-12101 / remove HQL-style
 positional parameters
In-Reply-To: <45104e7b-6032-db91-14dd-7ba0f6405641@gmail.com>
References: <45104e7b-6032-db91-14dd-7ba0f6405641@gmail.com>
Message-ID: <cbdb45f7-8ebf-0c90-9d43-3c6dc9ebec6d@gmail.com>

Hi,

After digging further, it seems to me that there is a bug with Hibernate 
5.3.

I debug and step through the query handling, and the generated QueryDSL 
query seems correct to me:

=========================
select queuedTaskHolder
from QueuedTaskHolder queuedTaskHolder
where queuedTaskHolder.status in (?1) and queuedTaskHolder.queueId = ?2
order by queuedTaskHolder.id asc
=========================

The (:x1_0, :x1_1, :x1_2, :x1_3) part appears in the hibernate query 
handling inside layers, in 
org.hibernate.query.internal.QueryParameterBindingsImpl.expandListValuedParameters(String, 
SharedSessionContractImplementor) method. It seems that the purpose of 
this method is to transform query and parameters arguments when argument 
is a list. So query is rewritten with named parameters, and query 
parameters are modified to inject this new parameters.

And this query is then rejected in 
org.hibernate.hql.internal.ast.HqlSqlWalker.generatePositionalParameter(AST, 
AST) because there are namedParameters.

If I switch dependency to 5.2.12.Final release, the same code works.

I'll try to write a minimal test-case about this when I'll get some 
spare time.

-- 
Laurent Almeras

On 02/02/2018 06:00 PM, Laurent Almeras wrote:
> Hi,
> 
> Testing Hibernate 9.3.0.Beta2, I run into this issue:
> 
> 
> ===============
>  ?Cannot define positional and named parameterSpecs : select 
> queuedTaskHolder
> from org.iglooproject.jpa.more.business.task.model.QueuedTaskHolder 
> queuedTaskHolder
> where queuedTaskHolder.status in (:x1_0, :x1_1, :x1_2, :x1_3) and 
> queuedTaskHolder.queueId = ?2
> ===============
> 
> 
> Hibernate complains that query contains both named and positional 
> parameters (note that this query use to work on Hibernate 5.2.x).
> 
> This new behavior is linked to:
> 
> * this commit: 
> https://github.com/hibernate/hibernate-orm/commit/5e0274adbbd3e0aa3092c29a765fd203c8279126 
> 
> * this issue: https://hibernate.atlassian.net/browse/HHH-12116
> * and this parent issue: https://hibernate.atlassian.net/browse/HHH-12101
> 
> I also find that you already talk about this behavior on this same 
> mailing-list: 
> http://lists.jboss.org/pipermail/hibernate-dev/2016-September/015460.html
> 
> 
> I think that allowing this behavior was not a good idea, so I don't have 
> any hope that you consider this as a bug. But I think it should be 
> noticed in the release note 
> (http://in.relation.to/2018/01/18/hibernate-orm-530-beta1-release/) or 
> in this ticket (https://hibernate.atlassian.net/browse/HHH-12101) as a 
> side-effect.
> 
> 
> On my side, I run in this issue because I use QueryDSL-jpa, and the 
> query I give as an example is buggy because it mixes a IN statement 
> (named parameter) dans an EQUAL statement (positional parameter).
> 
> Is there anyone following both Hibernate and QueryDSL here that is 
> already aware or working on this issue ?
> 
> 
> Thanks
> 
> Laurent Almeras
> 

From mihalcea.vlad at gmail.com  Sat Feb  3 10:03:20 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sat, 3 Feb 2018 17:03:20 +0200
Subject: [hibernate-dev] Support for entities without default constructor
In-Reply-To: <CA+gWKMCa_ueX_H+2sYpUzrXHkhTyRmSMJh9dfKNQXa_BxU4NzQ@mail.gmail.com>
References: <CA+gWKMBJem2FC+gz_jb42U4tgZ9fmdo2MZ+OMKsbKVQGaMiUoQ@mail.gmail.com>
	<CA+gWKMA7V_-KfrX3+fwxW+f3XVFdUyCxZ6FMa-g0WTrpiqK4GA@mail.gmail.com>
	<CA+gWKMALE8gpv2RsqoCWTXscDiEt0Tg4uKJt1iifi6Q2qydN=A@mail.gmail.com>
	<CA+gWKMC4Tn-URiaBYhK8Tk-EtgC9_UAO=HPHU7_y6pA94Yd37w@mail.gmail.com>
	<CA+gWKMAtx-NdE4x3yZA8bsyNkUdpJmn+7kxvqnFO3h5oQgXhwA@mail.gmail.com>
	<CA+gWKMAfhVGEWsavGtEr8xi_a74tfDN8D8Uwmk8ofgrLE25_cw@mail.gmail.com>
	<CA+gWKMA+fYVcUXvOcT97KzDz1PudcfSt5Vq1RnJr_NC1JkaHbQ@mail.gmail.com>
	<CA+gWKMCa_ueX_H+2sYpUzrXHkhTyRmSMJh9dfKNQXa_BxU4NzQ@mail.gmail.com>
Message-ID: <CA+gWKMCiHub+bS4TGweU0w0co-Ye9CRKqfeSJs3RZJwe-_Mfug@mail.gmail.com>

Hi,

I realized that we could allow users to define entities without a default
constructor.

For Kotlin, which supportsdefault values, this could be beneficial.

There is some info about how we could do that in this using Objenesis in
the following Spring issue:

https://jira.spring.io/plugins/servlet/mobile#issue/SPR-10594

Let me know what you think,
Vlad

From mihalcea.vlad at gmail.com  Sun Feb  4 02:34:10 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sun, 4 Feb 2018 09:34:10 +0200
Subject: [hibernate-dev] Support for entities without default constructor
In-Reply-To: <CA+gWKMCiHub+bS4TGweU0w0co-Ye9CRKqfeSJs3RZJwe-_Mfug@mail.gmail.com>
References: <CA+gWKMBJem2FC+gz_jb42U4tgZ9fmdo2MZ+OMKsbKVQGaMiUoQ@mail.gmail.com>
	<CA+gWKMA7V_-KfrX3+fwxW+f3XVFdUyCxZ6FMa-g0WTrpiqK4GA@mail.gmail.com>
	<CA+gWKMALE8gpv2RsqoCWTXscDiEt0Tg4uKJt1iifi6Q2qydN=A@mail.gmail.com>
	<CA+gWKMC4Tn-URiaBYhK8Tk-EtgC9_UAO=HPHU7_y6pA94Yd37w@mail.gmail.com>
	<CA+gWKMAtx-NdE4x3yZA8bsyNkUdpJmn+7kxvqnFO3h5oQgXhwA@mail.gmail.com>
	<CA+gWKMAfhVGEWsavGtEr8xi_a74tfDN8D8Uwmk8ofgrLE25_cw@mail.gmail.com>
	<CA+gWKMA+fYVcUXvOcT97KzDz1PudcfSt5Vq1RnJr_NC1JkaHbQ@mail.gmail.com>
	<CA+gWKMCa_ueX_H+2sYpUzrXHkhTyRmSMJh9dfKNQXa_BxU4NzQ@mail.gmail.com>
	<CA+gWKMCiHub+bS4TGweU0w0co-Ye9CRKqfeSJs3RZJwe-_Mfug@mail.gmail.com>
Message-ID: <CA+gWKMDpfYE9CyVdB=Q9===pDKuhf7zkKQfymzySy--s=kftxw@mail.gmail.com>

For anyone interested, Josh Long tell more about why they took this
approach where they inject the default constructor:

https://twitter.com/starbuxman/status/960049941916696578

Rafael Winterhaler shows that this can be easily done with Byte Buddy which
we already used before:

https://twitter.com/rafaelcodes/status/959892398997458946

If we can prove that it's indeed significantly faster than using Java
Reflection to build entities,
I think we should think about taking this approach as well.

What do you think of this?

Vlad

On Sat, Feb 3, 2018 at 5:03 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> I realized that we could allow users to define entities without a default
> constructor.
>
> For Kotlin, which supportsdefault values, this could be beneficial.
>
> There is some info about how we could do that in this using Objenesis in
> the following Spring issue:
>
> https://jira.spring.io/plugins/servlet/mobile#issue/SPR-10594
>
> Let me know what you think,
> Vlad
>

From gunnar at hibernate.org  Sun Feb  4 06:30:53 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sun, 4 Feb 2018 12:30:53 +0100
Subject: [hibernate-dev] Support for entities without default constructor
In-Reply-To: <CA+gWKMDpfYE9CyVdB=Q9===pDKuhf7zkKQfymzySy--s=kftxw@mail.gmail.com>
References: <CA+gWKMBJem2FC+gz_jb42U4tgZ9fmdo2MZ+OMKsbKVQGaMiUoQ@mail.gmail.com>
	<CA+gWKMA7V_-KfrX3+fwxW+f3XVFdUyCxZ6FMa-g0WTrpiqK4GA@mail.gmail.com>
	<CA+gWKMALE8gpv2RsqoCWTXscDiEt0Tg4uKJt1iifi6Q2qydN=A@mail.gmail.com>
	<CA+gWKMC4Tn-URiaBYhK8Tk-EtgC9_UAO=HPHU7_y6pA94Yd37w@mail.gmail.com>
	<CA+gWKMAtx-NdE4x3yZA8bsyNkUdpJmn+7kxvqnFO3h5oQgXhwA@mail.gmail.com>
	<CA+gWKMAfhVGEWsavGtEr8xi_a74tfDN8D8Uwmk8ofgrLE25_cw@mail.gmail.com>
	<CA+gWKMA+fYVcUXvOcT97KzDz1PudcfSt5Vq1RnJr_NC1JkaHbQ@mail.gmail.com>
	<CA+gWKMCa_ueX_H+2sYpUzrXHkhTyRmSMJh9dfKNQXa_BxU4NzQ@mail.gmail.com>
	<CA+gWKMCiHub+bS4TGweU0w0co-Ye9CRKqfeSJs3RZJwe-_Mfug@mail.gmail.com>
	<CA+gWKMDpfYE9CyVdB=Q9===pDKuhf7zkKQfymzySy--s=kftxw@mail.gmail.com>
Message-ID: <CADGJaX-L6+z1_p9fsUdxbhVqFS1CVv+bvzrZtRPk1eBrOvLCHA@mail.gmail.com>

I like it, but I think that's two separate concerns:

* using byte code generation to improve performance of entity instantiations
* avoiding the need for entities to have a parameterless constructor,
emphasising the mandatory properties of an entity (by requiring them as
constructor parameters) and allowing read-only entities to be truly
immutable (i.e. with final fields)

Both can be addressed independently.

The latter seems more impactful for developer experience, the need for a
default constructor has been a long-standing point of criticism often
raised by DDD-minded folks. As said on Twitter, it'll likely require an
annotation to mark the "persistence constructor", i.e. the one to be called
by Hibernate in case there are multiple ones. And we need a mapping between
parameter names and entity property names. That's "for free" if parameter
names are part of the byte code as possible with the "-parameters" option
in javac 8, otherwise some help by the developer is needed.

The avoidance of reflective constructor invocation via byte code generation
should be rather simple using ByteBuddy.

--Gunnar

2018-02-04 8:34 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:

> For anyone interested, Josh Long tell more about why they took this
> approach where they inject the default constructor:
>
> https://twitter.com/starbuxman/status/960049941916696578
>
> Rafael Winterhaler shows that this can be easily done with Byte Buddy which
> we already used before:
>
> https://twitter.com/rafaelcodes/status/959892398997458946
>
> If we can prove that it's indeed significantly faster than using Java
> Reflection to build entities,
> I think we should think about taking this approach as well.
>
> What do you think of this?
>
> Vlad
>
> On Sat, Feb 3, 2018 at 5:03 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
> > Hi,
> >
> > I realized that we could allow users to define entities without a default
> > constructor.
> >
> > For Kotlin, which supportsdefault values, this could be beneficial.
> >
> > There is some info about how we could do that in this using Objenesis in
> > the following Spring issue:
> >
> > https://jira.spring.io/plugins/servlet/mobile#issue/SPR-10594
> >
> > Let me know what you think,
> > Vlad
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Sun Feb  4 07:21:21 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sun, 4 Feb 2018 13:21:21 +0100
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
	validation mode CALLBACK
Message-ID: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>

Hi,

If the JPA validation mode is set to CALLBACK, BV constraints such as
@NotNull, @Size etc. are not reflected in the DDL created by ORM.

Instead, in TypeSafeActivator, the BV constraints are only considered for
DDL if the validation mode is DDL or AUTO [1].

CALLBACK is the safe way to ensure BV is invoked by JPA (instead of
silently ignoring it if no BV provider is present), so it's the setting I
usually recommend. I think constraints should also be propagated to DDL in
this mode, so I'm wondering whether there a specific reason for the current
behaviour or wether we can change it?

Thanks,

--Gunnar

[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cfg/beanvalidation/TypeSafeActivator.java#L146

From rvansa at redhat.com  Mon Feb  5 03:53:05 2018
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 5 Feb 2018 09:53:05 +0100
Subject: [hibernate-dev] Hiberante OGM Infinispan Remote dialect -
 Execute the command queue as a single Infispan Remote Server Task
In-Reply-To: <CAFiQRE87L6HrNZc+P+so2PXhm4=n7a2dz5roTqkfneJNA97_aQ@mail.gmail.com>
References: <CAFiQRE87L6HrNZc+P+so2PXhm4=n7a2dz5roTqkfneJNA97_aQ@mail.gmail.com>
Message-ID: <06f01f6e-1e11-1e2d-a933-3094e6539f0e@redhat.com>

Hi Fabio,

thinking about the cons, Hot Rod can intelligently pick the server where 
should a given key reside, to reduce the number of hops (therefore, 
latency). RemoteCache does not expose any way to route according to some 
key; feel free to file a feature request in Infinispan JIRA.

Note that in order to reduce the number of round-trips, Infinispan 9.2 
will support true-async operations: Previously the putAsync et all just 
moved the execution to different thread, since 9.2.0.CR2 it sends the 
request to the wire right await and the response is received through a 
CompletableFuture. At this moment multiple requests will need a distinct 
TCP connection for each concurrent operation, but this limitation is 
likely to be removed in 9.3. The goal is to let you write the batch down 
one-by-one using async API and just wait for all the operations to complete.

I know this won't help for all the types of operation (a lack of 
client-side API sometimes forces OGM to use get() + CAS in a loop).

I am not trying to talk you out of the remote execution API, just 
spreading news about the emerging alternatives.

Radim

On 02/02/2018 09:24 AM, Fabio Massimo Ercoli wrote:
> I'm Fabio, nice to meet you.
>
> Speaking of the current implementation of the Infinispan remote dialect of
> Hibernate OGM, working on issue OGM-1206 and talking with Davide I noticed
> that the unit of work commands are executed (flushed to datastore) at the
> end of the transaction itself.
> In particular I noticed that the commands are stored in a transaction
> scoped object of type org.hibernate.ogm.dialect.batch.spi.OperationsQueue.
>
> Instead of perfom one remote invocation for each command in the method
>   org.hibernate.ogm.dialect.impl.BatchOperationsDelegator::executeBatch
> maybe we could invoke a proper Infispan Remote Server Task to execute the
> command queue on server side as a bulk operation.
>
> Moving the execution of the server-side command list (Infinispan) we would
> have the advantage of reducing remote interactions. Moreover and above all
> the execution of the command queue would be a transactional work unit, on
> which could be apply a Repeteable Read isolation level, for instance.
>
> The solution would not solve the need for an XA client instead, but it
> could be adopted by customers interested in local transactions.
>
> What do you think about it?
> Can I open a Jira issue?
>
> Fabio
>

-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From fercoli at redhat.com  Mon Feb  5 10:05:20 2018
From: fercoli at redhat.com (Fabio Massimo Ercoli)
Date: Mon, 5 Feb 2018 16:05:20 +0100
Subject: [hibernate-dev] Hiberante OGM Infinispan Remote dialect -
 Execute the command queue as a single Infispan Remote Server Task
In-Reply-To: <06f01f6e-1e11-1e2d-a933-3094e6539f0e@redhat.com>
References: <CAFiQRE87L6HrNZc+P+so2PXhm4=n7a2dz5roTqkfneJNA97_aQ@mail.gmail.com>
	<06f01f6e-1e11-1e2d-a933-3094e6539f0e@redhat.com>
Message-ID: <CAFiQRE_=-gBtg3tj91hn0sktQO2=NxcuFNdBWBTyLzG_q30WJg@mail.gmail.com>

Hi Radim,

thank you for the alternative, it is very interesting.
I've to study deeply the feature :P

Fabio


On Mon, Feb 5, 2018 at 9:53 AM, Radim Vansa <rvansa at redhat.com> wrote:

> Hi Fabio,
>
> thinking about the cons, Hot Rod can intelligently pick the server where
> should a given key reside, to reduce the number of hops (therefore,
> latency). RemoteCache does not expose any way to route according to some
> key; feel free to file a feature request in Infinispan JIRA.
>
> Note that in order to reduce the number of round-trips, Infinispan 9.2
> will support true-async operations: Previously the putAsync et all just
> moved the execution to different thread, since 9.2.0.CR2 it sends the
> request to the wire right await and the response is received through a
> CompletableFuture. At this moment multiple requests will need a distinct
> TCP connection for each concurrent operation, but this limitation is
> likely to be removed in 9.3. The goal is to let you write the batch down
> one-by-one using async API and just wait for all the operations to
> complete.
>
> I know this won't help for all the types of operation (a lack of
> client-side API sometimes forces OGM to use get() + CAS in a loop).
>
> I am not trying to talk you out of the remote execution API, just
> spreading news about the emerging alternatives.
>
> Radim
>
> On 02/02/2018 09:24 AM, Fabio Massimo Ercoli wrote:
> > I'm Fabio, nice to meet you.
> >
> > Speaking of the current implementation of the Infinispan remote dialect
> of
> > Hibernate OGM, working on issue OGM-1206 and talking with Davide I
> noticed
> > that the unit of work commands are executed (flushed to datastore) at the
> > end of the transaction itself.
> > In particular I noticed that the commands are stored in a transaction
> > scoped object of type org.hibernate.ogm.dialect.
> batch.spi.OperationsQueue.
> >
> > Instead of perfom one remote invocation for each command in the method
> >   org.hibernate.ogm.dialect.impl.BatchOperationsDelegator::executeBatch
> > maybe we could invoke a proper Infispan Remote Server Task to execute the
> > command queue on server side as a bulk operation.
> >
> > Moving the execution of the server-side command list (Infinispan) we
> would
> > have the advantage of reducing remote interactions. Moreover and above
> all
> > the execution of the command queue would be a transactional work unit, on
> > which could be apply a Repeteable Read isolation level, for instance.
> >
> > The solution would not solve the need for an XA client instead, but it
> > could be adopted by customers interested in local transactions.
> >
> > What do you think about it?
> > Can I open a Jira issue?
> >
> > Fabio
> >
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>



-- 

FABIO MASSIMO ERCOLI

Senior Software Engineer - Hibernate & Data Platform

Red Hat <https://www.redhat.com/>

fabio.ercoli at redhat.com    M: (+39)-329.8681441
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>

From mihalcea.vlad at gmail.com  Tue Feb  6 07:42:41 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 6 Feb 2018 14:42:41 +0200
Subject: [hibernate-dev] Repackaging dependencies with Hibernate
Message-ID: <CA+gWKMCfFrokxFkXj8wRmV+QMZBS52N2to8rkonUiNnCr7ZMzw@mail.gmail.com>

Hi,

This Hibernate forum question provides a good point:

https://discourse.hibernate.org/t/hibernate-in-weblogic-has-a-conflicting-antlr-version-what-to-do/189

Frameworks like EclipseLink and Spring (
https://twitter.com/starbuxman/status/960854907854249986 ) repackage
dependencies to avoid the issue when the user needs a different library
version (ANTLR 3.3) in their Classpath.

Is it possible to do so for Hibernate ORM? Is there any license issues that
would prevent doing it?

Vlad

From chris at hibernate.org  Tue Feb  6 08:29:20 2018
From: chris at hibernate.org (Chris Cranford)
Date: Tue, 6 Feb 2018 08:29:20 -0500
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
Message-ID: <b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>

Gunnar -

I don't particularly see a reason why we cannot as it seems we're
handling the CALLBACK mode with no BV provider present earlier in the
code path.? I'm fine changing it.

Chris


On 02/04/2018 07:21 AM, Gunnar Morling wrote:
> Hi,
>
> If the JPA validation mode is set to CALLBACK, BV constraints such as
> @NotNull, @Size etc. are not reflected in the DDL created by ORM.
>
> Instead, in TypeSafeActivator, the BV constraints are only considered for
> DDL if the validation mode is DDL or AUTO [1].
>
> CALLBACK is the safe way to ensure BV is invoked by JPA (instead of
> silently ignoring it if no BV provider is present), so it's the setting I
> usually recommend. I think constraints should also be propagated to DDL in
> this mode, so I'm wondering whether there a specific reason for the current
> behaviour or wether we can change it?
>
> Thanks,
>
> --Gunnar
>
> [1]
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cfg/beanvalidation/TypeSafeActivator.java#L146
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Tue Feb  6 08:29:22 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 6 Feb 2018 13:29:22 +0000
Subject: [hibernate-dev] Repackaging dependencies with Hibernate
In-Reply-To: <CA+gWKMCfFrokxFkXj8wRmV+QMZBS52N2to8rkonUiNnCr7ZMzw@mail.gmail.com>
References: <CA+gWKMCfFrokxFkXj8wRmV+QMZBS52N2to8rkonUiNnCr7ZMzw@mail.gmail.com>
Message-ID: <CAFm4XO085-mLFxc2gS3M2Ax5R+BPuEUNRYa3PT8DLoKOYEzYbw@mail.gmail.com>

Repackaging, shading, etc.. are all a nightmare for supporting the
library down the road so we'd strongly prefer against doing such
things.
For users it's a nightmare as well when it comes to debug things, as
it breaks all tools such as having your IDE download the matching
sources for stacktraces, etc..

FWIW, we had a similar discussion on Infinispan some years ago, with
some people really wanting to hide some dependencies into shaded
modules to make project setup simpler. I lost that argument: shading
was done, and later we had so much pain that the decision was now
finally reverted. That team learned the lesson and will never use
shading again.

I hate to sound biased, but when you run an application in WildFly you
don't have this issue, as these "internal dependencies" don't pollute
the application's classpath: it's not a problem at all if the user
pulls in a different version of ANTLR.
I don't know much about WebLogic, but it really should be able to do
the same as any app server is required to provide some similar feature
- perhaps in the WebLogic case it's not nicely exposed as a feature
people can use, but that's their problem to not expose useful stuff :)

Regarding non technical issues: I'm not aware of a licensing issue,
not blocking at least in the case of ANTLR although we'd likely need
to add some clarification notes in the readme and licensing notes, in
case we really wanted to do such a thing ..

I'm glad others - e.g. Spring - repackage their dependencies, so
that's less likely to conflict with our dependencies :P

Thanks,
Sanne


On 6 February 2018 at 12:42, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Hi,
>
> This Hibernate forum question provides a good point:
>
> https://discourse.hibernate.org/t/hibernate-in-weblogic-has-a-conflicting-antlr-version-what-to-do/189
>
> Frameworks like EclipseLink and Spring (
> https://twitter.com/starbuxman/status/960854907854249986 ) repackage
> dependencies to avoid the issue when the user needs a different library
> version (ANTLR 3.3) in their Classpath.
>
> Is it possible to do so for Hibernate ORM? Is there any license issues that
> would prevent doing it?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Tue Feb  6 08:36:34 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 06 Feb 2018 13:36:34 +0000
Subject: [hibernate-dev] Repackaging dependencies with Hibernate
In-Reply-To: <CAFm4XO085-mLFxc2gS3M2Ax5R+BPuEUNRYa3PT8DLoKOYEzYbw@mail.gmail.com>
References: <CA+gWKMCfFrokxFkXj8wRmV+QMZBS52N2to8rkonUiNnCr7ZMzw@mail.gmail.com>
	<CAFm4XO085-mLFxc2gS3M2Ax5R+BPuEUNRYa3PT8DLoKOYEzYbw@mail.gmail.com>
Message-ID: <CAFdSV9v3ieG1q0r6wo9OPphCCXumVd4KsoU0E6Jke8iptfrUZQ@mail.gmail.com>

I started writing the same response but I'll simply +1 Sanne's excellent
reply

On Tue, Feb 6, 2018, 7:35 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Repackaging, shading, etc.. are all a nightmare for supporting the
> library down the road so we'd strongly prefer against doing such
> things.
> For users it's a nightmare as well when it comes to debug things, as
> it breaks all tools such as having your IDE download the matching
> sources for stacktraces, etc..
>
> FWIW, we had a similar discussion on Infinispan some years ago, with
> some people really wanting to hide some dependencies into shaded
> modules to make project setup simpler. I lost that argument: shading
> was done, and later we had so much pain that the decision was now
> finally reverted. That team learned the lesson and will never use
> shading again.
>
> I hate to sound biased, but when you run an application in WildFly you
> don't have this issue, as these "internal dependencies" don't pollute
> the application's classpath: it's not a problem at all if the user
> pulls in a different version of ANTLR.
> I don't know much about WebLogic, but it really should be able to do
> the same as any app server is required to provide some similar feature
> - perhaps in the WebLogic case it's not nicely exposed as a feature
> people can use, but that's their problem to not expose useful stuff :)
>
> Regarding non technical issues: I'm not aware of a licensing issue,
> not blocking at least in the case of ANTLR although we'd likely need
> to add some clarification notes in the readme and licensing notes, in
> case we really wanted to do such a thing ..
>
> I'm glad others - e.g. Spring - repackage their dependencies, so
> that's less likely to conflict with our dependencies :P
>
> Thanks,
> Sanne
>
>
> On 6 February 2018 at 12:42, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
> > Hi,
> >
> > This Hibernate forum question provides a good point:
> >
> >
> https://discourse.hibernate.org/t/hibernate-in-weblogic-has-a-conflicting-antlr-version-what-to-do/189
> >
> > Frameworks like EclipseLink and Spring (
> > https://twitter.com/starbuxman/status/960854907854249986 ) repackage
> > dependencies to avoid the issue when the user needs a different library
> > version (ANTLR 3.3) in their Classpath.
> >
> > Is it possible to do so for Hibernate ORM? Is there any license issues
> that
> > would prevent doing it?
> >
> > Vlad
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Feb  6 08:41:22 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 06 Feb 2018 13:41:22 +0000
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
Message-ID: <CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>

The reasoning is that the 2 BV modes you mention make no mention of also
applying constraints to the database.  It would be surprising for that to
happen.  I can see the argument for AUTO, but absolutely not for CALLBACK.

Also important is the distinction that hibernate accepts multivalued
validation modes, whereas BV does not if I remember correctly... Although
in my opinion it absolutely should.

On Tue, Feb 6, 2018, 7:35 AM Chris Cranford <chris at hibernate.org> wrote:

> Gunnar -
>
> I don't particularly see a reason why we cannot as it seems we're
> handling the CALLBACK mode with no BV provider present earlier in the
> code path.  I'm fine changing it.
>
> Chris
>
>
> On 02/04/2018 07:21 AM, Gunnar Morling wrote:
> > Hi,
> >
> > If the JPA validation mode is set to CALLBACK, BV constraints such as
> > @NotNull, @Size etc. are not reflected in the DDL created by ORM.
> >
> > Instead, in TypeSafeActivator, the BV constraints are only considered for
> > DDL if the validation mode is DDL or AUTO [1].
> >
> > CALLBACK is the safe way to ensure BV is invoked by JPA (instead of
> > silently ignoring it if no BV provider is present), so it's the setting I
> > usually recommend. I think constraints should also be propagated to DDL
> in
> > this mode, so I'm wondering whether there a specific reason for the
> current
> > behaviour or wether we can change it?
> >
> > Thanks,
> >
> > --Gunnar
> >
> > [1]
> >
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cfg/beanvalidation/TypeSafeActivator.java#L146
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Tue Feb  6 08:46:48 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 6 Feb 2018 15:46:48 +0200
Subject: [hibernate-dev] Repackaging dependencies with Hibernate
In-Reply-To: <CAFdSV9v3ieG1q0r6wo9OPphCCXumVd4KsoU0E6Jke8iptfrUZQ@mail.gmail.com>
References: <CA+gWKMCfFrokxFkXj8wRmV+QMZBS52N2to8rkonUiNnCr7ZMzw@mail.gmail.com>
	<CAFm4XO085-mLFxc2gS3M2Ax5R+BPuEUNRYa3PT8DLoKOYEzYbw@mail.gmail.com>
	<CAFdSV9v3ieG1q0r6wo9OPphCCXumVd4KsoU0E6Jke8iptfrUZQ@mail.gmail.com>
Message-ID: <CA+gWKMBesy26CjqfzzVY5OrJ+a6V_xKo3gYKM4zqXNh8O08=Yg@mail.gmail.com>

Thaks Sanne,

Can you add your response to the Hibernate forum?

Maybe the forum question will be indexed by Google and other people will
benefit from your answer.

Vlad

On Tue, Feb 6, 2018 at 3:36 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I started writing the same response but I'll simply +1 Sanne's excellent
> reply
>
> On Tue, Feb 6, 2018, 7:35 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>
>> Repackaging, shading, etc.. are all a nightmare for supporting the
>> library down the road so we'd strongly prefer against doing such
>> things.
>> For users it's a nightmare as well when it comes to debug things, as
>> it breaks all tools such as having your IDE download the matching
>> sources for stacktraces, etc..
>>
>> FWIW, we had a similar discussion on Infinispan some years ago, with
>> some people really wanting to hide some dependencies into shaded
>> modules to make project setup simpler. I lost that argument: shading
>> was done, and later we had so much pain that the decision was now
>> finally reverted. That team learned the lesson and will never use
>> shading again.
>>
>> I hate to sound biased, but when you run an application in WildFly you
>> don't have this issue, as these "internal dependencies" don't pollute
>> the application's classpath: it's not a problem at all if the user
>> pulls in a different version of ANTLR.
>> I don't know much about WebLogic, but it really should be able to do
>> the same as any app server is required to provide some similar feature
>> - perhaps in the WebLogic case it's not nicely exposed as a feature
>> people can use, but that's their problem to not expose useful stuff :)
>>
>> Regarding non technical issues: I'm not aware of a licensing issue,
>> not blocking at least in the case of ANTLR although we'd likely need
>> to add some clarification notes in the readme and licensing notes, in
>> case we really wanted to do such a thing ..
>>
>> I'm glad others - e.g. Spring - repackage their dependencies, so
>> that's less likely to conflict with our dependencies :P
>>
>> Thanks,
>> Sanne
>>
>>
>> On 6 February 2018 at 12:42, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > This Hibernate forum question provides a good point:
>> >
>> > https://discourse.hibernate.org/t/hibernate-in-weblogic-
>> has-a-conflicting-antlr-version-what-to-do/189
>> >
>> > Frameworks like EclipseLink and Spring (
>> > https://twitter.com/starbuxman/status/960854907854249986 ) repackage
>> > dependencies to avoid the issue when the user needs a different library
>> > version (ANTLR 3.3) in their Classpath.
>> >
>> > Is it possible to do so for Hibernate ORM? Is there any license issues
>> that
>> > would prevent doing it?
>> >
>> > Vlad
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From gunnar at hibernate.org  Tue Feb  6 08:52:00 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 6 Feb 2018 14:52:00 +0100
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
Message-ID: <CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>

2018-02-06 14:41 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> The reasoning is that the 2 BV modes you mention make no mention of also
> applying constraints to the database.  It would be surprising for that to
> happen.  I can see the argument for AUTO, but absolutely not for CALLBACK.
>
I think that a) "trigger validation upon insert/update" and b) "propagate
constraints to the DDL" are two separate concerns which should be handled
independently.

I.e. ideally I'd keep the "validation mode" property solely focused on a)
(i.e. not have that DDL enum member) and control b) (which is as you say
not defined by the spec) via a separate property. In fact, ORM already has
a property applying to b), "hibernate.validator.apply_to_ddl", although it
seems linked to "legacy Hibernate Validator" as per a log statement in
TypeSafeActivator (
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cfg/beanvalidation/TypeSafeActivator.java#L141
).

> Also important is the distinction that hibernate accepts multivalued
> validation modes, whereas BV does not if I remember correctly... Although
> in my opinion it absolutely should.
>
"validation mode" is defined by JPA, not BV. As per above I don't think it
needs to be multi-valued, those two aspects can be handled separately.



>
> On Tue, Feb 6, 2018, 7:35 AM Chris Cranford <chris at hibernate.org> wrote:
>
>> Gunnar -
>>
>> I don't particularly see a reason why we cannot as it seems we're
>> handling the CALLBACK mode with no BV provider present earlier in the
>> code path.  I'm fine changing it.
>>
>> Chris
>>
>>
>> On 02/04/2018 07:21 AM, Gunnar Morling wrote:
>> > Hi,
>> >
>> > If the JPA validation mode is set to CALLBACK, BV constraints such as
>> > @NotNull, @Size etc. are not reflected in the DDL created by ORM.
>> >
>> > Instead, in TypeSafeActivator, the BV constraints are only considered
>> for
>> > DDL if the validation mode is DDL or AUTO [1].
>> >
>> > CALLBACK is the safe way to ensure BV is invoked by JPA (instead of
>> > silently ignoring it if no BV provider is present), so it's the setting
>> I
>> > usually recommend. I think constraints should also be propagated to DDL
>> in
>> > this mode, so I'm wondering whether there a specific reason for the
>> current
>> > behaviour or wether we can change it?
>> >
>> > Thanks,
>> >
>> > --Gunnar
>> >
>> > [1]
>> > https://github.com/hibernate/hibernate-orm/blob/master/
>> hibernate-core/src/main/java/org/hibernate/cfg/beanvalidation/
>> TypeSafeActivator.java#L146
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From sanne at hibernate.org  Tue Feb  6 08:55:29 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 6 Feb 2018 13:55:29 +0000
Subject: [hibernate-dev] Hiberante OGM Infinispan Remote dialect -
 Execute the command queue as a single Infispan Remote Server Task
In-Reply-To: <CAFiQRE_=-gBtg3tj91hn0sktQO2=NxcuFNdBWBTyLzG_q30WJg@mail.gmail.com>
References: <CAFiQRE87L6HrNZc+P+so2PXhm4=n7a2dz5roTqkfneJNA97_aQ@mail.gmail.com>
	<06f01f6e-1e11-1e2d-a933-3094e6539f0e@redhat.com>
	<CAFiQRE_=-gBtg3tj91hn0sktQO2=NxcuFNdBWBTyLzG_q30WJg@mail.gmail.com>
Message-ID: <CAFm4XO1=zJGADu4En3npjgOjyqDrqgtnuRWNwg5h1LgRC0CseA@mail.gmail.com>

Thanks for starting this, great ideas.

We should start exploring such options but I am thinking of some more
limitations that we'll have to overcome. To keep the discussion from
getting hopelessly complex, let's try to clarify the purpose:

The goal is to solve two problems which are strongly related:
  # performance / efficiency
  # better ACIDity of "transactions"

# Efficiency
Radim makes a great point, it would be nice to be able to address the
optimal node for any "task" we might want to perform.
JIRA:
 - https://issues.jboss.org/browse/ISPN-8770

However while we wait for the Infinispan team to provide such
refinements, I think we should go ahead with this plan already, not
least for the other reasons, but also to be able to eventually provide
quick feedback on such improvements.

Clearly this means we'll incur (possibly?) a performance hit when
running a simple task - such as writing a single key - but it
shouldn't matter much for more complex operations: especially with a
small sized cluster chances are high to hit a node owning at least one
of these.

For the moment our client could detect if it's preferrable to run a
task or a "simple op"; essentially we could implement some of
ISPN-8770 in our Dialect but rather than making this too complex on
our side I'd contribute to the Infinispan improvement first.

# "one transaction, one task" ?

Just to clarify, we can't promise that the ORM won't need to flush
multiple times before the transaction is finally committed. Make sure
you read about auto-flush strategies, either in our docs or there are
many good articles about the topic.
In a nutshell, if there are dirty entities of some type A, and then a
query is run on that same type A, the ORM engine needs to flush the
pending changes on all As first to make sure the queries are accurate.
We could debate if this is appropriate and maybe we shouldn't do it on
all NoSQL stores, but it's certainly debatable as it's a change in
semantics compared to what people are used to.

It's not entirely bad news though; while a single transaction might
actually be performed by multiple, independent although ordered "Task
RPC"s this will give us some opportunity to at least make sure that
operations which really need to be atomic will happen atomically; for
example when we delete an entity we can make sure that all references
are cleared up correctly. However it's not a real transaction still
and we need to be clear about that, no big deal as "real transactions"
will come soon in Infinispan Remote too.

# Usability

Just a note on this. I hope we can try to work on this while expecting
that the Infinispan Server won't need to have specific code deployed
which depends on the specific application, such as the object model.
If it helps we can think of an "OGM extensions" to be included with
the Infinispan Server, but the code we include would then need to be
able to work with any schema. Ideally, even with multiple versions of
OGM, so I'd hope that we can design the models of each task we'll need
as Protobuf Entities.

Fabio, do you want to start working on such a POC?

Thanks,
Sanne





On 5 February 2018 at 15:05, Fabio Massimo Ercoli <fercoli at redhat.com> wrote:
> Hi Radim,
>
> thank you for the alternative, it is very interesting.
> I've to study deeply the feature :P
>
> Fabio
>
>
> On Mon, Feb 5, 2018 at 9:53 AM, Radim Vansa <rvansa at redhat.com> wrote:
>
>> Hi Fabio,
>>
>> thinking about the cons, Hot Rod can intelligently pick the server where
>> should a given key reside, to reduce the number of hops (therefore,
>> latency). RemoteCache does not expose any way to route according to some
>> key; feel free to file a feature request in Infinispan JIRA.
>>
>> Note that in order to reduce the number of round-trips, Infinispan 9.2
>> will support true-async operations: Previously the putAsync et all just
>> moved the execution to different thread, since 9.2.0.CR2 it sends the
>> request to the wire right await and the response is received through a
>> CompletableFuture. At this moment multiple requests will need a distinct
>> TCP connection for each concurrent operation, but this limitation is
>> likely to be removed in 9.3. The goal is to let you write the batch down
>> one-by-one using async API and just wait for all the operations to
>> complete.
>>
>> I know this won't help for all the types of operation (a lack of
>> client-side API sometimes forces OGM to use get() + CAS in a loop).
>>
>> I am not trying to talk you out of the remote execution API, just
>> spreading news about the emerging alternatives.
>>
>> Radim
>>
>> On 02/02/2018 09:24 AM, Fabio Massimo Ercoli wrote:
>> > I'm Fabio, nice to meet you.
>> >
>> > Speaking of the current implementation of the Infinispan remote dialect
>> of
>> > Hibernate OGM, working on issue OGM-1206 and talking with Davide I
>> noticed
>> > that the unit of work commands are executed (flushed to datastore) at the
>> > end of the transaction itself.
>> > In particular I noticed that the commands are stored in a transaction
>> > scoped object of type org.hibernate.ogm.dialect.
>> batch.spi.OperationsQueue.
>> >
>> > Instead of perfom one remote invocation for each command in the method
>> >   org.hibernate.ogm.dialect.impl.BatchOperationsDelegator::executeBatch
>> > maybe we could invoke a proper Infispan Remote Server Task to execute the
>> > command queue on server side as a bulk operation.
>> >
>> > Moving the execution of the server-side command list (Infinispan) we
>> would
>> > have the advantage of reducing remote interactions. Moreover and above
>> all
>> > the execution of the command queue would be a transactional work unit, on
>> > which could be apply a Repeteable Read isolation level, for instance.
>> >
>> > The solution would not solve the need for an XA client instead, but it
>> > could be adopted by customers interested in local transactions.
>> >
>> > What do you think about it?
>> > Can I open a Jira issue?
>> >
>> > Fabio
>> >
>>
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss Performance Team
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
>
> --
>
> FABIO MASSIMO ERCOLI
>
> Senior Software Engineer - Hibernate & Data Platform
>
> Red Hat <https://www.redhat.com/>
>
> fabio.ercoli at redhat.com    M: (+39)-329.8681441
> <http://redhatemailsignature-marketing.itos.redhat.com/>
> <https://red.ht/sig>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From rvansa at redhat.com  Tue Feb  6 09:17:58 2018
From: rvansa at redhat.com (Radim Vansa)
Date: Tue, 6 Feb 2018 15:17:58 +0100
Subject: [hibernate-dev] Hiberante OGM Infinispan Remote dialect -
 Execute the command queue as a single Infispan Remote Server Task
In-Reply-To: <CAFm4XO1=zJGADu4En3npjgOjyqDrqgtnuRWNwg5h1LgRC0CseA@mail.gmail.com>
References: <CAFiQRE87L6HrNZc+P+so2PXhm4=n7a2dz5roTqkfneJNA97_aQ@mail.gmail.com>
	<06f01f6e-1e11-1e2d-a933-3094e6539f0e@redhat.com>
	<CAFiQRE_=-gBtg3tj91hn0sktQO2=NxcuFNdBWBTyLzG_q30WJg@mail.gmail.com>
	<CAFm4XO1=zJGADu4En3npjgOjyqDrqgtnuRWNwg5h1LgRC0CseA@mail.gmail.com>
Message-ID: <79468a6a-9775-657b-5b3e-8c73fdde8ce0@redhat.com>

On 02/06/2018 02:55 PM, Sanne Grinovero wrote:
> Thanks for starting this, great ideas.
>
> We should start exploring such options but I am thinking of some more
> limitations that we'll have to overcome. To keep the discussion from
> getting hopelessly complex, let's try to clarify the purpose:
>
> The goal is to solve two problems which are strongly related:
>    # performance / efficiency
>    # better ACIDity of "transactions"
>
> # Efficiency
> Radim makes a great point, it would be nice to be able to address the
> optimal node for any "task" we might want to perform.
> JIRA:
>   - https://issues.jboss.org/browse/ISPN-8770
>
> However while we wait for the Infinispan team to provide such
> refinements, I think we should go ahead with this plan already, not
> least for the other reasons, but also to be able to eventually provide
> quick feedback on such improvements.
>
> Clearly this means we'll incur (possibly?) a performance hit when
> running a simple task - such as writing a single key - but it
> shouldn't matter much for more complex operations: especially with a
> small sized cluster chances are high to hit a node owning at least one
> of these.
>
> For the moment our client could detect if it's preferrable to run a
> task or a "simple op"; essentially we could implement some of
> ISPN-8770 in our Dialect but rather than making this too complex on
> our side I'd contribute to the Infinispan improvement first.
>
> # "one transaction, one task" ?
>
> Just to clarify, we can't promise that the ORM won't need to flush
> multiple times before the transaction is finally committed. Make sure
> you read about auto-flush strategies, either in our docs or there are
> many good articles about the topic.
> In a nutshell, if there are dirty entities of some type A, and then a
> query is run on that same type A, the ORM engine needs to flush the
> pending changes on all As first to make sure the queries are accurate.
> We could debate if this is appropriate and maybe we shouldn't do it on
> all NoSQL stores, but it's certainly debatable as it's a change in
> semantics compared to what people are used to.
>
> It's not entirely bad news though; while a single transaction might
> actually be performed by multiple, independent although ordered "Task
> RPC"s this will give us some opportunity to at least make sure that
> operations which really need to be atomic will happen atomically; for
> example when we delete an entity we can make sure that all references
> are cleared up correctly. However it's not a real transaction still
> and we need to be clear about that, no big deal as "real transactions"
> will come soon in Infinispan Remote too.

About 'real transactions': beware that current design for the Hot Rod 
transactions does not involve executing scripts withing the scope of the 
ongoing transaction. Since the server-side is already in master (for a 
while now), the protocol that lacks support for script execution in 
transaction is set. It was a 'start small' decision, so if this appears 
to be critical for your use cases please shout aloud on infinispan-dev 
list to influence that.

>
> # Usability
>
> Just a note on this. I hope we can try to work on this while expecting
> that the Infinispan Server won't need to have specific code deployed
> which depends on the specific application, such as the object model.
> If it helps we can think of an "OGM extensions" to be included with
> the Infinispan Server, but the code we include would then need to be
> able to work with any schema. Ideally, even with multiple versions of
> OGM, so I'd hope that we can design the models of each task we'll need
> as Protobuf Entities.

I hope you won't end up with OGM generating javascript to be run on the 
server :)

Radim

>
> Fabio, do you want to start working on such a POC?
>
> Thanks,
> Sanne
>
>
>
>
>
> On 5 February 2018 at 15:05, Fabio Massimo Ercoli <fercoli at redhat.com> wrote:
>> Hi Radim,
>>
>> thank you for the alternative, it is very interesting.
>> I've to study deeply the feature :P
>>
>> Fabio
>>
>>
>> On Mon, Feb 5, 2018 at 9:53 AM, Radim Vansa <rvansa at redhat.com> wrote:
>>
>>> Hi Fabio,
>>>
>>> thinking about the cons, Hot Rod can intelligently pick the server where
>>> should a given key reside, to reduce the number of hops (therefore,
>>> latency). RemoteCache does not expose any way to route according to some
>>> key; feel free to file a feature request in Infinispan JIRA.
>>>
>>> Note that in order to reduce the number of round-trips, Infinispan 9.2
>>> will support true-async operations: Previously the putAsync et all just
>>> moved the execution to different thread, since 9.2.0.CR2 it sends the
>>> request to the wire right await and the response is received through a
>>> CompletableFuture. At this moment multiple requests will need a distinct
>>> TCP connection for each concurrent operation, but this limitation is
>>> likely to be removed in 9.3. The goal is to let you write the batch down
>>> one-by-one using async API and just wait for all the operations to
>>> complete.
>>>
>>> I know this won't help for all the types of operation (a lack of
>>> client-side API sometimes forces OGM to use get() + CAS in a loop).
>>>
>>> I am not trying to talk you out of the remote execution API, just
>>> spreading news about the emerging alternatives.
>>>
>>> Radim
>>>
>>> On 02/02/2018 09:24 AM, Fabio Massimo Ercoli wrote:
>>>> I'm Fabio, nice to meet you.
>>>>
>>>> Speaking of the current implementation of the Infinispan remote dialect
>>> of
>>>> Hibernate OGM, working on issue OGM-1206 and talking with Davide I
>>> noticed
>>>> that the unit of work commands are executed (flushed to datastore) at the
>>>> end of the transaction itself.
>>>> In particular I noticed that the commands are stored in a transaction
>>>> scoped object of type org.hibernate.ogm.dialect.
>>> batch.spi.OperationsQueue.
>>>> Instead of perfom one remote invocation for each command in the method
>>>>    org.hibernate.ogm.dialect.impl.BatchOperationsDelegator::executeBatch
>>>> maybe we could invoke a proper Infispan Remote Server Task to execute the
>>>> command queue on server side as a bulk operation.
>>>>
>>>> Moving the execution of the server-side command list (Infinispan) we
>>> would
>>>> have the advantage of reducing remote interactions. Moreover and above
>>> all
>>>> the execution of the command queue would be a transactional work unit, on
>>>> which could be apply a Repeteable Read isolation level, for instance.
>>>>
>>>> The solution would not solve the need for an XA client instead, but it
>>>> could be adopted by customers interested in local transactions.
>>>>
>>>> What do you think about it?
>>>> Can I open a Jira issue?
>>>>
>>>> Fabio
>>>>
>>> --
>>> Radim Vansa <rvansa at redhat.com>
>>> JBoss Performance Team
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>> --
>>
>> FABIO MASSIMO ERCOLI
>>
>> Senior Software Engineer - Hibernate & Data Platform
>>
>> Red Hat <https://www.redhat.com/>
>>
>> fabio.ercoli at redhat.com    M: (+39)-329.8681441
>> <http://redhatemailsignature-marketing.itos.redhat.com/>
>> <https://red.ht/sig>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From steve at hibernate.org  Tue Feb  6 09:46:06 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 06 Feb 2018 14:46:06 +0000
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
Message-ID: <CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>

I'm not sure I would call them separate. They are clearly linked. Look at
it this way, if we export various "validation" constraints to the database
(DDL) it is, practically speaking, a performance overhead to also perform
those checks in memory. Right? This is, I think, the distinction you may be
missing in terms of DDL as a separate mode - only do these checks once, at
the database level.

Can all such validations be handled at the database level via contraints?
No of course not - but the vast majority in fact can.



On Tue, Feb 6, 2018, 7:52 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> 2018-02-06 14:41 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>
>> The reasoning is that the 2 BV modes you mention make no mention of also
>> applying constraints to the database.  It would be surprising for that to
>> happen.  I can see the argument for AUTO, but absolutely not for CALLBACK.
>>
> I think that a) "trigger validation upon insert/update" and b) "propagate
> constraints to the DDL" are two separate concerns which should be handled
> independently.
>
> I.e. ideally I'd keep the "validation mode" property solely focused on a)
> (i.e. not have that DDL enum member) and control b) (which is as you say
> not defined by the spec) via a separate property. In fact, ORM already has
> a property applying to b), "hibernate.validator.apply_to_ddl", although
> it seems linked to "legacy Hibernate Validator" as per a log statement in
> TypeSafeActivator (
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cfg/beanvalidation/TypeSafeActivator.java#L141
> ).
>
>> Also important is the distinction that hibernate accepts multivalued
>> validation modes, whereas BV does not if I remember correctly... Although
>> in my opinion it absolutely should.
>>
> "validation mode" is defined by JPA, not BV. As per above I don't think it
> needs to be multi-valued, those two aspects can be handled separately.
>
>
>
>>
>> On Tue, Feb 6, 2018, 7:35 AM Chris Cranford <chris at hibernate.org> wrote:
>>
>>> Gunnar -
>>>
>>> I don't particularly see a reason why we cannot as it seems we're
>>> handling the CALLBACK mode with no BV provider present earlier in the
>>> code path.  I'm fine changing it.
>>>
>>> Chris
>>>
>>>
>>> On 02/04/2018 07:21 AM, Gunnar Morling wrote:
>>> > Hi,
>>> >
>>> > If the JPA validation mode is set to CALLBACK, BV constraints such as
>>> > @NotNull, @Size etc. are not reflected in the DDL created by ORM.
>>> >
>>> > Instead, in TypeSafeActivator, the BV constraints are only considered
>>> for
>>> > DDL if the validation mode is DDL or AUTO [1].
>>> >
>>> > CALLBACK is the safe way to ensure BV is invoked by JPA (instead of
>>> > silently ignoring it if no BV provider is present), so it's the
>>> setting I
>>> > usually recommend. I think constraints should also be propagated to
>>> DDL in
>>> > this mode, so I'm wondering whether there a specific reason for the
>>> current
>>> > behaviour or wether we can change it?
>>> >
>>> > Thanks,
>>> >
>>> > --Gunnar
>>> >
>>> > [1]
>>> >
>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cfg/beanvalidation/TypeSafeActivator.java#L146
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>

From sanne at hibernate.org  Tue Feb  6 10:18:01 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 6 Feb 2018 15:18:01 +0000
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
Message-ID: <CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>

On 6 February 2018 at 14:46, Steve Ebersole <steve at hibernate.org> wrote:
> I'm not sure I would call them separate. They are clearly linked. Look at
> it this way, if we export various "validation" constraints to the database
> (DDL) it is, practically speaking, a performance overhead to also perform
> those checks in memory. Right? This is, I think, the distinction you may be
> missing in terms of DDL as a separate mode - only do these checks once, at
> the database level.

That's a grey area. Sure they are linked, as some combinations would
be nonsense, but I'd see benefits as well in being able to control
such aspects better.

In terms of performance, it might be beneficial to abort an operation
early on ("in memory") rather than have to bother the database. It's
far easier to scale a system by adding more JVMs than to scale the
RDBMs.

True it might be redundant if the business logic is perfect, but then
you'd not need validation.

> Can all such validations be handled at the database level via contraints?
> No of course not - but the vast majority in fact can.

Back in the days I've found it very useful that Hibernate ORM +
Validator + custom naming strategies, etc.. would allow me to fully
control all details of the DDL.
I used to version the DDL and have a script which gets ORM to dump it
on the same resource for each change on the model, to immediately see
the diff and understand all implications of any change on the model.
Ideal also for beginners to grow confidence in what exactly all those
annotations will do..

I'd really like to have options to still do that. I remember
complaining when Validator was standardised as IMO it lost focus from
the ORM integration; such stronger DDL integrations were available
before.

Thanks,
Sanne


>
>
>
> On Tue, Feb 6, 2018, 7:52 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> 2018-02-06 14:41 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> The reasoning is that the 2 BV modes you mention make no mention of also
>>> applying constraints to the database.  It would be surprising for that to
>>> happen.  I can see the argument for AUTO, but absolutely not for CALLBACK.
>>>
>> I think that a) "trigger validation upon insert/update" and b) "propagate
>> constraints to the DDL" are two separate concerns which should be handled
>> independently.
>>
>> I.e. ideally I'd keep the "validation mode" property solely focused on a)
>> (i.e. not have that DDL enum member) and control b) (which is as you say
>> not defined by the spec) via a separate property. In fact, ORM already has
>> a property applying to b), "hibernate.validator.apply_to_ddl", although
>> it seems linked to "legacy Hibernate Validator" as per a log statement in
>> TypeSafeActivator (
>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cfg/beanvalidation/TypeSafeActivator.java#L141
>> ).
>>
>>> Also important is the distinction that hibernate accepts multivalued
>>> validation modes, whereas BV does not if I remember correctly... Although
>>> in my opinion it absolutely should.
>>>
>> "validation mode" is defined by JPA, not BV. As per above I don't think it
>> needs to be multi-valued, those two aspects can be handled separately.
>>
>>
>>
>>>
>>> On Tue, Feb 6, 2018, 7:35 AM Chris Cranford <chris at hibernate.org> wrote:
>>>
>>>> Gunnar -
>>>>
>>>> I don't particularly see a reason why we cannot as it seems we're
>>>> handling the CALLBACK mode with no BV provider present earlier in the
>>>> code path.  I'm fine changing it.
>>>>
>>>> Chris
>>>>
>>>>
>>>> On 02/04/2018 07:21 AM, Gunnar Morling wrote:
>>>> > Hi,
>>>> >
>>>> > If the JPA validation mode is set to CALLBACK, BV constraints such as
>>>> > @NotNull, @Size etc. are not reflected in the DDL created by ORM.
>>>> >
>>>> > Instead, in TypeSafeActivator, the BV constraints are only considered
>>>> for
>>>> > DDL if the validation mode is DDL or AUTO [1].
>>>> >
>>>> > CALLBACK is the safe way to ensure BV is invoked by JPA (instead of
>>>> > silently ignoring it if no BV provider is present), so it's the
>>>> setting I
>>>> > usually recommend. I think constraints should also be propagated to
>>>> DDL in
>>>> > this mode, so I'm wondering whether there a specific reason for the
>>>> current
>>>> > behaviour or wether we can change it?
>>>> >
>>>> > Thanks,
>>>> >
>>>> > --Gunnar
>>>> >
>>>> > [1]
>>>> >
>>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cfg/beanvalidation/TypeSafeActivator.java#L146
>>>> > _______________________________________________
>>>> > hibernate-dev mailing list
>>>> > hibernate-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Tue Feb  6 10:34:06 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 06 Feb 2018 15:34:06 +0000
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
Message-ID: <CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>

On Tue, Feb 6, 2018 at 9:18 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 6 February 2018 at 14:46, Steve Ebersole <steve at hibernate.org> wrote:
> > I'm not sure I would call them separate. They are clearly linked. Look at
> > it this way, if we export various "validation" constraints to the
> database
> > (DDL) it is, practically speaking, a performance overhead to also perform
> > those checks in memory. Right? This is, I think, the distinction you may
> be
> > missing in terms of DDL as a separate mode - only do these checks once,
> at
> > the database level.
>
> That's a grey area. Sure they are linked, as some combinations would
> be nonsense, but I'd see benefits as well in being able to control
> such aspects better.
>
> In terms of performance, it might be beneficial to abort an operation
> early on ("in memory") rather than have to bother the database. It's
> far easier to scale a system by adding more JVMs than to scale the
> RDBMs.
>
> True it might be redundant if the business logic is perfect, but then
> you'd not need validation.
>

We tend to do this argument where it "not what we would do".  Well not
everyone is us :)

Also you are arguing about optimizing the exception case.  The majority
case is that the in-memory validations will (a) happen and (b) pass and
then we still have the db validations happening.


> Can all such validations be handled at the database level via contraints?
> > No of course not - but the vast majority in fact can.
>
> Back in the days I've found it very useful that Hibernate ORM +
> Validator + custom naming strategies, etc.. would allow me to fully
> control all details of the DDL.
> I used to version the DDL and have a script which gets ORM to dump it
> on the same resource for each change on the model, to immediately see
> the diff and understand all implications of any change on the model.
> Ideal also for beginners to grow confidence in what exactly all those
> annotations will do..
>

Neither what Gunnar is saying nor what we do not preclude that.

From sanne at hibernate.org  Tue Feb  6 10:42:54 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 6 Feb 2018 15:42:54 +0000
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
Message-ID: <CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>

On 6 February 2018 at 15:34, Steve Ebersole <steve at hibernate.org> wrote:
>
>
> On Tue, Feb 6, 2018 at 9:18 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> On 6 February 2018 at 14:46, Steve Ebersole <steve at hibernate.org> wrote:
>> > I'm not sure I would call them separate. They are clearly linked. Look
>> > at
>> > it this way, if we export various "validation" constraints to the
>> > database
>> > (DDL) it is, practically speaking, a performance overhead to also
>> > perform
>> > those checks in memory. Right? This is, I think, the distinction you may
>> > be
>> > missing in terms of DDL as a separate mode - only do these checks once,
>> > at
>> > the database level.
>>
>> That's a grey area. Sure they are linked, as some combinations would
>> be nonsense, but I'd see benefits as well in being able to control
>> such aspects better.
>>
>> In terms of performance, it might be beneficial to abort an operation
>> early on ("in memory") rather than have to bother the database. It's
>> far easier to scale a system by adding more JVMs than to scale the
>> RDBMs.
>>
>> True it might be redundant if the business logic is perfect, but then
>> you'd not need validation.
>
>
> We tend to do this argument where it "not what we would do".  Well not
> everyone is us :)

Not understanding what you mean with that. I'm well aware others might
have other opinions, in fact I'm suggesting to allow people more
control than what you established should be right?

> Also you are arguing about optimizing the exception case.  The majority case
> is that the in-memory validations will (a) happen and (b) pass and then we
> still have the db validations happening.

I'm aware. And that's why I said "it might be redundant ... but then
you'd not need validation".
Obviously everyone needs validation, so optimising the exception case
might be important - especially since like I said it's much cheaper to
do so in in local memory rather than have a round trip to the RDBMS to
figure it out, and consume precious RBDMS resources to have it do the
same job.

>> > Can all such validations be handled at the database level via
>> > contraints?
>> > No of course not - but the vast majority in fact can.
>>
>> Back in the days I've found it very useful that Hibernate ORM +
>> Validator + custom naming strategies, etc.. would allow me to fully
>> control all details of the DDL.
>> I used to version the DDL and have a script which gets ORM to dump it
>> on the same resource for each change on the model, to immediately see
>> the diff and understand all implications of any change on the model.
>> Ideal also for beginners to grow confidence in what exactly all those
>> annotations will do..
>
> Neither what Gunnar is saying nor what we do not preclude that.

Ok good to know. I remember some years back it wasn't doing what I'd
like - I don't remember what exactly now, but I remember wishing it
allowed the user more control.

Thanks,
Sanne

From gunnar at hibernate.org  Tue Feb  6 10:57:59 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 6 Feb 2018 16:57:59 +0100
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
Message-ID: <CADGJaX_MVh==uPHFGFvTTTyYHDwfgOJQC1rNiYYabHYrWnLsqA@mail.gmail.com>

My question essentially is why is it alright to piggy-back the enablement
of the DDL constraint export on JPA's validation mode option (which only
has been designed with the lifecycle validation in mind) for AUTO but not
for CALLBACK?

It causes a few issues: When using CALLBACK (which is the right setting if
you really want to make sure that lifecycle validation happens), there's
currently no way to have the constraint export to DDL. JPA won't allow me
to specify { CALLBACK, DDL } (as it's only a single-valued option as you
say). So I'd have to use AUTO, at the risk of lifecycle validation being
not enabled silently if the BV provider is missing from the classpath for
some reason. Also the interaction with "hibernate.validator.apply_to_ddl"
is confusing, as this only can be used to turn off the DDL export of
constraints but enabling it (the default) doesn't itself guarantee that
this is happening.

2018-02-06 15:46 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> I'm not sure I would call them separate. They are clearly linked. Look at
> it this way, if we export various "validation" constraints to the database
> (DDL) it is, practically speaking, a performance overhead to also perform
> those checks in memory. Right? This is, I think, the distinction you may be
> missing in terms of DDL as a separate mode - only do these checks once, at
> the database level.
>
> Can all such validations be handled at the database level via contraints?
> No of course not - but the vast majority in fact can.
>
>
>
> On Tue, Feb 6, 2018, 7:52 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> 2018-02-06 14:41 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> The reasoning is that the 2 BV modes you mention make no mention of also
>>> applying constraints to the database.  It would be surprising for that to
>>> happen.  I can see the argument for AUTO, but absolutely not for CALLBACK.
>>>
>> I think that a) "trigger validation upon insert/update" and b) "propagate
>> constraints to the DDL" are two separate concerns which should be handled
>> independently.
>>
>> I.e. ideally I'd keep the "validation mode" property solely focused on a)
>> (i.e. not have that DDL enum member) and control b) (which is as you say
>> not defined by the spec) via a separate property. In fact, ORM already has
>> a property applying to b), "hibernate.validator.apply_to_ddl", although
>> it seems linked to "legacy Hibernate Validator" as per a log statement in
>> TypeSafeActivator (https://github.com/hibernate/
>> hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cfg/
>> beanvalidation/TypeSafeActivator.java#L141).
>>
>>> Also important is the distinction that hibernate accepts multivalued
>>> validation modes, whereas BV does not if I remember correctly... Although
>>> in my opinion it absolutely should.
>>>
>> "validation mode" is defined by JPA, not BV. As per above I don't think
>> it needs to be multi-valued, those two aspects can be handled separately.
>>
>>
>>
>>>
>>> On Tue, Feb 6, 2018, 7:35 AM Chris Cranford <chris at hibernate.org> wrote:
>>>
>>>> Gunnar -
>>>>
>>>> I don't particularly see a reason why we cannot as it seems we're
>>>> handling the CALLBACK mode with no BV provider present earlier in the
>>>> code path.  I'm fine changing it.
>>>>
>>>> Chris
>>>>
>>>>
>>>> On 02/04/2018 07:21 AM, Gunnar Morling wrote:
>>>> > Hi,
>>>> >
>>>> > If the JPA validation mode is set to CALLBACK, BV constraints such as
>>>> > @NotNull, @Size etc. are not reflected in the DDL created by ORM.
>>>> >
>>>> > Instead, in TypeSafeActivator, the BV constraints are only considered
>>>> for
>>>> > DDL if the validation mode is DDL or AUTO [1].
>>>> >
>>>> > CALLBACK is the safe way to ensure BV is invoked by JPA (instead of
>>>> > silently ignoring it if no BV provider is present), so it's the
>>>> setting I
>>>> > usually recommend. I think constraints should also be propagated to
>>>> DDL in
>>>> > this mode, so I'm wondering whether there a specific reason for the
>>>> current
>>>> > behaviour or wether we can change it?
>>>> >
>>>> > Thanks,
>>>> >
>>>> > --Gunnar
>>>> >
>>>> > [1]
>>>> > https://github.com/hibernate/hibernate-orm/blob/master/
>>>> hibernate-core/src/main/java/org/hibernate/cfg/beanvalidation/
>>>> TypeSafeActivator.java#L146
>>>> > _______________________________________________
>>>> > hibernate-dev mailing list
>>>> > hibernate-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>

From sanne at hibernate.org  Tue Feb  6 10:59:22 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 6 Feb 2018 15:59:22 +0000
Subject: [hibernate-dev] Repackaging dependencies with Hibernate
In-Reply-To: <CA+gWKMBesy26CjqfzzVY5OrJ+a6V_xKo3gYKM4zqXNh8O08=Yg@mail.gmail.com>
References: <CA+gWKMCfFrokxFkXj8wRmV+QMZBS52N2to8rkonUiNnCr7ZMzw@mail.gmail.com>
	<CAFm4XO085-mLFxc2gS3M2Ax5R+BPuEUNRYa3PT8DLoKOYEzYbw@mail.gmail.com>
	<CAFdSV9v3ieG1q0r6wo9OPphCCXumVd4KsoU0E6Jke8iptfrUZQ@mail.gmail.com>
	<CA+gWKMBesy26CjqfzzVY5OrJ+a6V_xKo3gYKM4zqXNh8O08=Yg@mail.gmail.com>
Message-ID: <CAFm4XO2mVBJQXSbJ9n1Bfg_U-J_P-=VtofbW1qCizPh9JGbFvA@mail.gmail.com>

Done, and since the conflict was ANTLR 2 vs ANTLR 3 it might be much
simpler to resolve as there is no conflict ;)

 - https://discourse.hibernate.org/t/hibernate-in-weblogic-has-a-conflicting-antlr-version-what-to-do/189/5

Thanks,
Sanne

On 6 February 2018 at 13:46, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Thaks Sanne,
>
> Can you add your response to the Hibernate forum?
>
> Maybe the forum question will be indexed by Google and other people will
> benefit from your answer.
>
> Vlad
>
> On Tue, Feb 6, 2018 at 3:36 PM, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> I started writing the same response but I'll simply +1 Sanne's excellent
>> reply
>>
>>
>> On Tue, Feb 6, 2018, 7:35 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>>
>>> Repackaging, shading, etc.. are all a nightmare for supporting the
>>> library down the road so we'd strongly prefer against doing such
>>> things.
>>> For users it's a nightmare as well when it comes to debug things, as
>>> it breaks all tools such as having your IDE download the matching
>>> sources for stacktraces, etc..
>>>
>>> FWIW, we had a similar discussion on Infinispan some years ago, with
>>> some people really wanting to hide some dependencies into shaded
>>> modules to make project setup simpler. I lost that argument: shading
>>> was done, and later we had so much pain that the decision was now
>>> finally reverted. That team learned the lesson and will never use
>>> shading again.
>>>
>>> I hate to sound biased, but when you run an application in WildFly you
>>> don't have this issue, as these "internal dependencies" don't pollute
>>> the application's classpath: it's not a problem at all if the user
>>> pulls in a different version of ANTLR.
>>> I don't know much about WebLogic, but it really should be able to do
>>> the same as any app server is required to provide some similar feature
>>> - perhaps in the WebLogic case it's not nicely exposed as a feature
>>> people can use, but that's their problem to not expose useful stuff :)
>>>
>>> Regarding non technical issues: I'm not aware of a licensing issue,
>>> not blocking at least in the case of ANTLR although we'd likely need
>>> to add some clarification notes in the readme and licensing notes, in
>>> case we really wanted to do such a thing ..
>>>
>>> I'm glad others - e.g. Spring - repackage their dependencies, so
>>> that's less likely to conflict with our dependencies :P
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>> On 6 February 2018 at 12:42, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>> > Hi,
>>> >
>>> > This Hibernate forum question provides a good point:
>>> >
>>> >
>>> > https://discourse.hibernate.org/t/hibernate-in-weblogic-has-a-conflicting-antlr-version-what-to-do/189
>>> >
>>> > Frameworks like EclipseLink and Spring (
>>> > https://twitter.com/starbuxman/status/960854907854249986 ) repackage
>>> > dependencies to avoid the issue when the user needs a different library
>>> > version (ANTLR 3.3) in their Classpath.
>>> >
>>> > Is it possible to do so for Hibernate ORM? Is there any license issues
>>> > that
>>> > would prevent doing it?
>>> >
>>> > Vlad
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Tue Feb  6 11:01:16 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 06 Feb 2018 16:01:16 +0000
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
Message-ID: <CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>

On Tue, Feb 6, 2018 at 9:43 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 6 February 2018 at 15:34, Steve Ebersole <steve at hibernate.org> wrote:
> > We tend to do this argument where it "not what we would do".  Well not
> > everyone is us :)
>
> Not understanding what you mean with that. I'm well aware others might
> have other opinions, in fact I'm suggesting to allow people more
> control than what you established should be right?
>

Is it valid for a user to want *just* DDL-based validation?  How would that
work in Gunnar's request?

That's my point.  I mean to me there is:

   1. No validation
   2. In-memory validation
   3. In-db validation
   4. In-memory && in-db validation

All of those are valid options.  But I think Gunnar's suggestion misses #3,
although I certainly maybe just missed that in his email.  Gunnar?



> > Also you are arguing about optimizing the exception case.  The majority
> case
> > is that the in-memory validations will (a) happen and (b) pass and then
> we
> > still have the db validations happening.
>
> I'm aware. And that's why I said "it might be redundant ... but then
> you'd not need validation".
> Obviously everyone needs validation, so optimising the exception case
> might be important - especially since like I said it's much cheaper to
> do so in in local memory rather than have a round trip to the RDBMS to
> figure it out, and consume precious RBDMS resources to have it do the
> same job.
>


   1. No its not "obvious everyone needs validation".  I've worked on a few
   "raw input" systems (data imports, data transfers, etc) where you'd
   actually want absolutely no validation.  I'm sure there are other stories
   out there where conditions call for no validation..
   2. "so optimising the exception case *might* be important" - might,
   absolutely.  And then the rest of this comment... I mean you assume so many
   things about that app, the environment, etc

From steve at hibernate.org  Tue Feb  6 11:06:43 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 06 Feb 2018 16:06:43 +0000
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CADGJaX_MVh==uPHFGFvTTTyYHDwfgOJQC1rNiYYabHYrWnLsqA@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CADGJaX_MVh==uPHFGFvTTTyYHDwfgOJQC1rNiYYabHYrWnLsqA@mail.gmail.com>
Message-ID: <CAFdSV9vAbLd=NA4+a+b3+zjSjCGC8vA3uKh_TwBHFuP_rMVmWQ@mail.gmail.com>

On Tue, Feb 6, 2018 at 9:58 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> My question essentially is why is it alright to piggy-back the enablement
> of the DDL constraint export on JPA's validation mode option (which only
> has been designed with the lifecycle validation in mind) for AUTO but not
> for CALLBACK?
>

Because a user picked CALLBACK, which has a very specific meaning.  Its
like me asking a framework to do (a) and it chooses to also do (b).  (b)
might be nice and it might even be helpful, but I did not ask it to do
(b).  And even worse if the framework actually provides a way to ask for
(b).



>
> It causes a few issues: When using CALLBACK (which is the right setting if
> you really want to make sure that lifecycle validation happens), there's
> currently no way to have the constraint export to DDL. JPA won't allow me
> to specify { CALLBACK, DDL } (as it's only a single-valued option as you
> say). So I'd have to use AUTO, at the risk of lifecycle validation being
> not enabled silently if the BV provider is missing from the classpath for
> some reason. Also the interaction with "hibernate.validator.apply_to_ddl"
> is confusing, as this only can be used to turn off the DDL export of
> constraints but enabling it (the default) doesn't itself guarantee that
> this is happening.
>

Ok, then the crux here is that you do not like that we make a JPA-defined
single-valued setting into a multi-valued setting.  Ok, I can understand
that.  So then what is your suggestion?  Because I did not like your
original suggestion for the reasons I have stated, unless I mis-read your
suggestion




>
> 2018-02-06 15:46 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>
>> I'm not sure I would call them separate. They are clearly linked. Look at
>> it this way, if we export various "validation" constraints to the database
>> (DDL) it is, practically speaking, a performance overhead to also perform
>> those checks in memory. Right? This is, I think, the distinction you may be
>> missing in terms of DDL as a separate mode - only do these checks once, at
>> the database level.
>>
>> Can all such validations be handled at the database level via contraints?
>> No of course not - but the vast majority in fact can.
>>
>>
>>
>> On Tue, Feb 6, 2018, 7:52 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>>> 2018-02-06 14:41 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> The reasoning is that the 2 BV modes you mention make no mention of
>>>> also applying constraints to the database.  It would be surprising for that
>>>> to happen.  I can see the argument for AUTO, but absolutely not for
>>>> CALLBACK.
>>>>
>>> I think that a) "trigger validation upon insert/update" and b)
>>> "propagate constraints to the DDL" are two separate concerns which should
>>> be handled independently.
>>>
>>> I.e. ideally I'd keep the "validation mode" property solely focused on
>>> a) (i.e. not have that DDL enum member) and control b) (which is as you say
>>> not defined by the spec) via a separate property. In fact, ORM already has
>>> a property applying to b), "hibernate.validator.apply_to_ddl", although
>>> it seems linked to "legacy Hibernate Validator" as per a log statement in
>>> TypeSafeActivator (
>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cfg/beanvalidation/TypeSafeActivator.java#L141
>>> ).
>>>
>>>> Also important is the distinction that hibernate accepts multivalued
>>>> validation modes, whereas BV does not if I remember correctly... Although
>>>> in my opinion it absolutely should.
>>>>
>>> "validation mode" is defined by JPA, not BV. As per above I don't think
>>> it needs to be multi-valued, those two aspects can be handled separately.
>>>
>>>
>>>
>>>>
>>>> On Tue, Feb 6, 2018, 7:35 AM Chris Cranford <chris at hibernate.org>
>>>> wrote:
>>>>
>>>>> Gunnar -
>>>>>
>>>>> I don't particularly see a reason why we cannot as it seems we're
>>>>> handling the CALLBACK mode with no BV provider present earlier in the
>>>>> code path.  I'm fine changing it.
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>> On 02/04/2018 07:21 AM, Gunnar Morling wrote:
>>>>> > Hi,
>>>>> >
>>>>> > If the JPA validation mode is set to CALLBACK, BV constraints such as
>>>>> > @NotNull, @Size etc. are not reflected in the DDL created by ORM.
>>>>> >
>>>>> > Instead, in TypeSafeActivator, the BV constraints are only
>>>>> considered for
>>>>> > DDL if the validation mode is DDL or AUTO [1].
>>>>> >
>>>>> > CALLBACK is the safe way to ensure BV is invoked by JPA (instead of
>>>>> > silently ignoring it if no BV provider is present), so it's the
>>>>> setting I
>>>>> > usually recommend. I think constraints should also be propagated to
>>>>> DDL in
>>>>> > this mode, so I'm wondering whether there a specific reason for the
>>>>> current
>>>>> > behaviour or wether we can change it?
>>>>> >
>>>>> > Thanks,
>>>>> >
>>>>> > --Gunnar
>>>>> >
>>>>> > [1]
>>>>> >
>>>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cfg/beanvalidation/TypeSafeActivator.java#L146
>>>>> > _______________________________________________
>>>>> > hibernate-dev mailing list
>>>>> > hibernate-dev at lists.jboss.org
>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>>
>

From gunnar at hibernate.org  Tue Feb  6 11:09:13 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 6 Feb 2018 17:09:13 +0100
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
Message-ID: <CADGJaX8fziGpmYV9qdfROg=QfhvR1Dud-a0GWm_aFXGJcf++=g@mail.gmail.com>

> All of those are valid options.  But I think Gunnar's suggestion misses
#3, although I certainly maybe just missed that in his email.  Gunnar?

You'd have this:

- No validation: validation mode = NONE, hibernate.validator.apply_to_ddl =
false
- In-memory validation: validation mode = AUTO|CALLBACK,
hibernate.validator.apply_to_ddl = false
- In-db validation: validation mode = NONE, hibernate.validator.apply_to_ddl
= true
- In-memory && in-db validation: validation mode = AUTO|CALLBACK,
hibernate.validator.apply_to_ddl = true

Hibernate's validation mode DDL would be deprecated, being an alias for
hibernate.validator.apply_to_ddl = true, if present.

2018-02-06 17:01 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> On Tue, Feb 6, 2018 at 9:43 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 6 February 2018 at 15:34, Steve Ebersole <steve at hibernate.org> wrote:
>> > We tend to do this argument where it "not what we would do".  Well not
>> > everyone is us :)
>>
>> Not understanding what you mean with that. I'm well aware others might
>> have other opinions, in fact I'm suggesting to allow people more
>> control than what you established should be right?
>>
>
> Is it valid for a user to want *just* DDL-based validation?  How would
> that work in Gunnar's request?
>
> That's my point.  I mean to me there is:
>
>    1. No validation
>    2. In-memory validation
>    3. In-db validation
>    4. In-memory && in-db validation
>
> All of those are valid options.  But I think Gunnar's suggestion misses
> #3, although I certainly maybe just missed that in his email.  Gunnar?
>
>
>
>> > Also you are arguing about optimizing the exception case.  The majority
>> case
>> > is that the in-memory validations will (a) happen and (b) pass and then
>> we
>> > still have the db validations happening.
>>
>> I'm aware. And that's why I said "it might be redundant ... but then
>> you'd not need validation".
>> Obviously everyone needs validation, so optimising the exception case
>> might be important - especially since like I said it's much cheaper to
>> do so in in local memory rather than have a round trip to the RDBMS to
>> figure it out, and consume precious RBDMS resources to have it do the
>> same job.
>>
>
>
>    1. No its not "obvious everyone needs validation".  I've worked on a
>    few "raw input" systems (data imports, data transfers, etc) where you'd
>    actually want absolutely no validation.  I'm sure there are other stories
>    out there where conditions call for no validation..
>    2. "so optimising the exception case *might* be important" - might,
>    absolutely.  And then the rest of this comment... I mean you assume so many
>    things about that app, the environment, etc
>
>

From andrea at hibernate.org  Tue Feb  6 11:11:41 2018
From: andrea at hibernate.org (andrea boriero)
Date: Tue, 6 Feb 2018 16:11:41 +0000
Subject: [hibernate-dev] Starting 5.2.13 release
Message-ID: <CAL00eSSTPpXkeUneT0df4H_N9eqThkhG59cq8EhOKBRakYSjGg@mail.gmail.com>

*Please do not push anything to 5.2 branch.Thanks,Andrea*

From steve at hibernate.org  Tue Feb  6 11:20:35 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 06 Feb 2018 16:20:35 +0000
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CADGJaX8fziGpmYV9qdfROg=QfhvR1Dud-a0GWm_aFXGJcf++=g@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
	<CADGJaX8fziGpmYV9qdfROg=QfhvR1Dud-a0GWm_aFXGJcf++=g@mail.gmail.com>
Message-ID: <CAFdSV9vDc+LzbB1zNuxvRX214YtnAboN9m8frv7-ZAobpZmofQ@mail.gmail.com>

I personally think 2 settings to control 1 thing is fugly, but if there is
a consensus that is fine.  Bu so far its just been you saying that.

On Tue, Feb 6, 2018 at 10:09 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> > All of those are valid options.  But I think Gunnar's suggestion misses
> #3, although I certainly maybe just missed that in his email.  Gunnar?
>
> You'd have this:
>
> - No validation: validation mode = NONE, hibernate.validator.apply_to_ddl
> = false
> - In-memory validation: validation mode = AUTO|CALLBACK,
> hibernate.validator.apply_to_ddl = false
> - In-db validation: validation mode = NONE, hibernate.validator.apply_to_ddl
> = true
> - In-memory && in-db validation: validation mode = AUTO|CALLBACK,
> hibernate.validator.apply_to_ddl = true
>
> Hibernate's validation mode DDL would be deprecated, being an alias for
> hibernate.validator.apply_to_ddl = true, if present.
>
> 2018-02-06 17:01 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>
>> On Tue, Feb 6, 2018 at 9:43 AM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>>> On 6 February 2018 at 15:34, Steve Ebersole <steve at hibernate.org> wrote:
>>> > We tend to do this argument where it "not what we would do".  Well not
>>> > everyone is us :)
>>>
>>> Not understanding what you mean with that. I'm well aware others might
>>> have other opinions, in fact I'm suggesting to allow people more
>>> control than what you established should be right?
>>>
>>
>> Is it valid for a user to want *just* DDL-based validation?  How would
>> that work in Gunnar's request?
>>
>> That's my point.  I mean to me there is:
>>
>>    1. No validation
>>    2. In-memory validation
>>    3. In-db validation
>>    4. In-memory && in-db validation
>>
>> All of those are valid options.  But I think Gunnar's suggestion misses
>> #3, although I certainly maybe just missed that in his email.  Gunnar?
>>
>>
>>
>>> > Also you are arguing about optimizing the exception case.  The
>>> majority case
>>> > is that the in-memory validations will (a) happen and (b) pass and
>>> then we
>>> > still have the db validations happening.
>>>
>>> I'm aware. And that's why I said "it might be redundant ... but then
>>> you'd not need validation".
>>> Obviously everyone needs validation, so optimising the exception case
>>> might be important - especially since like I said it's much cheaper to
>>> do so in in local memory rather than have a round trip to the RDBMS to
>>> figure it out, and consume precious RBDMS resources to have it do the
>>> same job.
>>>
>>
>>
>>    1. No its not "obvious everyone needs validation".  I've worked on a
>>    few "raw input" systems (data imports, data transfers, etc) where you'd
>>    actually want absolutely no validation.  I'm sure there are other stories
>>    out there where conditions call for no validation..
>>    2. "so optimising the exception case *might* be important" - might,
>>    absolutely.  And then the rest of this comment... I mean you assume so many
>>    things about that app, the environment, etc
>>
>>
>

From gunnar at hibernate.org  Tue Feb  6 15:07:12 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 6 Feb 2018 21:07:12 +0100
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CAFdSV9vDc+LzbB1zNuxvRX214YtnAboN9m8frv7-ZAobpZmofQ@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
	<CADGJaX8fziGpmYV9qdfROg=QfhvR1Dud-a0GWm_aFXGJcf++=g@mail.gmail.com>
	<CAFdSV9vDc+LzbB1zNuxvRX214YtnAboN9m8frv7-ZAobpZmofQ@mail.gmail.com>
Message-ID: <CADGJaX8_2W2zvOthcK8xHc0QPDAbV-yBjw+AyykLT7yDQ-MgVg@mail.gmail.com>

It's not quite clear to me what your preferred alternative is. Not being
able to export constraints to DDL when using the safest validation mode
(CALLBACK) is not desirable IMHO.

+1 to hear what others think.

2018-02-06 17:20 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> I personally think 2 settings to control 1 thing is fugly, but if there is
> a consensus that is fine.  Bu so far its just been you saying that.
>
> On Tue, Feb 6, 2018 at 10:09 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> > All of those are valid options.  But I think Gunnar's suggestion misses
>> #3, although I certainly maybe just missed that in his email.  Gunnar?
>>
>> You'd have this:
>>
>> - No validation: validation mode = NONE, hibernate.validator.apply_to_ddl
>> = false
>> - In-memory validation: validation mode = AUTO|CALLBACK, hibernate.
>> validator.apply_to_ddl = false
>> - In-db validation: validation mode = NONE, hibernate.validator.apply_to_ddl
>> = true
>> - In-memory && in-db validation: validation mode = AUTO|CALLBACK,
>> hibernate.validator.apply_to_ddl = true
>>
>> Hibernate's validation mode DDL would be deprecated, being an alias for
>> hibernate.validator.apply_to_ddl = true, if present.
>>
>> 2018-02-06 17:01 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> On Tue, Feb 6, 2018 at 9:43 AM Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>>
>>>> On 6 February 2018 at 15:34, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>> > We tend to do this argument where it "not what we would do".  Well not
>>>> > everyone is us :)
>>>>
>>>> Not understanding what you mean with that. I'm well aware others might
>>>> have other opinions, in fact I'm suggesting to allow people more
>>>> control than what you established should be right?
>>>>
>>>
>>> Is it valid for a user to want *just* DDL-based validation?  How would
>>> that work in Gunnar's request?
>>>
>>> That's my point.  I mean to me there is:
>>>
>>>    1. No validation
>>>    2. In-memory validation
>>>    3. In-db validation
>>>    4. In-memory && in-db validation
>>>
>>> All of those are valid options.  But I think Gunnar's suggestion misses
>>> #3, although I certainly maybe just missed that in his email.  Gunnar?
>>>
>>>
>>>
>>>> > Also you are arguing about optimizing the exception case.  The
>>>> majority case
>>>> > is that the in-memory validations will (a) happen and (b) pass and
>>>> then we
>>>> > still have the db validations happening.
>>>>
>>>> I'm aware. And that's why I said "it might be redundant ... but then
>>>> you'd not need validation".
>>>> Obviously everyone needs validation, so optimising the exception case
>>>> might be important - especially since like I said it's much cheaper to
>>>> do so in in local memory rather than have a round trip to the RDBMS to
>>>> figure it out, and consume precious RBDMS resources to have it do the
>>>> same job.
>>>>
>>>
>>>
>>>    1. No its not "obvious everyone needs validation".  I've worked on a
>>>    few "raw input" systems (data imports, data transfers, etc) where you'd
>>>    actually want absolutely no validation.  I'm sure there are other stories
>>>    out there where conditions call for no validation..
>>>    2. "so optimising the exception case *might* be important" - might,
>>>    absolutely.  And then the rest of this comment... I mean you assume so many
>>>    things about that app, the environment, etc
>>>
>>>
>>

From steve at hibernate.org  Tue Feb  6 15:55:21 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 06 Feb 2018 20:55:21 +0000
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CADGJaX8_2W2zvOthcK8xHc0QPDAbV-yBjw+AyykLT7yDQ-MgVg@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
	<CADGJaX8fziGpmYV9qdfROg=QfhvR1Dud-a0GWm_aFXGJcf++=g@mail.gmail.com>
	<CAFdSV9vDc+LzbB1zNuxvRX214YtnAboN9m8frv7-ZAobpZmofQ@mail.gmail.com>
	<CADGJaX8_2W2zvOthcK8xHc0QPDAbV-yBjw+AyykLT7yDQ-MgVg@mail.gmail.com>
Message-ID: <CAFdSV9swUMJeNds5bJgHjqUUeKAwVu-Nuu_QH843zRjpnsxMZw@mail.gmail.com>

Well like I said, I understand your not liking that we reuse a JPA-specific
setting regarding the validation mode (single-valued) and expand it to
accept multiple values.  I just think its just as bad to use 2 different
settings.  2 wrongs don't make a right.

When you say "safest" you mean (I assume) in terms of JPA provider
portability.  Because otherwise, I'm sure you are already talking about a
Hibernate-specific feature.

My specific concern with your 2 setting approach?  Well what about when I
want to disable validation for whatever reason?  So I set
`javax.persistence.validation.mode=NONE` (because, you know, that's the
"safest").  But I still get constraints exported.  And I can hear the next
answer... big deal, you get it exported to the schema... who cares?  Well I
do.  I have a real problem with telling a framework to do something, and it
does something else.

I don't have a great answer.  But then again, I'm not the one suggesting a
change ;)

On Tue, Feb 6, 2018 at 2:07 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> It's not quite clear to me what your preferred alternative is. Not being
> able to export constraints to DDL when using the safest validation mode
> (CALLBACK) is not desirable IMHO.
>
> +1 to hear what others think.
>
> 2018-02-06 17:20 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>
>> I personally think 2 settings to control 1 thing is fugly, but if there
>> is a consensus that is fine.  Bu so far its just been you saying that.
>>
>> On Tue, Feb 6, 2018 at 10:09 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> > All of those are valid options.  But I think Gunnar's suggestion
>>> misses #3, although I certainly maybe just missed that in his email.
>>> Gunnar?
>>>
>>> You'd have this:
>>>
>>> - No validation: validation mode = NONE, hibernate.validator.apply_to_ddl
>>> = false
>>> - In-memory validation: validation mode = AUTO|CALLBACK,
>>> hibernate.validator.apply_to_ddl = false
>>> - In-db validation: validation mode = NONE,
>>> hibernate.validator.apply_to_ddl = true
>>> - In-memory && in-db validation: validation mode = AUTO|CALLBACK,
>>> hibernate.validator.apply_to_ddl = true
>>>
>>> Hibernate's validation mode DDL would be deprecated, being an alias for
>>> hibernate.validator.apply_to_ddl = true, if present.
>>>
>>> 2018-02-06 17:01 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> On Tue, Feb 6, 2018 at 9:43 AM Sanne Grinovero <sanne at hibernate.org>
>>>> wrote:
>>>>
>>>>> On 6 February 2018 at 15:34, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>> > We tend to do this argument where it "not what we would do".  Well
>>>>> not
>>>>> > everyone is us :)
>>>>>
>>>>> Not understanding what you mean with that. I'm well aware others might
>>>>> have other opinions, in fact I'm suggesting to allow people more
>>>>> control than what you established should be right?
>>>>>
>>>>
>>>> Is it valid for a user to want *just* DDL-based validation?  How would
>>>> that work in Gunnar's request?
>>>>
>>>> That's my point.  I mean to me there is:
>>>>
>>>>    1. No validation
>>>>    2. In-memory validation
>>>>    3. In-db validation
>>>>    4. In-memory && in-db validation
>>>>
>>>> All of those are valid options.  But I think Gunnar's suggestion misses
>>>> #3, although I certainly maybe just missed that in his email.  Gunnar?
>>>>
>>>>
>>>>
>>>>> > Also you are arguing about optimizing the exception case.  The
>>>>> majority case
>>>>> > is that the in-memory validations will (a) happen and (b) pass and
>>>>> then we
>>>>> > still have the db validations happening.
>>>>>
>>>>> I'm aware. And that's why I said "it might be redundant ... but then
>>>>> you'd not need validation".
>>>>> Obviously everyone needs validation, so optimising the exception case
>>>>> might be important - especially since like I said it's much cheaper to
>>>>> do so in in local memory rather than have a round trip to the RDBMS to
>>>>> figure it out, and consume precious RBDMS resources to have it do the
>>>>> same job.
>>>>>
>>>>
>>>>
>>>>    1. No its not "obvious everyone needs validation".  I've worked on
>>>>    a few "raw input" systems (data imports, data transfers, etc) where you'd
>>>>    actually want absolutely no validation.  I'm sure there are other stories
>>>>    out there where conditions call for no validation..
>>>>    2. "so optimising the exception case *might* be important" - might,
>>>>    absolutely.  And then the rest of this comment... I mean you assume so many
>>>>    things about that app, the environment, etc
>>>>
>>>>
>>>
>

From guillaume.smet at gmail.com  Tue Feb  6 16:15:17 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 6 Feb 2018 22:15:17 +0100
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
Message-ID: <CALt0+o87_5g9qQGxRNL0msOSz-XCvSTak16mojh635DpzJpqMw@mail.gmail.com>

Hi,

On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <steve at hibernate.org> wrote:
>
> Is it valid for a user to want *just* DDL-based validation?  How would that
> work in Gunnar's request?
>

>From your writings, I suspect I'm the only one with this opinion but my
answer would be: "not if you use Bean Validation annotations".

If you use BV's @NotNull, you expect BV to validate the input. And you
might want additional DDL in your database to be on the safe side (which
should be the default IMHO).

-- 
Guillaume

From andrea at hibernate.org  Wed Feb  7 07:22:07 2018
From: andrea at hibernate.org (andrea boriero)
Date: Wed, 7 Feb 2018 12:22:07 +0000
Subject: [hibernate-dev] Hibernate ORM 5.2.13.Final has been released
Message-ID: <CAL00eSRKZTqu9W6J3RrPO0NqH=2TpSPqo6Ya2oJ1B4MZmO9VvA@mail.gmail.com>

*For
details:http://in.relation.to/2018/02/07/hibernate-orm-5213-final-release
<http://in.relation.to/2018/02/07/hibernate-orm-5213-final-release>*

From yoann at hibernate.org  Wed Feb  7 09:24:39 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Wed, 07 Feb 2018 14:24:39 +0000
Subject: [hibernate-dev] Hibernate Search 5.9.0.Final released
Message-ID: <CAEqagppCeHrpCtUZKHd40z7EQ_feOVHYG+_3B-wmE9o4n9fsaw@mail.gmail.com>

Hello,

We just published 5.9.0.Final, the first stable release in the 5.9 branch.
This release brings a brand-new JSR-352 integration for mass indexing,
WildFly feature packs, and better integration to modular environments.

Check out our blog for more information about this release:

http://in.relation.to/2018/02/07/hibernate-search-5-9-0-Final/
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From steve at hibernate.org  Wed Feb  7 10:08:20 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 07 Feb 2018 15:08:20 +0000
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CALt0+o87_5g9qQGxRNL0msOSz-XCvSTak16mojh635DpzJpqMw@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
	<CALt0+o87_5g9qQGxRNL0msOSz-XCvSTak16mojh635DpzJpqMw@mail.gmail.com>
Message-ID: <CAFdSV9vgQKpdvNB7aEqa_YB8WSUidS7z77ms-rG6HnujjsPHuA@mail.gmail.com>

Ok, so this is the crux then because it really comes down to whether you
believe whether it is valid to *only* export the annotation-based
validations as DDL.

And keep in mind that this code is basically unchanged from all the way
back to the initial "integrations" with HV.  So back then the
thought-process (not mine, btw) was that yes, that *is* valid - hence the
option to chose just DDL as an option.

But if thats now no longer valid then that changes things.



On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>>
>> Is it valid for a user to want *just* DDL-based validation?  How would
>> that
>> work in Gunnar's request?
>>
>
> From your writings, I suspect I'm the only one with this opinion but my
> answer would be: "not if you use Bean Validation annotations".
>
> If you use BV's @NotNull, you expect BV to validate the input. And you
> might want additional DDL in your database to be on the safe side (which
> should be the default IMHO).
>
> --
> Guillaume
>

From steve at hibernate.org  Wed Feb  7 11:30:10 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 07 Feb 2018 16:30:10 +0000
Subject: [hibernate-dev] Some insight about HHH-12101 / remove HQL-style
 positional parameters
In-Reply-To: <cbdb45f7-8ebf-0c90-9d43-3c6dc9ebec6d@gmail.com>
References: <45104e7b-6032-db91-14dd-7ba0f6405641@gmail.com>
	<cbdb45f7-8ebf-0c90-9d43-3c6dc9ebec6d@gmail.com>
Message-ID: <CAFdSV9vY=3cVgbRcJZ0_jQ_Kg-gUSQUsp2tftx0HaAQ0kxzGpA@mail.gmail.com>

Yes, I can see this being a problem.  Its caused by some very old, fulgy
code in how "list-valued parameters" are handled internally.

I'm not sure the best way to deal with this.  Unfortunately reverting this
is not possible - its necessary for JPA compliance.  The simple workaround
of course is to use named parameters yourself.  Honestly JPA's notion of
"positional" parameters is nonsensical since they are not positional - the
ordinals can repeat and can appear in any order... nothing particularly
positional about that.  In fact they are really nothing more than named
parameters that happen to use int-valued labels.

Longer term 6.0 will address this because it changes that "old, fulgy"
internal code - but those same changes are not possibly in 5.3.


On Fri, Feb 2, 2018 at 3:37 PM Laurent Almeras <lalmeras at gmail.com> wrote:

> Hi,
>
> After digging further, it seems to me that there is a bug with Hibernate
> 5.3.
>
> I debug and step through the query handling, and the generated QueryDSL
> query seems correct to me:
>
> =========================
> select queuedTaskHolder
> from QueuedTaskHolder queuedTaskHolder
> where queuedTaskHolder.status in (?1) and queuedTaskHolder.queueId = ?2
> order by queuedTaskHolder.id asc
> =========================
>
> The (:x1_0, :x1_1, :x1_2, :x1_3) part appears in the hibernate query
> handling inside layers, in
>
> org.hibernate.query.internal.QueryParameterBindingsImpl.expandListValuedParameters(String,
> SharedSessionContractImplementor) method. It seems that the purpose of
> this method is to transform query and parameters arguments when argument
> is a list. So query is rewritten with named parameters, and query
> parameters are modified to inject this new parameters.
>
> And this query is then rejected in
>
> org.hibernate.hql.internal.ast.HqlSqlWalker.generatePositionalParameter(AST,
> AST) because there are namedParameters.
>
> If I switch dependency to 5.2.12.Final release, the same code works.
>
> I'll try to write a minimal test-case about this when I'll get some
> spare time.
>
> --
> Laurent Almeras
>
> On 02/02/2018 06:00 PM, Laurent Almeras wrote:
> > Hi,
> >
> > Testing Hibernate 9.3.0.Beta2, I run into this issue:
> >
> >
> > ===============
> >   Cannot define positional and named parameterSpecs : select
> > queuedTaskHolder
> > from org.iglooproject.jpa.more.business.task.model.QueuedTaskHolder
> > queuedTaskHolder
> > where queuedTaskHolder.status in (:x1_0, :x1_1, :x1_2, :x1_3) and
> > queuedTaskHolder.queueId = ?2
> > ===============
> >
> >
> > Hibernate complains that query contains both named and positional
> > parameters (note that this query use to work on Hibernate 5.2.x).
> >
> > This new behavior is linked to:
> >
> > * this commit:
> >
> https://github.com/hibernate/hibernate-orm/commit/5e0274adbbd3e0aa3092c29a765fd203c8279126
> >
> > * this issue: https://hibernate.atlassian.net/browse/HHH-12116
> > * and this parent issue:
> https://hibernate.atlassian.net/browse/HHH-12101
> >
> > I also find that you already talk about this behavior on this same
> > mailing-list:
> >
> http://lists.jboss.org/pipermail/hibernate-dev/2016-September/015460.html
> >
> >
> > I think that allowing this behavior was not a good idea, so I don't have
> > any hope that you consider this as a bug. But I think it should be
> > noticed in the release note
> > (http://in.relation.to/2018/01/18/hibernate-orm-530-beta1-release/) or
> > in this ticket (https://hibernate.atlassian.net/browse/HHH-12101) as a
> > side-effect.
> >
> >
> > On my side, I run in this issue because I use QueryDSL-jpa, and the
> > query I give as an example is buggy because it mixes a IN statement
> > (named parameter) dans an EQUAL statement (positional parameter).
> >
> > Is there anyone following both Hibernate and QueryDSL here that is
> > already aware or working on this issue ?
> >
> >
> > Thanks
> >
> > Laurent Almeras
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed Feb  7 13:02:36 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 7 Feb 2018 19:02:36 +0100
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CAFdSV9vgQKpdvNB7aEqa_YB8WSUidS7z77ms-rG6HnujjsPHuA@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
	<CALt0+o87_5g9qQGxRNL0msOSz-XCvSTak16mojh635DpzJpqMw@mail.gmail.com>
	<CAFdSV9vgQKpdvNB7aEqa_YB8WSUidS7z77ms-rG6HnujjsPHuA@mail.gmail.com>
Message-ID: <CADGJaX93zksf7J0XMPGS=3HM=i3SN0FXEUA+Lkv14CxHyUQg3w@mail.gmail.com>

2018-02-07 16:08 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> Ok, so this is the crux then because it really comes down to whether you
> believe whether it is valid to *only* export the annotation-based
> validations as DDL.
>
> And keep in mind that this code is basically unchanged from all the way
> back to the initial "integrations" with HV.  So back then the
> thought-process (not mine, btw) was that yes, that *is* valid - hence the
> option to chose just DDL as an option.
>

You'd still have that ability with my suggestion, just keep validation mode
to NONE and set hibernate.validator.apply_to_ddl = true.

By "safest mode" above I meant CALLBACK is the right way if you really want
to make sure that lifecycle validation occurs, or you'll get an exception
if no BV provider is present. It can't happen that lifecycle validation
silently, unexpectedly doesn't happen. Hence I prefer it over AUTO. And as
things stand I can't benefit from constraints in DDL export in that case,
which is a pity.

But if thats now no longer valid then that changes things.
>
>
>
> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
> > Hi,
> >
> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <steve at hibernate.org>
> > wrote:
> >>
> >> Is it valid for a user to want *just* DDL-based validation?  How would
> >> that
> >> work in Gunnar's request?
> >>
> >
> > From your writings, I suspect I'm the only one with this opinion but my
> > answer would be: "not if you use Bean Validation annotations".
> >
> > If you use BV's @NotNull, you expect BV to validate the input. And you
> > might want additional DDL in your database to be on the safe side (which
> > should be the default IMHO).
> >
> > --
> > Guillaume
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Feb  7 13:32:23 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 07 Feb 2018 18:32:23 +0000
Subject: [hibernate-dev] ORM documentation info hibernate.org
Message-ID: <CAFdSV9vq7z5vXMCLCMbi56PiSyxCRYm9Ooy24sukiH4UCPth9A@mail.gmail.com>

Now that the hibernate.org infrastructure supports doc versions, should we
remove the version drop-down from the info pages?  Vlad I know you spent
some time adding that; what are your thoughts?

From andrea at hibernate.org  Wed Feb  7 13:36:19 2018
From: andrea at hibernate.org (andrea boriero)
Date: Wed, 7 Feb 2018 18:36:19 +0000
Subject: [hibernate-dev] ORM documentation info hibernate.org
In-Reply-To: <CAFdSV9vq7z5vXMCLCMbi56PiSyxCRYm9Ooy24sukiH4UCPth9A@mail.gmail.com>
References: <CAFdSV9vq7z5vXMCLCMbi56PiSyxCRYm9Ooy24sukiH4UCPth9A@mail.gmail.com>
Message-ID: <CAL00eSRpcDw-HBRVWioS7bV1wTSpCmDtKSeWtKB=-C77=aLe5A@mail.gmail.com>

I think it is not necessary anymore, so +1 for removing it.

On 7 February 2018 at 18:32, Steve Ebersole <steve at hibernate.org> wrote:

> Now that the hibernate.org infrastructure supports doc versions, should we
> remove the version drop-down from the info pages?  Vlad I know you spent
> some time adding that; what are your thoughts?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Wed Feb  7 13:38:14 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 7 Feb 2018 20:38:14 +0200
Subject: [hibernate-dev] ORM documentation info hibernate.org
In-Reply-To: <CAL00eSRpcDw-HBRVWioS7bV1wTSpCmDtKSeWtKB=-C77=aLe5A@mail.gmail.com>
References: <CAFdSV9vq7z5vXMCLCMbi56PiSyxCRYm9Ooy24sukiH4UCPth9A@mail.gmail.com>
	<CAL00eSRpcDw-HBRVWioS7bV1wTSpCmDtKSeWtKB=-C77=aLe5A@mail.gmail.com>
Message-ID: <CA+gWKMCqRuv-OHJozJnZRfiWuqSeSZnKMaK5Bo5uX8k0-EKNHw@mail.gmail.com>

I also think it's redundant now.

Vlad

On Wed, Feb 7, 2018 at 8:36 PM, andrea boriero <andrea at hibernate.org> wrote:

> I think it is not necessary anymore, so +1 for removing it.
>
> On 7 February 2018 at 18:32, Steve Ebersole <steve at hibernate.org> wrote:
>
> > Now that the hibernate.org infrastructure supports doc versions, should
> we
> > remove the version drop-down from the info pages?  Vlad I know you spent
> > some time adding that; what are your thoughts?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Feb  7 13:41:26 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 07 Feb 2018 18:41:26 +0000
Subject: [hibernate-dev] Some insight about HHH-12101 / remove HQL-style
 positional parameters
In-Reply-To: <66af1316-dc1a-c3a1-a6dd-4bc0fc897ee7@laposte.net>
References: <45104e7b-6032-db91-14dd-7ba0f6405641@gmail.com>
	<cbdb45f7-8ebf-0c90-9d43-3c6dc9ebec6d@gmail.com>
	<CAFdSV9vY=3cVgbRcJZ0_jQ_Kg-gUSQUsp2tftx0HaAQ0kxzGpA@mail.gmail.com>
	<66af1316-dc1a-c3a1-a6dd-4bc0fc897ee7@laposte.net>
Message-ID: <CAFdSV9uGHPiepyqXKBf_ir0tAzbzgqM_3G+6yQ17wtdQcYswiw@mail.gmail.com>

Yes, I understood the situation.

I'm saying that in your query you should just be able to switch to use
named parameters (prefixed with `:`, rather than `?`) as a workaround

On Wed, Feb 7, 2018 at 11:21 AM Laurent Almeras <laurent.almeras at laposte.net>
wrote:

> Hi,
>
> Thanks for this insight ; but as I stated (and this is a correction of the
> assumptions of my first email) in my second email, it seems that the wrong
> query (with mixed positional and named parameters) is built in hibernate
> inside layers (and not in QueryDSL).
>
> I get rid of my QueryDSL query and replace it with raw JPQL query :
>
>
> ============================
>         Query query = getEntityManager().createQuery("select
> queuedTaskHolder\n" +
>                 "from QueuedTaskHolder queuedTaskHolder\n" +
>                 "where queuedTaskHolder.status in (?1) and
> queuedTaskHolder.queueId = ?2\n" +
>                 "order by queuedTaskHolder.id asc").setParameter(1,
> ImmutableList.of(TaskStatus.CANCELLED,
> TaskStatus.COMPLETED)).setParameter(2, "queue");
>         return query.getResultList();
> ============================
>
> And it fails with the very same message :
>
>
> ============================
>
>
> Cannot define positional and named parameterSpecs : select queuedTaskHolder
> from org.iglooproject.jpa.more.business.task.model.QueuedTaskHolder
> queuedTaskHolder
>
> where queuedTaskHolder.status in (:x1_0, :x1_1) and
> queuedTaskHolder.queueId = ?2
> order by queuedTaskHolder.id asc
>     at
> org.hibernate.hql.internal.ast.HqlSqlWalker.generatePositionalParameter(HqlSqlWalker.java:1094)
>     at
> org.hibernate.hql.internal.antlr.HqlSqlBaseWalker.parameter(HqlSqlBaseWalker.java:3463)
> ============================
>
> It used to work with Hibernate 5.2.x ; and by reading JPQL spec (not sure
> if this is the right version -
> https://docs.oracle.com/html/E13946_01/ejb3_langref.html#ejb3_langref_in
> ) it seems that " IN (?param) " is a valid syntax.
>
> I agree that mixed query may not be supported, but even if positional
> parameter queries bring nothing more than named parameters ones, there are
> also required for JPA compliance ?
>
> Can you say me if I made some wrong assumptions ? If not, is it usefull I
> provide some minimal test-case ?
>
>
>
> *Side-note:* same query written with named parameters is OK (as expected):
>
>
> ============================
>         Query query = getEntityManager().createQuery("select
> queuedTaskHolder\n" +
>         "from QueuedTaskHolder queuedTaskHolder\n" +
>         "where queuedTaskHolder.status in (:statuses) and
> queuedTaskHolder.queueId = :queue\n" +
>         "order by queuedTaskHolder.id asc").setParameter("statuses",
> ImmutableList.of(TaskStatus.CANCELLED,
> TaskStatus.COMPLETED)).setParameter("queue", "queue");
>         return query.getResultList();
> ============================
>
>
>
> Thanks,
>
> Le 07/02/2018 ? 17:30, Steve Ebersole a ?crit :
>
> Yes, I can see this being a problem.  Its caused by some very old, fulgy
> code in how "list-valued parameters" are handled internally.
>
> I'm not sure the best way to deal with this.  Unfortunately reverting this
> is not possible - its necessary for JPA compliance.  The simple workaround
> of course is to use named parameters yourself.  Honestly JPA's notion of
> "positional" parameters is nonsensical since they are not positional - the
> ordinals can repeat and can appear in any order... nothing particularly
> positional about that.  In fact they are really nothing more than named
> parameters that happen to use int-valued labels.
>
> Longer term 6.0 will address this because it changes that "old, fulgy"
> internal code - but those same changes are not possibly in 5.3.
>
>
>
>

From steve at hibernate.org  Wed Feb  7 13:43:23 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 07 Feb 2018 18:43:23 +0000
Subject: [hibernate-dev] Some insight about HHH-12101 / remove HQL-style
 positional parameters
In-Reply-To: <CAFdSV9uGHPiepyqXKBf_ir0tAzbzgqM_3G+6yQ17wtdQcYswiw@mail.gmail.com>
References: <45104e7b-6032-db91-14dd-7ba0f6405641@gmail.com>
	<cbdb45f7-8ebf-0c90-9d43-3c6dc9ebec6d@gmail.com>
	<CAFdSV9vY=3cVgbRcJZ0_jQ_Kg-gUSQUsp2tftx0HaAQ0kxzGpA@mail.gmail.com>
	<66af1316-dc1a-c3a1-a6dd-4bc0fc897ee7@laposte.net>
	<CAFdSV9uGHPiepyqXKBf_ir0tAzbzgqM_3G+6yQ17wtdQcYswiw@mail.gmail.com>
Message-ID: <CAFdSV9uEL3gXTiWrj=L7b-qwfj2sV4fRYujb-6vka08Mftb+pg@mail.gmail.com>

And I did say that this is indeed a problem assuming you are right, and I
have no reason to believe you are not.  In fact I can see how that would
happen.  Yes all based on Hibernate internals.

So I am not trying to blow you off as "this is not a bug".  I think it is a
bug.  I'm just saying I do not yet know what to do about it.

On Wed, Feb 7, 2018 at 12:41 PM Steve Ebersole <steve at hibernate.org> wrote:

> Yes, I understood the situation.
>
> I'm saying that in your query you should just be able to switch to use
> named parameters (prefixed with `:`, rather than `?`) as a workaround
>
> On Wed, Feb 7, 2018 at 11:21 AM Laurent Almeras <
> laurent.almeras at laposte.net> wrote:
>
>> Hi,
>>
>> Thanks for this insight ; but as I stated (and this is a correction of
>> the assumptions of my first email) in my second email, it seems that the
>> wrong query (with mixed positional and named parameters) is built in
>> hibernate inside layers (and not in QueryDSL).
>>
>> I get rid of my QueryDSL query and replace it with raw JPQL query :
>>
>>
>> ============================
>>         Query query = getEntityManager().createQuery("select
>> queuedTaskHolder\n" +
>>                 "from QueuedTaskHolder queuedTaskHolder\n" +
>>                 "where queuedTaskHolder.status in (?1) and
>> queuedTaskHolder.queueId = ?2\n" +
>>                 "order by queuedTaskHolder.id asc").setParameter(1,
>> ImmutableList.of(TaskStatus.CANCELLED,
>> TaskStatus.COMPLETED)).setParameter(2, "queue");
>>         return query.getResultList();
>> ============================
>>
>> And it fails with the very same message :
>>
>>
>> ============================
>>
>>
>> Cannot define positional and named parameterSpecs : select
>> queuedTaskHolder
>> from org.iglooproject.jpa.more.business.task.model.QueuedTaskHolder
>> queuedTaskHolder
>>
>> where queuedTaskHolder.status in (:x1_0, :x1_1) and
>> queuedTaskHolder.queueId = ?2
>> order by queuedTaskHolder.id asc
>>     at
>> org.hibernate.hql.internal.ast.HqlSqlWalker.generatePositionalParameter(HqlSqlWalker.java:1094)
>>     at
>> org.hibernate.hql.internal.antlr.HqlSqlBaseWalker.parameter(HqlSqlBaseWalker.java:3463)
>> ============================
>>
>> It used to work with Hibernate 5.2.x ; and by reading JPQL spec (not sure
>> if this is the right version -
>> https://docs.oracle.com/html/E13946_01/ejb3_langref.html#ejb3_langref_in
>> ) it seems that " IN (?param) " is a valid syntax.
>>
>> I agree that mixed query may not be supported, but even if positional
>> parameter queries bring nothing more than named parameters ones, there are
>> also required for JPA compliance ?
>>
>> Can you say me if I made some wrong assumptions ? If not, is it usefull I
>> provide some minimal test-case ?
>>
>>
>>
>> *Side-note:* same query written with named parameters is OK (as
>> expected):
>>
>>
>> ============================
>>         Query query = getEntityManager().createQuery("select
>> queuedTaskHolder\n" +
>>         "from QueuedTaskHolder queuedTaskHolder\n" +
>>         "where queuedTaskHolder.status in (:statuses) and
>> queuedTaskHolder.queueId = :queue\n" +
>>         "order by queuedTaskHolder.id asc").setParameter("statuses",
>> ImmutableList.of(TaskStatus.CANCELLED,
>> TaskStatus.COMPLETED)).setParameter("queue", "queue");
>>         return query.getResultList();
>> ============================
>>
>>
>>
>> Thanks,
>>
>> Le 07/02/2018 ? 17:30, Steve Ebersole a ?crit :
>>
>> Yes, I can see this being a problem.  Its caused by some very old, fulgy
>> code in how "list-valued parameters" are handled internally.
>>
>> I'm not sure the best way to deal with this.  Unfortunately reverting
>> this is not possible - its necessary for JPA compliance.  The simple
>> workaround of course is to use named parameters yourself.  Honestly JPA's
>> notion of "positional" parameters is nonsensical since they are not
>> positional - the ordinals can repeat and can appear in any order... nothing
>> particularly positional about that.  In fact they are really nothing more
>> than named parameters that happen to use int-valued labels.
>>
>> Longer term 6.0 will address this because it changes that "old, fulgy"
>> internal code - but those same changes are not possibly in 5.3.
>>
>>
>>
>>

From steve at hibernate.org  Wed Feb  7 13:44:55 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 07 Feb 2018 18:44:55 +0000
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CADGJaX93zksf7J0XMPGS=3HM=i3SN0FXEUA+Lkv14CxHyUQg3w@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
	<CALt0+o87_5g9qQGxRNL0msOSz-XCvSTak16mojh635DpzJpqMw@mail.gmail.com>
	<CAFdSV9vgQKpdvNB7aEqa_YB8WSUidS7z77ms-rG6HnujjsPHuA@mail.gmail.com>
	<CADGJaX93zksf7J0XMPGS=3HM=i3SN0FXEUA+Lkv14CxHyUQg3w@mail.gmail.com>
Message-ID: <CAFdSV9s9xsyb1Cyb=sMDQx7iQzrXO89O+hVLb58wuxTe8GLkkw@mail.gmail.com>

Of course you can.  `mode = CALLBACK,DDL`

You mean that you cannot using single-valued setting

On Wed, Feb 7, 2018 at 12:02 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> 2018-02-07 16:08 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>
>> Ok, so this is the crux then because it really comes down to whether you
>> believe whether it is valid to *only* export the annotation-based
>> validations as DDL.
>>
>> And keep in mind that this code is basically unchanged from all the way
>> back to the initial "integrations" with HV.  So back then the
>> thought-process (not mine, btw) was that yes, that *is* valid - hence the
>> option to chose just DDL as an option.
>>
>
> You'd still have that ability with my suggestion, just keep validation
> mode to NONE and set hibernate.validator.apply_to_ddl = true.
>
> By "safest mode" above I meant CALLBACK is the right way if you really
> want to make sure that lifecycle validation occurs, or you'll get an
> exception if no BV provider is present. It can't happen that lifecycle
> validation silently, unexpectedly doesn't happen. Hence I prefer it over
> AUTO. And as things stand I can't benefit from constraints in DDL export in
> that case, which is a pity.
>
> But if thats now no longer valid then that changes things.
>>
>>
>>
>> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet <guillaume.smet at gmail.com>
>> wrote:
>>
>
>> > Hi,
>> >
>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <steve at hibernate.org>
>> > wrote:
>> >>
>> >> Is it valid for a user to want *just* DDL-based validation?  How would
>> >> that
>> >> work in Gunnar's request?
>> >>
>> >
>> > From your writings, I suspect I'm the only one with this opinion but my
>> > answer would be: "not if you use Bean Validation annotations".
>> >
>> > If you use BV's @NotNull, you expect BV to validate the input. And you
>> > might want additional DDL in your database to be on the safe side (which
>> > should be the default IMHO).
>> >
>> > --
>> > Guillaume
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From gunnar at hibernate.org  Wed Feb  7 13:53:24 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 7 Feb 2018 19:53:24 +0100
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CAFdSV9s9xsyb1Cyb=sMDQx7iQzrXO89O+hVLb58wuxTe8GLkkw@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
	<CALt0+o87_5g9qQGxRNL0msOSz-XCvSTak16mojh635DpzJpqMw@mail.gmail.com>
	<CAFdSV9vgQKpdvNB7aEqa_YB8WSUidS7z77ms-rG6HnujjsPHuA@mail.gmail.com>
	<CADGJaX93zksf7J0XMPGS=3HM=i3SN0FXEUA+Lkv14CxHyUQg3w@mail.gmail.com>
	<CAFdSV9s9xsyb1Cyb=sMDQx7iQzrXO89O+hVLb58wuxTe8GLkkw@mail.gmail.com>
Message-ID: <CADGJaX-_L8WsjimKQWef+krAgcaRe8T=g-mEC3rpJCOweaFkhg@mail.gmail.com>

Right, giving multiple values isn't allowed as per JPA's XSD.

2018-02-07 19:44 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> Of course you can.  `mode = CALLBACK,DDL`
>
> You mean that you cannot using single-valued setting
>
> On Wed, Feb 7, 2018 at 12:02 PM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> 2018-02-07 16:08 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> Ok, so this is the crux then because it really comes down to whether you
>>> believe whether it is valid to *only* export the annotation-based
>>> validations as DDL.
>>>
>>> And keep in mind that this code is basically unchanged from all the way
>>> back to the initial "integrations" with HV.  So back then the
>>> thought-process (not mine, btw) was that yes, that *is* valid - hence the
>>> option to chose just DDL as an option.
>>>
>>
>> You'd still have that ability with my suggestion, just keep validation
>> mode to NONE and set hibernate.validator.apply_to_ddl = true.
>>
>> By "safest mode" above I meant CALLBACK is the right way if you really
>> want to make sure that lifecycle validation occurs, or you'll get an
>> exception if no BV provider is present. It can't happen that lifecycle
>> validation silently, unexpectedly doesn't happen. Hence I prefer it over
>> AUTO. And as things stand I can't benefit from constraints in DDL export in
>> that case, which is a pity.
>>
>> But if thats now no longer valid then that changes things.
>>>
>>>
>>>
>>> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet <guillaume.smet at gmail.com>
>>> wrote:
>>>
>>
>>> > Hi,
>>> >
>>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <steve at hibernate.org>
>>> > wrote:
>>> >>
>>> >> Is it valid for a user to want *just* DDL-based validation?  How would
>>> >> that
>>> >> work in Gunnar's request?
>>> >>
>>> >
>>> > From your writings, I suspect I'm the only one with this opinion but my
>>> > answer would be: "not if you use Bean Validation annotations".
>>> >
>>> > If you use BV's @NotNull, you expect BV to validate the input. And you
>>> > might want additional DDL in your database to be on the safe side
>>> (which
>>> > should be the default IMHO).
>>> >
>>> > --
>>> > Guillaume
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>

From steve at hibernate.org  Wed Feb  7 14:05:56 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 07 Feb 2018 19:05:56 +0000
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CADGJaX-_L8WsjimKQWef+krAgcaRe8T=g-mEC3rpJCOweaFkhg@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
	<CALt0+o87_5g9qQGxRNL0msOSz-XCvSTak16mojh635DpzJpqMw@mail.gmail.com>
	<CAFdSV9vgQKpdvNB7aEqa_YB8WSUidS7z77ms-rG6HnujjsPHuA@mail.gmail.com>
	<CADGJaX93zksf7J0XMPGS=3HM=i3SN0FXEUA+Lkv14CxHyUQg3w@mail.gmail.com>
	<CAFdSV9s9xsyb1Cyb=sMDQx7iQzrXO89O+hVLb58wuxTe8GLkkw@mail.gmail.com>
	<CADGJaX-_L8WsjimKQWef+krAgcaRe8T=g-mEC3rpJCOweaFkhg@mail.gmail.com>
Message-ID: <CAFdSV9sf-urQttXXOmuWtXHJNRC7zkU6nJmSMmyqOAbBu2n=pA@mail.gmail.com>

How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?

Look, I don't mind revisiting a change here.  I really have no horse n this
race - this is not even my code originally.  TBH I thought this was code
that you did.  So I don't mind changes here if there is a consensus.  But
let's use real reasons ;)

On Wed, Feb 7, 2018 at 12:53 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> Right, giving multiple values isn't allowed as per JPA's XSD.
>
> 2018-02-07 19:44 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>
>> Of course you can.  `mode = CALLBACK,DDL`
>>
>> You mean that you cannot using single-valued setting
>>
>> On Wed, Feb 7, 2018 at 12:02 PM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> 2018-02-07 16:08 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> Ok, so this is the crux then because it really comes down to whether you
>>>> believe whether it is valid to *only* export the annotation-based
>>>> validations as DDL.
>>>>
>>>> And keep in mind that this code is basically unchanged from all the way
>>>> back to the initial "integrations" with HV.  So back then the
>>>> thought-process (not mine, btw) was that yes, that *is* valid - hence
>>>> the
>>>> option to chose just DDL as an option.
>>>>
>>>
>>> You'd still have that ability with my suggestion, just keep validation
>>> mode to NONE and set hibernate.validator.apply_to_ddl = true.
>>>
>>> By "safest mode" above I meant CALLBACK is the right way if you really
>>> want to make sure that lifecycle validation occurs, or you'll get an
>>> exception if no BV provider is present. It can't happen that lifecycle
>>> validation silently, unexpectedly doesn't happen. Hence I prefer it over
>>> AUTO. And as things stand I can't benefit from constraints in DDL export in
>>> that case, which is a pity.
>>>
>>> But if thats now no longer valid then that changes things.
>>>>
>>>>
>>>>
>>>> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet <guillaume.smet at gmail.com
>>>> >
>>>> wrote:
>>>>
>>>
>>>> > Hi,
>>>> >
>>>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <steve at hibernate.org>
>>>> > wrote:
>>>> >>
>>>> >> Is it valid for a user to want *just* DDL-based validation?  How
>>>> would
>>>> >> that
>>>> >> work in Gunnar's request?
>>>> >>
>>>> >
>>>> > From your writings, I suspect I'm the only one with this opinion but
>>>> my
>>>> > answer would be: "not if you use Bean Validation annotations".
>>>> >
>>>> > If you use BV's @NotNull, you expect BV to validate the input. And you
>>>> > might want additional DDL in your database to be on the safe side
>>>> (which
>>>> > should be the default IMHO).
>>>> >
>>>> > --
>>>> > Guillaume
>>>> >
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>

From gunnar at hibernate.org  Wed Feb  7 14:45:22 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 7 Feb 2018 20:45:22 +0100
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CAFdSV9sf-urQttXXOmuWtXHJNRC7zkU6nJmSMmyqOAbBu2n=pA@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
	<CALt0+o87_5g9qQGxRNL0msOSz-XCvSTak16mojh635DpzJpqMw@mail.gmail.com>
	<CAFdSV9vgQKpdvNB7aEqa_YB8WSUidS7z77ms-rG6HnujjsPHuA@mail.gmail.com>
	<CADGJaX93zksf7J0XMPGS=3HM=i3SN0FXEUA+Lkv14CxHyUQg3w@mail.gmail.com>
	<CAFdSV9s9xsyb1Cyb=sMDQx7iQzrXO89O+hVLb58wuxTe8GLkkw@mail.gmail.com>
	<CADGJaX-_L8WsjimKQWef+krAgcaRe8T=g-mEC3rpJCOweaFkhg@mail.gmail.com>
	<CAFdSV9sf-urQttXXOmuWtXHJNRC7zkU6nJmSMmyqOAbBu2n=pA@mail.gmail.com>
Message-ID: <CADGJaX9RjPDz_8Kf4G6OhWmnUi8kgxP0sMYnxfkeObmuC3Y=YA@mail.gmail.com>

> How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?

I was referring to the dedicated <validation-mode> element, which is
restricted to the values AUTO, CALLBACK, NONE in that XSD and which can be
given at most once [1]. I can see though how it'd work with the
javax.persistence.validation.mode String property.

So, yeah, technically no change needed. Still quite subtle and very easy to
miss. Waiting a bit for some more feedback by others, if we decide to leave
it as is, we need at least to update the HV docs to describe this in more
depth (we only mention <validation-mode> but not that string property).

[1]
https://github.com/hibernate/hibernate-orm/blob/master/tooling/metamodel-generator/src/main/xsd/persistence_2_1.xsd#L326-L339
.

2018-02-07 20:05 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?
>
> Look, I don't mind revisiting a change here.  I really have no horse n
> this race - this is not even my code originally.  TBH I thought this was
> code that you did.  So I don't mind changes here if there is a consensus.
> But let's use real reasons ;)
>
> On Wed, Feb 7, 2018 at 12:53 PM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Right, giving multiple values isn't allowed as per JPA's XSD.
>>
>> 2018-02-07 19:44 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> Of course you can.  `mode = CALLBACK,DDL`
>>>
>>> You mean that you cannot using single-valued setting
>>>
>>> On Wed, Feb 7, 2018 at 12:02 PM Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>>
>>>> 2018-02-07 16:08 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>
>>>>> Ok, so this is the crux then because it really comes down to whether
>>>>> you
>>>>> believe whether it is valid to *only* export the annotation-based
>>>>> validations as DDL.
>>>>>
>>>>> And keep in mind that this code is basically unchanged from all the way
>>>>> back to the initial "integrations" with HV.  So back then the
>>>>> thought-process (not mine, btw) was that yes, that *is* valid - hence
>>>>> the
>>>>> option to chose just DDL as an option.
>>>>>
>>>>
>>>> You'd still have that ability with my suggestion, just keep validation
>>>> mode to NONE and set hibernate.validator.apply_to_ddl = true.
>>>>
>>>> By "safest mode" above I meant CALLBACK is the right way if you really
>>>> want to make sure that lifecycle validation occurs, or you'll get an
>>>> exception if no BV provider is present. It can't happen that lifecycle
>>>> validation silently, unexpectedly doesn't happen. Hence I prefer it over
>>>> AUTO. And as things stand I can't benefit from constraints in DDL export in
>>>> that case, which is a pity.
>>>>
>>>> But if thats now no longer valid then that changes things.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet <
>>>>> guillaume.smet at gmail.com>
>>>>> wrote:
>>>>>
>>>>
>>>>> > Hi,
>>>>> >
>>>>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <steve at hibernate.org>
>>>>> > wrote:
>>>>> >>
>>>>> >> Is it valid for a user to want *just* DDL-based validation?  How
>>>>> would
>>>>> >> that
>>>>> >> work in Gunnar's request?
>>>>> >>
>>>>> >
>>>>> > From your writings, I suspect I'm the only one with this opinion but
>>>>> my
>>>>> > answer would be: "not if you use Bean Validation annotations".
>>>>> >
>>>>> > If you use BV's @NotNull, you expect BV to validate the input. And
>>>>> you
>>>>> > might want additional DDL in your database to be on the safe side
>>>>> (which
>>>>> > should be the default IMHO).
>>>>> >
>>>>> > --
>>>>> > Guillaume
>>>>> >
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>

From steve at hibernate.org  Wed Feb  7 15:07:04 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 07 Feb 2018 20:07:04 +0000
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CADGJaX9RjPDz_8Kf4G6OhWmnUi8kgxP0sMYnxfkeObmuC3Y=YA@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
	<CALt0+o87_5g9qQGxRNL0msOSz-XCvSTak16mojh635DpzJpqMw@mail.gmail.com>
	<CAFdSV9vgQKpdvNB7aEqa_YB8WSUidS7z77ms-rG6HnujjsPHuA@mail.gmail.com>
	<CADGJaX93zksf7J0XMPGS=3HM=i3SN0FXEUA+Lkv14CxHyUQg3w@mail.gmail.com>
	<CAFdSV9s9xsyb1Cyb=sMDQx7iQzrXO89O+hVLb58wuxTe8GLkkw@mail.gmail.com>
	<CADGJaX-_L8WsjimKQWef+krAgcaRe8T=g-mEC3rpJCOweaFkhg@mail.gmail.com>
	<CAFdSV9sf-urQttXXOmuWtXHJNRC7zkU6nJmSMmyqOAbBu2n=pA@mail.gmail.com>
	<CADGJaX9RjPDz_8Kf4G6OhWmnUi8kgxP0sMYnxfkeObmuC3Y=YA@mail.gmail.com>
Message-ID: <CAFdSV9upe7N+VByAwsmVnSkMkEtvU3Woq+JFaaLeGUrP0EpSjg@mail.gmail.com>

No, I think you are right and `hibernate.validator.apply_to_ddl` should
apply to CALLBACK as well.

On Wed, Feb 7, 2018 at 1:45 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> > How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?
>
> I was referring to the dedicated <validation-mode> element, which is
> restricted to the values AUTO, CALLBACK, NONE in that XSD and which can
> be given at most once [1]. I can see though how it'd work with the
> javax.persistence.validation.mode String property.
>
> So, yeah, technically no change needed. Still quite subtle and very easy
> to miss. Waiting a bit for some more feedback by others, if we decide to
> leave it as is, we need at least to update the HV docs to describe this in
> more depth (we only mention <validation-mode> but not that string property).
>
> [1]
> https://github.com/hibernate/hibernate-orm/blob/master/tooling/metamodel-generator/src/main/xsd/persistence_2_1.xsd#L326-L339
> .
>
> 2018-02-07 20:05 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>
>> How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?
>>
>> Look, I don't mind revisiting a change here.  I really have no horse n
>> this race - this is not even my code originally.  TBH I thought this was
>> code that you did.  So I don't mind changes here if there is a consensus.
>> But let's use real reasons ;)
>>
>> On Wed, Feb 7, 2018 at 12:53 PM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> Right, giving multiple values isn't allowed as per JPA's XSD.
>>>
>>> 2018-02-07 19:44 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> Of course you can.  `mode = CALLBACK,DDL`
>>>>
>>>> You mean that you cannot using single-valued setting
>>>>
>>>> On Wed, Feb 7, 2018 at 12:02 PM Gunnar Morling <gunnar at hibernate.org>
>>>> wrote:
>>>>
>>>>> 2018-02-07 16:08 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>>
>>>>>> Ok, so this is the crux then because it really comes down to whether
>>>>>> you
>>>>>> believe whether it is valid to *only* export the annotation-based
>>>>>> validations as DDL.
>>>>>>
>>>>>> And keep in mind that this code is basically unchanged from all the
>>>>>> way
>>>>>> back to the initial "integrations" with HV.  So back then the
>>>>>> thought-process (not mine, btw) was that yes, that *is* valid - hence
>>>>>> the
>>>>>> option to chose just DDL as an option.
>>>>>>
>>>>>
>>>>> You'd still have that ability with my suggestion, just keep validation
>>>>> mode to NONE and set hibernate.validator.apply_to_ddl = true.
>>>>>
>>>>> By "safest mode" above I meant CALLBACK is the right way if you really
>>>>> want to make sure that lifecycle validation occurs, or you'll get an
>>>>> exception if no BV provider is present. It can't happen that lifecycle
>>>>> validation silently, unexpectedly doesn't happen. Hence I prefer it over
>>>>> AUTO. And as things stand I can't benefit from constraints in DDL export in
>>>>> that case, which is a pity.
>>>>>
>>>>> But if thats now no longer valid then that changes things.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet <
>>>>>> guillaume.smet at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>
>>>>>> > Hi,
>>>>>> >
>>>>>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <steve at hibernate.org
>>>>>> >
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> Is it valid for a user to want *just* DDL-based validation?  How
>>>>>> would
>>>>>> >> that
>>>>>> >> work in Gunnar's request?
>>>>>> >>
>>>>>> >
>>>>>> > From your writings, I suspect I'm the only one with this opinion
>>>>>> but my
>>>>>> > answer would be: "not if you use Bean Validation annotations".
>>>>>> >
>>>>>> > If you use BV's @NotNull, you expect BV to validate the input. And
>>>>>> you
>>>>>> > might want additional DDL in your database to be on the safe side
>>>>>> (which
>>>>>> > should be the default IMHO).
>>>>>> >
>>>>>> > --
>>>>>> > Guillaume
>>>>>> >
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>>
>>>
>

From sanne at hibernate.org  Wed Feb  7 16:51:43 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 7 Feb 2018 21:51:43 +0000
Subject: [hibernate-dev] ORM documentation info hibernate.org
In-Reply-To: <CA+gWKMCqRuv-OHJozJnZRfiWuqSeSZnKMaK5Bo5uX8k0-EKNHw@mail.gmail.com>
References: <CAFdSV9vq7z5vXMCLCMbi56PiSyxCRYm9Ooy24sukiH4UCPth9A@mail.gmail.com>
	<CAL00eSRpcDw-HBRVWioS7bV1wTSpCmDtKSeWtKB=-C77=aLe5A@mail.gmail.com>
	<CA+gWKMCqRuv-OHJozJnZRfiWuqSeSZnKMaK5Bo5uX8k0-EKNHw@mail.gmail.com>
Message-ID: <CAFm4XO2eobnk8Gv-VajF8LJZDCYksukMBR8hrxx+C_Ut0P18uA@mail.gmail.com>

No strong objection, but I quite like it giving a quick shortcut to
switch version.

It's also well visible, making sure people are on the version they
mean to be - which is useful if they "land" directly on a version
documentation from outdated links or search engines.



On 7 February 2018 at 18:38, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> I also think it's redundant now.
>
> Vlad
>
> On Wed, Feb 7, 2018 at 8:36 PM, andrea boriero <andrea at hibernate.org> wrote:
>
>> I think it is not necessary anymore, so +1 for removing it.
>>
>> On 7 February 2018 at 18:32, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> > Now that the hibernate.org infrastructure supports doc versions, should
>> we
>> > remove the version drop-down from the info pages?  Vlad I know you spent
>> > some time adding that; what are your thoughts?
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Feb  7 17:56:25 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 07 Feb 2018 22:56:25 +0000
Subject: [hibernate-dev] ORM documentation info hibernate.org
In-Reply-To: <CAFm4XO2eobnk8Gv-VajF8LJZDCYksukMBR8hrxx+C_Ut0P18uA@mail.gmail.com>
References: <CAFdSV9vq7z5vXMCLCMbi56PiSyxCRYm9Ooy24sukiH4UCPth9A@mail.gmail.com>
	<CAL00eSRpcDw-HBRVWioS7bV1wTSpCmDtKSeWtKB=-C77=aLe5A@mail.gmail.com>
	<CA+gWKMCqRuv-OHJozJnZRfiWuqSeSZnKMaK5Bo5uX8k0-EKNHw@mail.gmail.com>
	<CAFm4XO2eobnk8Gv-VajF8LJZDCYksukMBR8hrxx+C_Ut0P18uA@mail.gmail.com>
Message-ID: <CAFdSV9s0qZLOjVHq2s4+BFJcVXuGWTcp7=xEXe86Xfxm7X5vug@mail.gmail.com>

That's a good thought.

On Wed, Feb 7, 2018, 3:52 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> No strong objection, but I quite like it giving a quick shortcut to
> switch version.
>
> It's also well visible, making sure people are on the version they
> mean to be - which is useful if they "land" directly on a version
> documentation from outdated links or search engines.
>
>
>
> On 7 February 2018 at 18:38, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
> > I also think it's redundant now.
> >
> > Vlad
> >
> > On Wed, Feb 7, 2018 at 8:36 PM, andrea boriero <andrea at hibernate.org>
> wrote:
> >
> >> I think it is not necessary anymore, so +1 for removing it.
> >>
> >> On 7 February 2018 at 18:32, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>
> >> > Now that the hibernate.org infrastructure supports doc versions,
> should
> >> we
> >> > remove the version drop-down from the info pages?  Vlad I know you
> spent
> >> > some time adding that; what are your thoughts?
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From davide at hibernate.org  Thu Feb  8 10:34:44 2018
From: davide at hibernate.org (Davide D'Alto)
Date: Thu, 8 Feb 2018 15:34:44 +0000
Subject: [hibernate-dev] Jenkins updates tomorrow
Message-ID: <CANoTJYOdQPnenEU210ciqWOKn1fULL4Pf=-kxdXWR91DPY90Rg@mail.gmail.com>

Hi,
I'm planning to update Jenkins tomorrow, it should painless but, just in case,
expect possible disruptions.

Cheers,
Davide

From guillaume.smet at gmail.com  Thu Feb  8 10:48:20 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 8 Feb 2018 16:48:20 +0100
Subject: [hibernate-dev] Jenkins updates tomorrow
In-Reply-To: <CANoTJYOdQPnenEU210ciqWOKn1fULL4Pf=-kxdXWR91DPY90Rg@mail.gmail.com>
References: <CANoTJYOdQPnenEU210ciqWOKn1fULL4Pf=-kxdXWR91DPY90Rg@mail.gmail.com>
Message-ID: <CALt0+o9UU1shbsmricETDSazgta7oikZsk-e-AezkfQwfcvYAw@mail.gmail.com>

Thanks for warning and thanks for doing the update!

On Thu, Feb 8, 2018 at 4:34 PM, Davide D'Alto <davide at hibernate.org> wrote:

> Hi,
> I'm planning to update Jenkins tomorrow, it should painless but, just in
> case,
> expect possible disruptions.
>
> Cheers,
> Davide
>

From smarlow at redhat.com  Thu Feb  8 13:30:05 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 8 Feb 2018 13:30:05 -0500
Subject: [hibernate-dev] Could we have a Hibernate 5.3 compatibility
 layer that includes the ORM 5.1 Hibernate Session class
In-Reply-To: <CAFdSV9sjOucZPV2Q92bGJ4qosb_86wCOFwk-cRDo23PbYnVPGA@mail.gmail.com>
References: <CAJtdNN4kj8+AkWdYNMumfGuAoxa9nwwUJvBPgKZgZ1TDLWktQA@mail.gmail.com>
	<CAFm4XO36bfsg_+0BO-rbmRp9JDx2e=9+=s0z8q2WqFaqURXGpQ@mail.gmail.com>
	<CAFdSV9sjOucZPV2Q92bGJ4qosb_86wCOFwk-cRDo23PbYnVPGA@mail.gmail.com>
Message-ID: <d61f7594-1020-760b-de43-027505a0c7f6@redhat.com>



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

From steve at hibernate.org  Thu Feb  8 13:50:12 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 08 Feb 2018 18:50:12 +0000
Subject: [hibernate-dev] Could we have a Hibernate 5.3 compatibility
 layer that includes the ORM 5.1 Hibernate Session class
In-Reply-To: <d61f7594-1020-760b-de43-027505a0c7f6@redhat.com>
References: <CAJtdNN4kj8+AkWdYNMumfGuAoxa9nwwUJvBPgKZgZ1TDLWktQA@mail.gmail.com>
	<CAFm4XO36bfsg_+0BO-rbmRp9JDx2e=9+=s0z8q2WqFaqURXGpQ@mail.gmail.com>
	<CAFdSV9sjOucZPV2Q92bGJ4qosb_86wCOFwk-cRDo23PbYnVPGA@mail.gmail.com>
	<d61f7594-1020-760b-de43-027505a0c7f6@redhat.com>
Message-ID: <CAFdSV9uXqvo=_XUsCNjWLkOBdAL98MVyoBkVOLaVpH7GgKO5nA@mail.gmail.com>

What is meant by "(JPA/native application) compatible with the Hibernate
ORM versions that we include"?

Both 5.3 and 6.0 are JPA 2.2, but 5.1 is JPA 2.1.  Does that mean they
violate that requirement?


On Thu, Feb 8, 2018 at 12:30 PM Scott Marlow <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
>

From smarlow at redhat.com  Thu Feb  8 14:54:34 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 8 Feb 2018 14:54:34 -0500
Subject: [hibernate-dev] Could we have a Hibernate 5.3 compatibility
 layer that includes the ORM 5.1 Hibernate Session class
In-Reply-To: <CAFdSV9uXqvo=_XUsCNjWLkOBdAL98MVyoBkVOLaVpH7GgKO5nA@mail.gmail.com>
References: <CAJtdNN4kj8+AkWdYNMumfGuAoxa9nwwUJvBPgKZgZ1TDLWktQA@mail.gmail.com>
	<CAFm4XO36bfsg_+0BO-rbmRp9JDx2e=9+=s0z8q2WqFaqURXGpQ@mail.gmail.com>
	<CAFdSV9sjOucZPV2Q92bGJ4qosb_86wCOFwk-cRDo23PbYnVPGA@mail.gmail.com>
	<d61f7594-1020-760b-de43-027505a0c7f6@redhat.com>
	<CAFdSV9uXqvo=_XUsCNjWLkOBdAL98MVyoBkVOLaVpH7GgKO5nA@mail.gmail.com>
Message-ID: <b3310652-67fd-d7f8-906b-9d558ae7ccf8@redhat.com>



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
> 

From sanne at hibernate.org  Thu Feb  8 17:08:56 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 8 Feb 2018 22:08:56 +0000
Subject: [hibernate-dev] Could we have a Hibernate 5.3 compatibility
 layer that includes the ORM 5.1 Hibernate Session class
In-Reply-To: <b3310652-67fd-d7f8-906b-9d558ae7ccf8@redhat.com>
References: <CAJtdNN4kj8+AkWdYNMumfGuAoxa9nwwUJvBPgKZgZ1TDLWktQA@mail.gmail.com>
	<CAFm4XO36bfsg_+0BO-rbmRp9JDx2e=9+=s0z8q2WqFaqURXGpQ@mail.gmail.com>
	<CAFdSV9sjOucZPV2Q92bGJ4qosb_86wCOFwk-cRDo23PbYnVPGA@mail.gmail.com>
	<d61f7594-1020-760b-de43-027505a0c7f6@redhat.com>
	<CAFdSV9uXqvo=_XUsCNjWLkOBdAL98MVyoBkVOLaVpH7GgKO5nA@mail.gmail.com>
	<b3310652-67fd-d7f8-906b-9d558ae7ccf8@redhat.com>
Message-ID: <CAFm4XO2dzrXoa9iGv8gq18Z_+QEBHaGMvLQXtxD4S+64To+xNA@mail.gmail.com>

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
>>
>

From gunnar at hibernate.org  Fri Feb  9 10:14:31 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 9 Feb 2018 16:14:31 +0100
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CAFdSV9upe7N+VByAwsmVnSkMkEtvU3Woq+JFaaLeGUrP0EpSjg@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
	<CALt0+o87_5g9qQGxRNL0msOSz-XCvSTak16mojh635DpzJpqMw@mail.gmail.com>
	<CAFdSV9vgQKpdvNB7aEqa_YB8WSUidS7z77ms-rG6HnujjsPHuA@mail.gmail.com>
	<CADGJaX93zksf7J0XMPGS=3HM=i3SN0FXEUA+Lkv14CxHyUQg3w@mail.gmail.com>
	<CAFdSV9s9xsyb1Cyb=sMDQx7iQzrXO89O+hVLb58wuxTe8GLkkw@mail.gmail.com>
	<CADGJaX-_L8WsjimKQWef+krAgcaRe8T=g-mEC3rpJCOweaFkhg@mail.gmail.com>
	<CAFdSV9sf-urQttXXOmuWtXHJNRC7zkU6nJmSMmyqOAbBu2n=pA@mail.gmail.com>
	<CADGJaX9RjPDz_8Kf4G6OhWmnUi8kgxP0sMYnxfkeObmuC3Y=YA@mail.gmail.com>
	<CAFdSV9upe7N+VByAwsmVnSkMkEtvU3Woq+JFaaLeGUrP0EpSjg@mail.gmail.com>
Message-ID: <CADGJaX9=UUt11DGH_+B7gognrS=2=p_qSJVfHFiwZTZrm1x6sg@mail.gmail.com>

Ok, so the constraints would be added to DDL when "hibernate
.validator.apply_to_ddl" is true and validation mode is one of {AUTO,
CALLBACK, DDL}. And they wouldn't be added to the DDL if "hibernate
.validator.apply_to_ddl" is false or validation mode is NONE?

That'd work for me.

2018-02-07 21:07 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> No, I think you are right and `hibernate.validator.apply_to_ddl` should
> apply to CALLBACK as well.
>
> On Wed, Feb 7, 2018 at 1:45 PM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> > How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?
>>
>> I was referring to the dedicated <validation-mode> element, which is
>> restricted to the values AUTO, CALLBACK, NONE in that XSD and which can
>> be given at most once [1]. I can see though how it'd work with the
>> javax.persistence.validation.mode String property.
>>
>> So, yeah, technically no change needed. Still quite subtle and very easy
>> to miss. Waiting a bit for some more feedback by others, if we decide to
>> leave it as is, we need at least to update the HV docs to describe this in
>> more depth (we only mention <validation-mode> but not that string property).
>>
>> [1] https://github.com/hibernate/hibernate-orm/blob/
>> master/tooling/metamodel-generator/src/main/xsd/
>> persistence_2_1.xsd#L326-L339.
>>
>> 2018-02-07 20:05 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?
>>>
>>> Look, I don't mind revisiting a change here.  I really have no horse n
>>> this race - this is not even my code originally.  TBH I thought this was
>>> code that you did.  So I don't mind changes here if there is a consensus.
>>> But let's use real reasons ;)
>>>
>>> On Wed, Feb 7, 2018 at 12:53 PM Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>>
>>>> Right, giving multiple values isn't allowed as per JPA's XSD.
>>>>
>>>> 2018-02-07 19:44 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>
>>>>> Of course you can.  `mode = CALLBACK,DDL`
>>>>>
>>>>> You mean that you cannot using single-valued setting
>>>>>
>>>>> On Wed, Feb 7, 2018 at 12:02 PM Gunnar Morling <gunnar at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> 2018-02-07 16:08 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>>>
>>>>>>> Ok, so this is the crux then because it really comes down to whether
>>>>>>> you
>>>>>>> believe whether it is valid to *only* export the annotation-based
>>>>>>> validations as DDL.
>>>>>>>
>>>>>>> And keep in mind that this code is basically unchanged from all the
>>>>>>> way
>>>>>>> back to the initial "integrations" with HV.  So back then the
>>>>>>> thought-process (not mine, btw) was that yes, that *is* valid -
>>>>>>> hence the
>>>>>>> option to chose just DDL as an option.
>>>>>>>
>>>>>>
>>>>>> You'd still have that ability with my suggestion, just keep
>>>>>> validation mode to NONE and set hibernate.validator.apply_to_ddl =
>>>>>> true.
>>>>>>
>>>>>> By "safest mode" above I meant CALLBACK is the right way if you
>>>>>> really want to make sure that lifecycle validation occurs, or you'll get an
>>>>>> exception if no BV provider is present. It can't happen that lifecycle
>>>>>> validation silently, unexpectedly doesn't happen. Hence I prefer it over
>>>>>> AUTO. And as things stand I can't benefit from constraints in DDL export in
>>>>>> that case, which is a pity.
>>>>>>
>>>>>> But if thats now no longer valid then that changes things.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet <
>>>>>>> guillaume.smet at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>
>>>>>>> > Hi,
>>>>>>> >
>>>>>>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <
>>>>>>> steve at hibernate.org>
>>>>>>> > wrote:
>>>>>>> >>
>>>>>>> >> Is it valid for a user to want *just* DDL-based validation?  How
>>>>>>> would
>>>>>>> >> that
>>>>>>> >> work in Gunnar's request?
>>>>>>> >>
>>>>>>> >
>>>>>>> > From your writings, I suspect I'm the only one with this opinion
>>>>>>> but my
>>>>>>> > answer would be: "not if you use Bean Validation annotations".
>>>>>>> >
>>>>>>> > If you use BV's @NotNull, you expect BV to validate the input. And
>>>>>>> you
>>>>>>> > might want additional DDL in your database to be on the safe side
>>>>>>> (which
>>>>>>> > should be the default IMHO).
>>>>>>> >
>>>>>>> > --
>>>>>>> > Guillaume
>>>>>>> >
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>
>>>>>>
>>>>
>>

From steve at hibernate.org  Fri Feb  9 10:26:17 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 09 Feb 2018 15:26:17 +0000
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CADGJaX9=UUt11DGH_+B7gognrS=2=p_qSJVfHFiwZTZrm1x6sg@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
	<CALt0+o87_5g9qQGxRNL0msOSz-XCvSTak16mojh635DpzJpqMw@mail.gmail.com>
	<CAFdSV9vgQKpdvNB7aEqa_YB8WSUidS7z77ms-rG6HnujjsPHuA@mail.gmail.com>
	<CADGJaX93zksf7J0XMPGS=3HM=i3SN0FXEUA+Lkv14CxHyUQg3w@mail.gmail.com>
	<CAFdSV9s9xsyb1Cyb=sMDQx7iQzrXO89O+hVLb58wuxTe8GLkkw@mail.gmail.com>
	<CADGJaX-_L8WsjimKQWef+krAgcaRe8T=g-mEC3rpJCOweaFkhg@mail.gmail.com>
	<CAFdSV9sf-urQttXXOmuWtXHJNRC7zkU6nJmSMmyqOAbBu2n=pA@mail.gmail.com>
	<CADGJaX9RjPDz_8Kf4G6OhWmnUi8kgxP0sMYnxfkeObmuC3Y=YA@mail.gmail.com>
	<CAFdSV9upe7N+VByAwsmVnSkMkEtvU3Woq+JFaaLeGUrP0EpSjg@mail.gmail.com>
	<CADGJaX9=UUt11DGH_+B7gognrS=2=p_qSJVfHFiwZTZrm1x6sg@mail.gmail.com>
Message-ID: <CAFdSV9ud4agJF2Aq91e_W8HND71CKEvNsU21TEKrirS3AMHJzg@mail.gmail.com>

I think constraints should be exported to the DDL when the mode is DDL or `
hibernate.validator.apply_to_ddl == true`.  I'd personally say that `
hibernate.validator.apply_to_ddl` still works with NONE - as y'all keep
saying, mode is about in-memory callbacks.  In fact because of that, we
should even consider:

   1. droping DDL as an allowable mode
   2. no longer allowing multiple values


Additionally I'd say that AUTO maps to CALLBACK *as long as BV is available
on the classpath.  As I understand it, using CALLBACK mode is supposed to
cause an error when BV is not available on classpath.  AUTO would silently
ignore that.

WDYT?


On Fri, Feb 9, 2018 at 9:14 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Ok, so the constraints would be added to DDL when "hibernate
> .validator.apply_to_ddl" is true and validation mode is one of {AUTO,
> CALLBACK, DDL}. And they wouldn't be added to the DDL if "hibernate
> .validator.apply_to_ddl" is false or validation mode is NONE?
>
> That'd work for me.
>
> 2018-02-07 21:07 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>
>> No, I think you are right and `hibernate.validator.apply_to_ddl` should
>> apply to CALLBACK as well.
>>
>> On Wed, Feb 7, 2018 at 1:45 PM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> > How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?
>>>
>>> I was referring to the dedicated <validation-mode> element, which is
>>> restricted to the values AUTO, CALLBACK, NONE in that XSD and which can
>>> be given at most once [1]. I can see though how it'd work with the
>>> javax.persistence.validation.mode String property.
>>>
>>> So, yeah, technically no change needed. Still quite subtle and very easy
>>> to miss. Waiting a bit for some more feedback by others, if we decide to
>>> leave it as is, we need at least to update the HV docs to describe this in
>>> more depth (we only mention <validation-mode> but not that string property).
>>>
>>> [1]
>>> https://github.com/hibernate/hibernate-orm/blob/master/tooling/metamodel-generator/src/main/xsd/persistence_2_1.xsd#L326-L339
>>> .
>>>
>>> 2018-02-07 20:05 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?
>>>>
>>>> Look, I don't mind revisiting a change here.  I really have no horse n
>>>> this race - this is not even my code originally.  TBH I thought this was
>>>> code that you did.  So I don't mind changes here if there is a consensus.
>>>> But let's use real reasons ;)
>>>>
>>>> On Wed, Feb 7, 2018 at 12:53 PM Gunnar Morling <gunnar at hibernate.org>
>>>> wrote:
>>>>
>>>>> Right, giving multiple values isn't allowed as per JPA's XSD.
>>>>>
>>>>> 2018-02-07 19:44 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>>
>>>>>> Of course you can.  `mode = CALLBACK,DDL`
>>>>>>
>>>>>> You mean that you cannot using single-valued setting
>>>>>>
>>>>>> On Wed, Feb 7, 2018 at 12:02 PM Gunnar Morling <gunnar at hibernate.org>
>>>>>> wrote:
>>>>>>
>>>>>>> 2018-02-07 16:08 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>>>>
>>>>>>>> Ok, so this is the crux then because it really comes down to
>>>>>>>> whether you
>>>>>>>> believe whether it is valid to *only* export the annotation-based
>>>>>>>> validations as DDL.
>>>>>>>>
>>>>>>>> And keep in mind that this code is basically unchanged from all the
>>>>>>>> way
>>>>>>>> back to the initial "integrations" with HV.  So back then the
>>>>>>>> thought-process (not mine, btw) was that yes, that *is* valid -
>>>>>>>> hence the
>>>>>>>> option to chose just DDL as an option.
>>>>>>>>
>>>>>>>
>>>>>>> You'd still have that ability with my suggestion, just keep
>>>>>>> validation mode to NONE and set hibernate.validator.apply_to_ddl =
>>>>>>> true.
>>>>>>>
>>>>>>> By "safest mode" above I meant CALLBACK is the right way if you
>>>>>>> really want to make sure that lifecycle validation occurs, or you'll get an
>>>>>>> exception if no BV provider is present. It can't happen that lifecycle
>>>>>>> validation silently, unexpectedly doesn't happen. Hence I prefer it over
>>>>>>> AUTO. And as things stand I can't benefit from constraints in DDL export in
>>>>>>> that case, which is a pity.
>>>>>>>
>>>>>>> But if thats now no longer valid then that changes things.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet <
>>>>>>>> guillaume.smet at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>
>>>>>>>> > Hi,
>>>>>>>> >
>>>>>>>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <
>>>>>>>> steve at hibernate.org>
>>>>>>>> > wrote:
>>>>>>>> >>
>>>>>>>> >> Is it valid for a user to want *just* DDL-based validation?  How
>>>>>>>> would
>>>>>>>> >> that
>>>>>>>> >> work in Gunnar's request?
>>>>>>>> >>
>>>>>>>> >
>>>>>>>> > From your writings, I suspect I'm the only one with this opinion
>>>>>>>> but my
>>>>>>>> > answer would be: "not if you use Bean Validation annotations".
>>>>>>>> >
>>>>>>>> > If you use BV's @NotNull, you expect BV to validate the input.
>>>>>>>> And you
>>>>>>>> > might want additional DDL in your database to be on the safe side
>>>>>>>> (which
>>>>>>>> > should be the default IMHO).
>>>>>>>> >
>>>>>>>> > --
>>>>>>>> > Guillaume
>>>>>>>> >
>>>>>>>> _______________________________________________
>>>>>>>> hibernate-dev mailing list
>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>
>>>>>>>
>>>>>
>>>
>

From davide at hibernate.org  Fri Feb  9 14:23:33 2018
From: davide at hibernate.org (Davide D'Alto)
Date: Fri, 9 Feb 2018 19:23:33 +0000
Subject: [hibernate-dev] Jenkins updates tomorrow
In-Reply-To: <CALt0+o9UU1shbsmricETDSazgta7oikZsk-e-AezkfQwfcvYAw@mail.gmail.com>
References: <CANoTJYOdQPnenEU210ciqWOKn1fULL4Pf=-kxdXWR91DPY90Rg@mail.gmail.com>
	<CALt0+o9UU1shbsmricETDSazgta7oikZsk-e-AezkfQwfcvYAw@mail.gmail.com>
Message-ID: <CANoTJYPm8ax9kT2iiUpBhXh_aXyn6gM2HgkcCnOLTGKjgoe30A@mail.gmail.com>

I finished the Jenkins upgrades, I'm working on fixing some CSS issues.

If you have some problems with the Jobs, let me know.

Cheers,
Davide

On Thu, Feb 8, 2018 at 3:48 PM, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Thanks for warning and thanks for doing the update!
>
>
> On Thu, Feb 8, 2018 at 4:34 PM, Davide D'Alto <davide at hibernate.org> wrote:
>>
>> Hi,
>> I'm planning to update Jenkins tomorrow, it should painless but, just in
>> case,
>> expect possible disruptions.
>>
>> Cheers,
>> Davide
>
>

From davide at hibernate.org  Fri Feb  9 15:07:13 2018
From: davide at hibernate.org (Davide D'Alto)
Date: Fri, 9 Feb 2018 20:07:13 +0000
Subject: [hibernate-dev] Jenkins updates tomorrow
In-Reply-To: <CANoTJYPm8ax9kT2iiUpBhXh_aXyn6gM2HgkcCnOLTGKjgoe30A@mail.gmail.com>
References: <CANoTJYOdQPnenEU210ciqWOKn1fULL4Pf=-kxdXWR91DPY90Rg@mail.gmail.com>
	<CALt0+o9UU1shbsmricETDSazgta7oikZsk-e-AezkfQwfcvYAw@mail.gmail.com>
	<CANoTJYPm8ax9kT2iiUpBhXh_aXyn6gM2HgkcCnOLTGKjgoe30A@mail.gmail.com>
Message-ID: <CANoTJYMNk=GjPTimbCakSfUvS+3aPbb_h0zaURdXCFgM9m-XoA@mail.gmail.com>

CSS should be fixed as well now.

There was a problem when going to the Nodes page where the buttons
overlapped with the logout link.

Let me know if there is something else weird.

Cheers,
Davide

On Fri, Feb 9, 2018 at 7:23 PM, Davide D'Alto <davide at hibernate.org> wrote:
> I finished the Jenkins upgrades, I'm working on fixing some CSS issues.
>
> If you have some problems with the Jobs, let me know.
>
> Cheers,
> Davide
>
> On Thu, Feb 8, 2018 at 3:48 PM, Guillaume Smet <guillaume.smet at gmail.com> wrote:
>> Thanks for warning and thanks for doing the update!
>>
>>
>> On Thu, Feb 8, 2018 at 4:34 PM, Davide D'Alto <davide at hibernate.org> wrote:
>>>
>>> Hi,
>>> I'm planning to update Jenkins tomorrow, it should painless but, just in
>>> case,
>>> expect possible disruptions.
>>>
>>> Cheers,
>>> Davide
>>
>>

From smarlow at redhat.com  Sat Feb 10 08:32:47 2018
From: smarlow at redhat.com (Scott Marlow)
Date: Sat, 10 Feb 2018 08:32:47 -0500
Subject: [hibernate-dev] Could we have a Hibernate 5.3 compatibility
 layer that includes the ORM 5.1 Hibernate Session class
In-Reply-To: <CAFm4XO2dzrXoa9iGv8gq18Z_+QEBHaGMvLQXtxD4S+64To+xNA@mail.gmail.com>
References: <CAJtdNN4kj8+AkWdYNMumfGuAoxa9nwwUJvBPgKZgZ1TDLWktQA@mail.gmail.com>
	<CAFm4XO36bfsg_+0BO-rbmRp9JDx2e=9+=s0z8q2WqFaqURXGpQ@mail.gmail.com>
	<CAFdSV9sjOucZPV2Q92bGJ4qosb_86wCOFwk-cRDo23PbYnVPGA@mail.gmail.com>
	<d61f7594-1020-760b-de43-027505a0c7f6@redhat.com>
	<CAFdSV9uXqvo=_XUsCNjWLkOBdAL98MVyoBkVOLaVpH7GgKO5nA@mail.gmail.com>
	<b3310652-67fd-d7f8-906b-9d558ae7ccf8@redhat.com>
	<CAFm4XO2dzrXoa9iGv8gq18Z_+QEBHaGMvLQXtxD4S+64To+xNA@mail.gmail.com>
Message-ID: <CAJtdNN7T+JJRvVjv6RDdYnh_Cjg1_KbKhfeX-U=+K_ObjNB+MA@mail.gmail.com>

Hi Sanne,

Good question about what is public API exactly.  In WF modules, we have a
way to mark the entire module as private.  That doesn't help here, and that
would only be a "how" not answering "what extensions".

Having said that, it would be interesting to know the "how" as well.
Perhaps documentation could state what APIs in Hibernate 5.3 that could be
expected to *not* be the same in 6.0+.  This wouldn't include new method
signatures added but instead only existing method signatures removed.  As
well as, existing methods that are going to be repurposed in some way.

I am not sure if this is enough but we could explore this idea if it would
give us enough flexibility to move from 5.3 to 6.0+, later.

Scott

On Feb 8, 2018 5:09 PM, "Sanne Grinovero" <sanne at hibernate.org> wrote:

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
>>
>

From gunnar at hibernate.org  Sat Feb 10 08:55:37 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sat, 10 Feb 2018 14:55:37 +0100
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CAFdSV9ud4agJF2Aq91e_W8HND71CKEvNsU21TEKrirS3AMHJzg@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
	<CALt0+o87_5g9qQGxRNL0msOSz-XCvSTak16mojh635DpzJpqMw@mail.gmail.com>
	<CAFdSV9vgQKpdvNB7aEqa_YB8WSUidS7z77ms-rG6HnujjsPHuA@mail.gmail.com>
	<CADGJaX93zksf7J0XMPGS=3HM=i3SN0FXEUA+Lkv14CxHyUQg3w@mail.gmail.com>
	<CAFdSV9s9xsyb1Cyb=sMDQx7iQzrXO89O+hVLb58wuxTe8GLkkw@mail.gmail.com>
	<CADGJaX-_L8WsjimKQWef+krAgcaRe8T=g-mEC3rpJCOweaFkhg@mail.gmail.com>
	<CAFdSV9sf-urQttXXOmuWtXHJNRC7zkU6nJmSMmyqOAbBu2n=pA@mail.gmail.com>
	<CADGJaX9RjPDz_8Kf4G6OhWmnUi8kgxP0sMYnxfkeObmuC3Y=YA@mail.gmail.com>
	<CAFdSV9upe7N+VByAwsmVnSkMkEtvU3Woq+JFaaLeGUrP0EpSjg@mail.gmail.com>
	<CADGJaX9=UUt11DGH_+B7gognrS=2=p_qSJVfHFiwZTZrm1x6sg@mail.gmail.com>
	<CAFdSV9ud4agJF2Aq91e_W8HND71CKEvNsU21TEKrirS3AMHJzg@mail.gmail.com>
Message-ID: <CADGJaX_8QO2nMs9DAEKEdvDXW=VBNgSKQiJtsEpq51fshxsBPg@mail.gmail.com>

2018-02-09 16:26 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> I think constraints should be exported to the DDL when the mode is DDL or
> `hibernate.validator.apply_to_ddl == true`.  I'd personally say that `
> hibernate.validator.apply_to_ddl` still works with NONE - as y'all keep
> saying, mode is about in-memory callbacks.  In fact because of that, we
> should even consider:
>
>    1. droping DDL as an allowable mode
>    2. no longer allowing multiple values
>
> Sounds great. Exactly what I had in mind :)


> Additionally I'd say that AUTO maps to CALLBACK *as long as BV is
> available on the classpath.  As I understand it, using CALLBACK mode is
> supposed to cause an error when BV is not available on classpath.  AUTO
> would silently ignore that.
>

Exactly. That's why I recommend users to go with CALLBACK over AUTO.

WDYT?
>

Seems we're on the same page. I can do this change, my only question would
be about dropping the DDL enum member and rejecting multiple values (your
1. and 2. above). Should we first (i.e. in 5.3) deprecate the enum member
and log a warning if multiple values are given?


>
> On Fri, Feb 9, 2018 at 9:14 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Ok, so the constraints would be added to DDL when "hibernate
>> .validator.apply_to_ddl" is true and validation mode is one of {AUTO,
>> CALLBACK, DDL}. And they wouldn't be added to the DDL if "hibernate
>> .validator.apply_to_ddl" is false or validation mode is NONE?
>>
>> That'd work for me.
>>
>> 2018-02-07 21:07 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> No, I think you are right and `hibernate.validator.apply_to_ddl` should
>>> apply to CALLBACK as well.
>>>
>>> On Wed, Feb 7, 2018 at 1:45 PM Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>>
>>>> > How is a String "CALLBACK,DDL" considered "multiple values" to an
>>>> XSD?
>>>>
>>>> I was referring to the dedicated <validation-mode> element, which is
>>>> restricted to the values AUTO, CALLBACK, NONE in that XSD and which
>>>> can be given at most once [1]. I can see though how it'd work with the
>>>> javax.persistence.validation.mode String property.
>>>>
>>>> So, yeah, technically no change needed. Still quite subtle and very
>>>> easy to miss. Waiting a bit for some more feedback by others, if we decide
>>>> to leave it as is, we need at least to update the HV docs to describe this
>>>> in more depth (we only mention <validation-mode> but not that string
>>>> property).
>>>>
>>>> [1] https://github.com/hibernate/hibernate-orm/blob/
>>>> master/tooling/metamodel-generator/src/main/xsd/
>>>> persistence_2_1.xsd#L326-L339.
>>>>
>>>> 2018-02-07 20:05 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>
>>>>> How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?
>>>>>
>>>>> Look, I don't mind revisiting a change here.  I really have no horse n
>>>>> this race - this is not even my code originally.  TBH I thought this was
>>>>> code that you did.  So I don't mind changes here if there is a consensus.
>>>>> But let's use real reasons ;)
>>>>>
>>>>> On Wed, Feb 7, 2018 at 12:53 PM Gunnar Morling <gunnar at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> Right, giving multiple values isn't allowed as per JPA's XSD.
>>>>>>
>>>>>> 2018-02-07 19:44 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>>>
>>>>>>> Of course you can.  `mode = CALLBACK,DDL`
>>>>>>>
>>>>>>> You mean that you cannot using single-valued setting
>>>>>>>
>>>>>>> On Wed, Feb 7, 2018 at 12:02 PM Gunnar Morling <gunnar at hibernate.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> 2018-02-07 16:08 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>>>>>
>>>>>>>>> Ok, so this is the crux then because it really comes down to
>>>>>>>>> whether you
>>>>>>>>> believe whether it is valid to *only* export the annotation-based
>>>>>>>>> validations as DDL.
>>>>>>>>>
>>>>>>>>> And keep in mind that this code is basically unchanged from all
>>>>>>>>> the way
>>>>>>>>> back to the initial "integrations" with HV.  So back then the
>>>>>>>>> thought-process (not mine, btw) was that yes, that *is* valid -
>>>>>>>>> hence the
>>>>>>>>> option to chose just DDL as an option.
>>>>>>>>>
>>>>>>>>
>>>>>>>> You'd still have that ability with my suggestion, just keep
>>>>>>>> validation mode to NONE and set hibernate.validator.apply_to_ddl =
>>>>>>>> true.
>>>>>>>>
>>>>>>>> By "safest mode" above I meant CALLBACK is the right way if you
>>>>>>>> really want to make sure that lifecycle validation occurs, or you'll get an
>>>>>>>> exception if no BV provider is present. It can't happen that lifecycle
>>>>>>>> validation silently, unexpectedly doesn't happen. Hence I prefer it over
>>>>>>>> AUTO. And as things stand I can't benefit from constraints in DDL export in
>>>>>>>> that case, which is a pity.
>>>>>>>>
>>>>>>>> But if thats now no longer valid then that changes things.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet <
>>>>>>>>> guillaume.smet at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>
>>>>>>>>> > Hi,
>>>>>>>>> >
>>>>>>>>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <
>>>>>>>>> steve at hibernate.org>
>>>>>>>>> > wrote:
>>>>>>>>> >>
>>>>>>>>> >> Is it valid for a user to want *just* DDL-based validation?
>>>>>>>>> How would
>>>>>>>>> >> that
>>>>>>>>> >> work in Gunnar's request?
>>>>>>>>> >>
>>>>>>>>> >
>>>>>>>>> > From your writings, I suspect I'm the only one with this opinion
>>>>>>>>> but my
>>>>>>>>> > answer would be: "not if you use Bean Validation annotations".
>>>>>>>>> >
>>>>>>>>> > If you use BV's @NotNull, you expect BV to validate the input.
>>>>>>>>> And you
>>>>>>>>> > might want additional DDL in your database to be on the safe
>>>>>>>>> side (which
>>>>>>>>> > should be the default IMHO).
>>>>>>>>> >
>>>>>>>>> > --
>>>>>>>>> > Guillaume
>>>>>>>>> >
>>>>>>>>> _______________________________________________
>>>>>>>>> hibernate-dev mailing list
>>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>

From sanne at hibernate.org  Sat Feb 10 09:51:04 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 10 Feb 2018 14:51:04 +0000
Subject: [hibernate-dev] Could we have a Hibernate 5.3 compatibility
 layer that includes the ORM 5.1 Hibernate Session class
In-Reply-To: <CAJtdNN7T+JJRvVjv6RDdYnh_Cjg1_KbKhfeX-U=+K_ObjNB+MA@mail.gmail.com>
References: <CAJtdNN4kj8+AkWdYNMumfGuAoxa9nwwUJvBPgKZgZ1TDLWktQA@mail.gmail.com>
	<CAFm4XO36bfsg_+0BO-rbmRp9JDx2e=9+=s0z8q2WqFaqURXGpQ@mail.gmail.com>
	<CAFdSV9sjOucZPV2Q92bGJ4qosb_86wCOFwk-cRDo23PbYnVPGA@mail.gmail.com>
	<d61f7594-1020-760b-de43-027505a0c7f6@redhat.com>
	<CAFdSV9uXqvo=_XUsCNjWLkOBdAL98MVyoBkVOLaVpH7GgKO5nA@mail.gmail.com>
	<b3310652-67fd-d7f8-906b-9d558ae7ccf8@redhat.com>
	<CAFm4XO2dzrXoa9iGv8gq18Z_+QEBHaGMvLQXtxD4S+64To+xNA@mail.gmail.com>
	<CAJtdNN7T+JJRvVjv6RDdYnh_Cjg1_KbKhfeX-U=+K_ObjNB+MA@mail.gmail.com>
Message-ID: <CAFm4XO3MUMJNTzmo-XoYtdigcNO=KOVgy+y3g-X_brjiGgLyCQ@mail.gmail.com>

On 10 February 2018 at 13:32, Scott Marlow <smarlow at redhat.com> wrote:
> Hi Sanne,
>
> Good question about what is public API exactly.  In WF modules, we have a
> way to mark the entire module as private.  That doesn't help here, and that
> would only be a "how" not answering "what extensions".
>
> Having said that, it would be interesting to know the "how" as well.
> Perhaps documentation could state what APIs in Hibernate 5.3 that could be
> expected to *not* be the same in 6.0+.  This wouldn't include new method
> signatures added but instead only existing method signatures removed.  As
> well as, existing methods that are going to be repurposed in some way.
>
> I am not sure if this is enough but we could explore this idea if it would
> give us enough flexibility to move from 5.3 to 6.0+, later.

That sounds like a workable idea. Users won't have to wait for 6, and
we can document our intentions.

We've previously used labels such as "experimental" on some APIs but
that hasn't been very effective.
To avoid misunderstandings, I'd prefer an explicit "opt in" for what
we consider stable API. So rather than listing what is *not*
supported, I propose we mark/annotate/document the methods we consider
stable. Would that work for WildFly's needs?

This way we'll likely be very conservative in 5.3 with what we
document to be "stable", providing essentially JPA and a few more
cherry picked essentials; we could then relax restrictions in smaller
steps while the new stuff matures.

I expect some cathegories of users will find our selection too
restrictive, but those more demanding are free to use ORM 5.1 for the
time being and let us know what they'd like to see supported in the
next round.
I also expect the majority of users to not care at all what we
document being stable or not, so everyone will have options ;)

Thanks,
Sanne


>
> Scott
>
> On Feb 8, 2018 5:09 PM, "Sanne Grinovero" <sanne at hibernate.org> wrote:
>
> 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
>>>
>>
>
>

From steve at hibernate.org  Sat Feb 10 10:17:23 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 10 Feb 2018 15:17:23 +0000
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CADGJaX_8QO2nMs9DAEKEdvDXW=VBNgSKQiJtsEpq51fshxsBPg@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
	<CALt0+o87_5g9qQGxRNL0msOSz-XCvSTak16mojh635DpzJpqMw@mail.gmail.com>
	<CAFdSV9vgQKpdvNB7aEqa_YB8WSUidS7z77ms-rG6HnujjsPHuA@mail.gmail.com>
	<CADGJaX93zksf7J0XMPGS=3HM=i3SN0FXEUA+Lkv14CxHyUQg3w@mail.gmail.com>
	<CAFdSV9s9xsyb1Cyb=sMDQx7iQzrXO89O+hVLb58wuxTe8GLkkw@mail.gmail.com>
	<CADGJaX-_L8WsjimKQWef+krAgcaRe8T=g-mEC3rpJCOweaFkhg@mail.gmail.com>
	<CAFdSV9sf-urQttXXOmuWtXHJNRC7zkU6nJmSMmyqOAbBu2n=pA@mail.gmail.com>
	<CADGJaX9RjPDz_8Kf4G6OhWmnUi8kgxP0sMYnxfkeObmuC3Y=YA@mail.gmail.com>
	<CAFdSV9upe7N+VByAwsmVnSkMkEtvU3Woq+JFaaLeGUrP0EpSjg@mail.gmail.com>
	<CADGJaX9=UUt11DGH_+B7gognrS=2=p_qSJVfHFiwZTZrm1x6sg@mail.gmail.com>
	<CAFdSV9ud4agJF2Aq91e_W8HND71CKEvNsU21TEKrirS3AMHJzg@mail.gmail.com>
	<CADGJaX_8QO2nMs9DAEKEdvDXW=VBNgSKQiJtsEpq51fshxsBPg@mail.gmail.com>
Message-ID: <CAFdSV9u8gnTU4jZfaOxO2dT5mWdcj9OQMEhQo0cKb7O9bBHOxg@mail.gmail.com>

Yes, I agree.

On Sat, Feb 10, 2018, 7:55 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> 2018-02-09 16:26 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>
>> I think constraints should be exported to the DDL when the mode is DDL or
>> `hibernate.validator.apply_to_ddl == true`.  I'd personally say that `
>> hibernate.validator.apply_to_ddl` still works with NONE - as y'all keep
>> saying, mode is about in-memory callbacks.  In fact because of that, we
>> should even consider:
>>
>>    1. droping DDL as an allowable mode
>>    2. no longer allowing multiple values
>>
>> Sounds great. Exactly what I had in mind :)
>
>
>> Additionally I'd say that AUTO maps to CALLBACK *as long as BV is
>> available on the classpath.  As I understand it, using CALLBACK mode is
>> supposed to cause an error when BV is not available on classpath.  AUTO
>> would silently ignore that.
>>
>
> Exactly. That's why I recommend users to go with CALLBACK over AUTO.
>
> WDYT?
>>
>
> Seems we're on the same page. I can do this change, my only question would
> be about dropping the DDL enum member and rejecting multiple values (your
> 1. and 2. above). Should we first (i.e. in 5.3) deprecate the enum member
> and log a warning if multiple values are given?
>
>
>>
>> On Fri, Feb 9, 2018 at 9:14 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> Ok, so the constraints would be added to DDL when "hibernate
>>> .validator.apply_to_ddl" is true and validation mode is one of {AUTO,
>>> CALLBACK, DDL}. And they wouldn't be added to the DDL if "hibernate
>>> .validator.apply_to_ddl" is false or validation mode is NONE?
>>>
>>> That'd work for me.
>>>
>>> 2018-02-07 21:07 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> No, I think you are right and `hibernate.validator.apply_to_ddl`
>>>> should apply to CALLBACK as well.
>>>>
>>>> On Wed, Feb 7, 2018 at 1:45 PM Gunnar Morling <gunnar at hibernate.org>
>>>> wrote:
>>>>
>>>>> > How is a String "CALLBACK,DDL" considered "multiple values" to an
>>>>> XSD?
>>>>>
>>>>> I was referring to the dedicated <validation-mode> element, which is
>>>>> restricted to the values AUTO, CALLBACK, NONE in that XSD and which
>>>>> can be given at most once [1]. I can see though how it'd work with the
>>>>> javax.persistence.validation.mode String property.
>>>>>
>>>>> So, yeah, technically no change needed. Still quite subtle and very
>>>>> easy to miss. Waiting a bit for some more feedback by others, if we decide
>>>>> to leave it as is, we need at least to update the HV docs to describe this
>>>>> in more depth (we only mention <validation-mode> but not that string
>>>>> property).
>>>>>
>>>>> [1]
>>>>> https://github.com/hibernate/hibernate-orm/blob/master/tooling/metamodel-generator/src/main/xsd/persistence_2_1.xsd#L326-L339
>>>>> .
>>>>>
>>>>> 2018-02-07 20:05 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>>
>>>>>> How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?
>>>>>>
>>>>>> Look, I don't mind revisiting a change here.  I really have no horse
>>>>>> n this race - this is not even my code originally.  TBH I thought this was
>>>>>> code that you did.  So I don't mind changes here if there is a consensus.
>>>>>> But let's use real reasons ;)
>>>>>>
>>>>>> On Wed, Feb 7, 2018 at 12:53 PM Gunnar Morling <gunnar at hibernate.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Right, giving multiple values isn't allowed as per JPA's XSD.
>>>>>>>
>>>>>>> 2018-02-07 19:44 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>>>>
>>>>>>>> Of course you can.  `mode = CALLBACK,DDL`
>>>>>>>>
>>>>>>>> You mean that you cannot using single-valued setting
>>>>>>>>
>>>>>>>> On Wed, Feb 7, 2018 at 12:02 PM Gunnar Morling <
>>>>>>>> gunnar at hibernate.org> wrote:
>>>>>>>>
>>>>>>>>> 2018-02-07 16:08 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>>>>>>
>>>>>>>>>> Ok, so this is the crux then because it really comes down to
>>>>>>>>>> whether you
>>>>>>>>>> believe whether it is valid to *only* export the annotation-based
>>>>>>>>>> validations as DDL.
>>>>>>>>>>
>>>>>>>>>> And keep in mind that this code is basically unchanged from all
>>>>>>>>>> the way
>>>>>>>>>> back to the initial "integrations" with HV.  So back then the
>>>>>>>>>> thought-process (not mine, btw) was that yes, that *is* valid -
>>>>>>>>>> hence the
>>>>>>>>>> option to chose just DDL as an option.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You'd still have that ability with my suggestion, just keep
>>>>>>>>> validation mode to NONE and set hibernate.validator.apply_to_ddl
>>>>>>>>> = true.
>>>>>>>>>
>>>>>>>>> By "safest mode" above I meant CALLBACK is the right way if you
>>>>>>>>> really want to make sure that lifecycle validation occurs, or you'll get an
>>>>>>>>> exception if no BV provider is present. It can't happen that lifecycle
>>>>>>>>> validation silently, unexpectedly doesn't happen. Hence I prefer it over
>>>>>>>>> AUTO. And as things stand I can't benefit from constraints in DDL export in
>>>>>>>>> that case, which is a pity.
>>>>>>>>>
>>>>>>>>> But if thats now no longer valid then that changes things.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet <
>>>>>>>>>> guillaume.smet at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> > Hi,
>>>>>>>>>> >
>>>>>>>>>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <
>>>>>>>>>> steve at hibernate.org>
>>>>>>>>>> > wrote:
>>>>>>>>>> >>
>>>>>>>>>> >> Is it valid for a user to want *just* DDL-based validation?
>>>>>>>>>> How would
>>>>>>>>>> >> that
>>>>>>>>>> >> work in Gunnar's request?
>>>>>>>>>> >>
>>>>>>>>>> >
>>>>>>>>>> > From your writings, I suspect I'm the only one with this
>>>>>>>>>> opinion but my
>>>>>>>>>> > answer would be: "not if you use Bean Validation annotations".
>>>>>>>>>> >
>>>>>>>>>> > If you use BV's @NotNull, you expect BV to validate the input.
>>>>>>>>>> And you
>>>>>>>>>> > might want additional DDL in your database to be on the safe
>>>>>>>>>> side (which
>>>>>>>>>> > should be the default IMHO).
>>>>>>>>>> >
>>>>>>>>>> > --
>>>>>>>>>> > Guillaume
>>>>>>>>>> >
>>>>>>>>>> _______________________________________________
>>>>>>>>>> hibernate-dev mailing list
>>>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>

From gunnar at hibernate.org  Sun Feb 11 09:03:24 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sun, 11 Feb 2018 15:03:24 +0100
Subject: [hibernate-dev] Support for entities without default constructor
In-Reply-To: <CADGJaX-L6+z1_p9fsUdxbhVqFS1CVv+bvzrZtRPk1eBrOvLCHA@mail.gmail.com>
References: <CA+gWKMBJem2FC+gz_jb42U4tgZ9fmdo2MZ+OMKsbKVQGaMiUoQ@mail.gmail.com>
	<CA+gWKMA7V_-KfrX3+fwxW+f3XVFdUyCxZ6FMa-g0WTrpiqK4GA@mail.gmail.com>
	<CA+gWKMALE8gpv2RsqoCWTXscDiEt0Tg4uKJt1iifi6Q2qydN=A@mail.gmail.com>
	<CA+gWKMC4Tn-URiaBYhK8Tk-EtgC9_UAO=HPHU7_y6pA94Yd37w@mail.gmail.com>
	<CA+gWKMAtx-NdE4x3yZA8bsyNkUdpJmn+7kxvqnFO3h5oQgXhwA@mail.gmail.com>
	<CA+gWKMAfhVGEWsavGtEr8xi_a74tfDN8D8Uwmk8ofgrLE25_cw@mail.gmail.com>
	<CA+gWKMA+fYVcUXvOcT97KzDz1PudcfSt5Vq1RnJr_NC1JkaHbQ@mail.gmail.com>
	<CA+gWKMCa_ueX_H+2sYpUzrXHkhTyRmSMJh9dfKNQXa_BxU4NzQ@mail.gmail.com>
	<CA+gWKMCiHub+bS4TGweU0w0co-Ye9CRKqfeSJs3RZJwe-_Mfug@mail.gmail.com>
	<CA+gWKMDpfYE9CyVdB=Q9===pDKuhf7zkKQfymzySy--s=kftxw@mail.gmail.com>
	<CADGJaX-L6+z1_p9fsUdxbhVqFS1CVv+bvzrZtRPk1eBrOvLCHA@mail.gmail.com>
Message-ID: <CADGJaX8PFdwrwYz2G+Atk9j2kC12j9BHGSaAKKgJDDVCzgqHRA@mail.gmail.com>

> The avoidance of reflective constructor invocation via byte code
generation should be rather simple using ByteBuddy.

Turns out that the ByteBuddy byte code provider already has an
instantiation optimizer doing exactly that [1]. Unfortunately, though, from
what I can say it's never used due to a bug in PojoEntityTuplizer which
ignores the reflection optimizer's instantation optimizer. I've logged
HHH-12284
[2] for that.

--Gunnar

[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/bytecode/internal/bytebuddy/BytecodeProviderImpl.java#L61-L74

[2] https://hibernate.atlassian.net/browse/HHH-12284


2018-02-04 12:30 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:

> I like it, but I think that's two separate concerns:
>
> * using byte code generation to improve performance of entity
> instantiations
> * avoiding the need for entities to have a parameterless constructor,
> emphasising the mandatory properties of an entity (by requiring them as
> constructor parameters) and allowing read-only entities to be truly
> immutable (i.e. with final fields)
>
> Both can be addressed independently.
>
> The latter seems more impactful for developer experience, the need for a
> default constructor has been a long-standing point of criticism often
> raised by DDD-minded folks. As said on Twitter, it'll likely require an
> annotation to mark the "persistence constructor", i.e. the one to be called
> by Hibernate in case there are multiple ones. And we need a mapping between
> parameter names and entity property names. That's "for free" if parameter
> names are part of the byte code as possible with the "-parameters" option
> in javac 8, otherwise some help by the developer is needed.
>
> The avoidance of reflective constructor invocation via byte code
> generation should be rather simple using ByteBuddy.
>
> --Gunnar
>
> 2018-02-04 8:34 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
>
>> For anyone interested, Josh Long tell more about why they took this
>> approach where they inject the default constructor:
>>
>> https://twitter.com/starbuxman/status/960049941916696578
>>
>> Rafael Winterhaler shows that this can be easily done with Byte Buddy
>> which
>> we already used before:
>>
>> https://twitter.com/rafaelcodes/status/959892398997458946
>>
>> If we can prove that it's indeed significantly faster than using Java
>> Reflection to build entities,
>> I think we should think about taking this approach as well.
>>
>> What do you think of this?
>>
>> Vlad
>>
>> On Sat, Feb 3, 2018 at 5:03 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> > I realized that we could allow users to define entities without a
>> default
>> > constructor.
>> >
>> > For Kotlin, which supportsdefault values, this could be beneficial.
>> >
>> > There is some info about how we could do that in this using Objenesis in
>> > the following Spring issue:
>> >
>> > https://jira.spring.io/plugins/servlet/mobile#issue/SPR-10594
>> >
>> > Let me know what you think,
>> > Vlad
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Sun Feb 11 12:01:21 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 11 Feb 2018 17:01:21 +0000
Subject: [hibernate-dev] Make JpaCompliance available earlier
Message-ID: <CAFdSV9swKNYtgGkNCCtx6cGafm6sPvZSDEXyhe+f8AwFc96iBg@mail.gmail.com>

I am working on HHH-12282.  I was thinking that the best solution would be
to check this setting at the time when Join#setOptional is called.  The
reason being to centralize the place that this check needs to be done.  I
can do it inside the persister as it consumes the Join, but that leads to
duplicated code.

But in order to fix in the way I just described, we would have to make
JpaCompliance available earlier in the boot process (currently it is built
as part of SessionFactoryOptions/Builder).

WDYT?

From gunnar at hibernate.org  Mon Feb 12 03:13:41 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 12 Feb 2018 09:13:41 +0100
Subject: [hibernate-dev] ORM DDL doesn't reflect BV constraints with
 validation mode CALLBACK
In-Reply-To: <CAFdSV9u8gnTU4jZfaOxO2dT5mWdcj9OQMEhQo0cKb7O9bBHOxg@mail.gmail.com>
References: <CADGJaX-+MEM_xprj+OOS5X3L5HhAJ0udehYbOHzG7q8r0DQNrg@mail.gmail.com>
	<b94db11c-2145-93c9-a854-f9dfc9aad698@hibernate.org>
	<CAFdSV9tZrBLTxPp0NibK2imsiwaQfHsro4nPxNrcjQ2Q1_nmtA@mail.gmail.com>
	<CADGJaX-MUiVS6fW21Z85wp0pSv_1-94ZY8DXqZR4VF4Ur0b6Dg@mail.gmail.com>
	<CAFdSV9v05V1abCQv-dJrqPXBGkh8BAtmh4ofHp_p6ZBS-RpYhQ@mail.gmail.com>
	<CAFm4XO15ZSCjzg6aQkChz5-HtgQhhEEfjEC5T8D+Rx4EY+Bwhw@mail.gmail.com>
	<CAFdSV9ue__ZouwUtyecpvJDp8jpB2McKSqQWrjewucPSyzpwYA@mail.gmail.com>
	<CAFm4XO1Rex7Womg0+XEfG3gmSZCxMfaFy9SUfNpAiSY7dz21iQ@mail.gmail.com>
	<CAFdSV9uaB_iTRj7hskunrgApnd_Ek98nB_GPkRv0ZROBTcbWvg@mail.gmail.com>
	<CALt0+o87_5g9qQGxRNL0msOSz-XCvSTak16mojh635DpzJpqMw@mail.gmail.com>
	<CAFdSV9vgQKpdvNB7aEqa_YB8WSUidS7z77ms-rG6HnujjsPHuA@mail.gmail.com>
	<CADGJaX93zksf7J0XMPGS=3HM=i3SN0FXEUA+Lkv14CxHyUQg3w@mail.gmail.com>
	<CAFdSV9s9xsyb1Cyb=sMDQx7iQzrXO89O+hVLb58wuxTe8GLkkw@mail.gmail.com>
	<CADGJaX-_L8WsjimKQWef+krAgcaRe8T=g-mEC3rpJCOweaFkhg@mail.gmail.com>
	<CAFdSV9sf-urQttXXOmuWtXHJNRC7zkU6nJmSMmyqOAbBu2n=pA@mail.gmail.com>
	<CADGJaX9RjPDz_8Kf4G6OhWmnUi8kgxP0sMYnxfkeObmuC3Y=YA@mail.gmail.com>
	<CAFdSV9upe7N+VByAwsmVnSkMkEtvU3Woq+JFaaLeGUrP0EpSjg@mail.gmail.com>
	<CADGJaX9=UUt11DGH_+B7gognrS=2=p_qSJVfHFiwZTZrm1x6sg@mail.gmail.com>
	<CAFdSV9ud4agJF2Aq91e_W8HND71CKEvNsU21TEKrirS3AMHJzg@mail.gmail.com>
	<CADGJaX_8QO2nMs9DAEKEdvDXW=VBNgSKQiJtsEpq51fshxsBPg@mail.gmail.com>
	<CAFdSV9u8gnTU4jZfaOxO2dT5mWdcj9OQMEhQo0cKb7O9bBHOxg@mail.gmail.com>
Message-ID: <CADGJaX9RHWnxgYHuiBnuPPq96-1xG7yR2+JjmTpUJ_STF3jrMg@mail.gmail.com>

Excellent; I've filed https://hibernate.atlassian.net/browse/HHH-12287 for
this. I'll try and find some time to provide a PR.

What's the cut-off date for 5.3?

2018-02-10 16:17 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> Yes, I agree.
>
> On Sat, Feb 10, 2018, 7:55 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> 2018-02-09 16:26 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> I think constraints should be exported to the DDL when the mode is DDL
>>> or `hibernate.validator.apply_to_ddl == true`.  I'd personally say that
>>> `hibernate.validator.apply_to_ddl` still works with NONE - as y'all
>>> keep saying, mode is about in-memory callbacks.  In fact because of that,
>>> we should even consider:
>>>
>>>    1. droping DDL as an allowable mode
>>>    2. no longer allowing multiple values
>>>
>>> Sounds great. Exactly what I had in mind :)
>>
>>
>>> Additionally I'd say that AUTO maps to CALLBACK *as long as BV is
>>> available on the classpath.  As I understand it, using CALLBACK mode is
>>> supposed to cause an error when BV is not available on classpath.  AUTO
>>> would silently ignore that.
>>>
>>
>> Exactly. That's why I recommend users to go with CALLBACK over AUTO.
>>
>> WDYT?
>>>
>>
>> Seems we're on the same page. I can do this change, my only question
>> would be about dropping the DDL enum member and rejecting multiple values
>> (your 1. and 2. above). Should we first (i.e. in 5.3) deprecate the enum
>> member and log a warning if multiple values are given?
>>
>>
>>>
>>> On Fri, Feb 9, 2018 at 9:14 AM Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>>
>>>> Ok, so the constraints would be added to DDL when "hibernate
>>>> .validator.apply_to_ddl" is true and validation mode is one of {AUTO,
>>>> CALLBACK, DDL}. And they wouldn't be added to the DDL if "hibernate
>>>> .validator.apply_to_ddl" is false or validation mode is NONE?
>>>>
>>>> That'd work for me.
>>>>
>>>> 2018-02-07 21:07 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>
>>>>> No, I think you are right and `hibernate.validator.apply_to_ddl`
>>>>> should apply to CALLBACK as well.
>>>>>
>>>>> On Wed, Feb 7, 2018 at 1:45 PM Gunnar Morling <gunnar at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> > How is a String "CALLBACK,DDL" considered "multiple values" to an
>>>>>> XSD?
>>>>>>
>>>>>> I was referring to the dedicated <validation-mode> element, which is
>>>>>> restricted to the values AUTO, CALLBACK, NONE in that XSD and which
>>>>>> can be given at most once [1]. I can see though how it'd work with the
>>>>>> javax.persistence.validation.mode String property.
>>>>>>
>>>>>> So, yeah, technically no change needed. Still quite subtle and very
>>>>>> easy to miss. Waiting a bit for some more feedback by others, if we decide
>>>>>> to leave it as is, we need at least to update the HV docs to describe this
>>>>>> in more depth (we only mention <validation-mode> but not that string
>>>>>> property).
>>>>>>
>>>>>> [1] https://github.com/hibernate/hibernate-orm/blob/
>>>>>> master/tooling/metamodel-generator/src/main/xsd/
>>>>>> persistence_2_1.xsd#L326-L339.
>>>>>>
>>>>>> 2018-02-07 20:05 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>>>
>>>>>>> How is a String "CALLBACK,DDL" considered "multiple values" to an
>>>>>>> XSD?
>>>>>>>
>>>>>>> Look, I don't mind revisiting a change here.  I really have no horse
>>>>>>> n this race - this is not even my code originally.  TBH I thought this was
>>>>>>> code that you did.  So I don't mind changes here if there is a consensus.
>>>>>>> But let's use real reasons ;)
>>>>>>>
>>>>>>> On Wed, Feb 7, 2018 at 12:53 PM Gunnar Morling <gunnar at hibernate.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Right, giving multiple values isn't allowed as per JPA's XSD.
>>>>>>>>
>>>>>>>> 2018-02-07 19:44 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>>>>>
>>>>>>>>> Of course you can.  `mode = CALLBACK,DDL`
>>>>>>>>>
>>>>>>>>> You mean that you cannot using single-valued setting
>>>>>>>>>
>>>>>>>>> On Wed, Feb 7, 2018 at 12:02 PM Gunnar Morling <
>>>>>>>>> gunnar at hibernate.org> wrote:
>>>>>>>>>
>>>>>>>>>> 2018-02-07 16:08 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>>>>>>>
>>>>>>>>>>> Ok, so this is the crux then because it really comes down to
>>>>>>>>>>> whether you
>>>>>>>>>>> believe whether it is valid to *only* export the annotation-based
>>>>>>>>>>> validations as DDL.
>>>>>>>>>>>
>>>>>>>>>>> And keep in mind that this code is basically unchanged from all
>>>>>>>>>>> the way
>>>>>>>>>>> back to the initial "integrations" with HV.  So back then the
>>>>>>>>>>> thought-process (not mine, btw) was that yes, that *is* valid -
>>>>>>>>>>> hence the
>>>>>>>>>>> option to chose just DDL as an option.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You'd still have that ability with my suggestion, just keep
>>>>>>>>>> validation mode to NONE and set hibernate.validator.apply_to_ddl
>>>>>>>>>> = true.
>>>>>>>>>>
>>>>>>>>>> By "safest mode" above I meant CALLBACK is the right way if you
>>>>>>>>>> really want to make sure that lifecycle validation occurs, or you'll get an
>>>>>>>>>> exception if no BV provider is present. It can't happen that lifecycle
>>>>>>>>>> validation silently, unexpectedly doesn't happen. Hence I prefer it over
>>>>>>>>>> AUTO. And as things stand I can't benefit from constraints in DDL export in
>>>>>>>>>> that case, which is a pity.
>>>>>>>>>>
>>>>>>>>>> But if thats now no longer valid then that changes things.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet <
>>>>>>>>>>> guillaume.smet at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> > Hi,
>>>>>>>>>>> >
>>>>>>>>>>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <
>>>>>>>>>>> steve at hibernate.org>
>>>>>>>>>>> > wrote:
>>>>>>>>>>> >>
>>>>>>>>>>> >> Is it valid for a user to want *just* DDL-based validation?
>>>>>>>>>>> How would
>>>>>>>>>>> >> that
>>>>>>>>>>> >> work in Gunnar's request?
>>>>>>>>>>> >>
>>>>>>>>>>> >
>>>>>>>>>>> > From your writings, I suspect I'm the only one with this
>>>>>>>>>>> opinion but my
>>>>>>>>>>> > answer would be: "not if you use Bean Validation annotations".
>>>>>>>>>>> >
>>>>>>>>>>> > If you use BV's @NotNull, you expect BV to validate the input.
>>>>>>>>>>> And you
>>>>>>>>>>> > might want additional DDL in your database to be on the safe
>>>>>>>>>>> side (which
>>>>>>>>>>> > should be the default IMHO).
>>>>>>>>>>> >
>>>>>>>>>>> > --
>>>>>>>>>>> > Guillaume
>>>>>>>>>>> >
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> hibernate-dev mailing list
>>>>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>

From andrea at hibernate.org  Mon Feb 12 08:01:21 2018
From: andrea at hibernate.org (andrea boriero)
Date: Mon, 12 Feb 2018 13:01:21 +0000
Subject: [hibernate-dev] Make JpaCompliance available earlier
In-Reply-To: <CAFdSV9swKNYtgGkNCCtx6cGafm6sPvZSDEXyhe+f8AwFc96iBg@mail.gmail.com>
References: <CAFdSV9swKNYtgGkNCCtx6cGafm6sPvZSDEXyhe+f8AwFc96iBg@mail.gmail.com>
Message-ID: <CAL00eSTSO062v09egTHvUDxkA4CyZEWKb=ruJ++A1BU0ikYjmw@mail.gmail.com>

I think it is fine, may be you can only get just the value of the specific
setting instead of creating the entire JpaCompliance object.

On 11 February 2018 at 17:01, Steve Ebersole <steve at hibernate.org> wrote:

> I am working on HHH-12282.  I was thinking that the best solution would be
> to check this setting at the time when Join#setOptional is called.  The
> reason being to centralize the place that this check needs to be done.  I
> can do it inside the persister as it consumes the Join, but that leads to
> duplicated code.
>
> But in order to fix in the way I just described, we would have to make
> JpaCompliance available earlier in the boot process (currently it is built
> as part of SessionFactoryOptions/Builder).
>
> WDYT?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Mon Feb 12 11:55:32 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 12 Feb 2018 16:55:32 +0000
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for
	all published modules
Message-ID: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>

Picking automatic module names for Hibernate Search isn't going to be
straight-forward as our two main jars (hibernate-search-engine &
hibernate-search-orm) suffer from split package among them.

We can't really fix the split package problem without breaking all
users, so if we want to consider that, we can debate it but that will
need to happen at another round as we're doing a minor release, so
let's focus on:
 # Which names to pick
 # Should we pick the names at all
 # Which modules should have a name

For a great background on the possible strategies and pitfalls I
recommend reading Stephen Colebourne's blog on this subject [1].
He persuaded me there are good reasons to use the "reverse DNS, the
top level package", however since we have the split package problem we
can't simply go with that.

Still, we can respect the principles he recommends with a small
variation. It's fair to assume that the `org.hibernate.search` prefix
is "ours"; since the nature of the suggestion is focused on making
sure there are no misunderstandings in the community about which names
you can choose - as there is no central authority making sure module
names aren't clashing - we should be fine within Hibernate projects
with any `org.hibernate.X` prefix, as long as we coordinate and reach
an agreement on this list.

So, I propose we use:

Engine module:
 - org.hibernate.search.engine

ORM integration module:
 - org.hibernate.search.orm

JGroups, JMS backends:
  [ no automatic module name ? Excepting some "guidelines" in the JMS
module, these are not public API so nobody would benefit from it -
also we think we might want to phase out the name "backend" in the
future ]

Elasticsearch integration module [hibernate-search-elasticsearch.jar]:
 - org.hibernate.search.elasticsearch

Elasticsearch / AWS security integration:
 [ no automatic module name: no public API ]

Serialization / Avro
 [ no automatic module name: no public API ]

WDYT?

We could also pick names for the ones which I've listed as "no public
API" but I see no point: as we're only assigning an "Automatic Module
Name" we won't be able to explicitly state that the other modules
depend on these. So nobody will use them, and things are a bit in flux
anyway in this area because of Hibernate Search 6 plans.

Another optional altogether: since we have split packages which we'll
have to resolve before we can actually transform these into fully
fledged modules, I think an acceptable position is also to say we
won't be publishing any automatic module name yet. Personally I'm
inclined to go with the names suggested above, at least some others
can start making baby steps, even if it's not all there.

# What I don't like:
For one, that the typical application will need to import both
`org.hibernate.search.engine` and `org.hibernate.search.orm`, and
likely more as well (e.g. Elasticsearch API, Lucene API module is
coming, ..).

Maybe similar to BOM's today we could publish a module which
statically imports multiple of these, that could be nicer to use but
we risk needing to publish (and document) one for each of a selection
of combinations. So let's not start with such things yet.

Thanks,
Sanne

[1] http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html

From gunnar at hibernate.org  Mon Feb 12 13:00:44 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 12 Feb 2018 19:00:44 +0100
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
Message-ID: <CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>

2018-02-12 17:55 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> Picking automatic module names for Hibernate Search isn't going to be
> straight-forward as our two main jars (hibernate-search-engine &
> hibernate-search-orm) suffer from split package among them.
>
> We can't really fix the split package problem without breaking all
> users, so if we want to consider that, we can debate it but that will
> need to happen at another round as we're doing a minor release, so
> let's focus on:
>  # Which names to pick
>  # Should we pick the names at all
>  # Which modules should have a name
>
> For a great background on the possible strategies and pitfalls I
> recommend reading Stephen Colebourne's blog on this subject [1].
> He persuaded me there are good reasons to use the "reverse DNS, the
> top level package", however since we have the split package problem we
> can't simply go with that.
>
> Still, we can respect the principles he recommends with a small
> variation. It's fair to assume that the `org.hibernate.search` prefix
> is "ours"; since the nature of the suggestion is focused on making
> sure there are no misunderstandings in the community about which names
> you can choose - as there is no central authority making sure module
> names aren't clashing - we should be fine within Hibernate projects
> with any `org.hibernate.X` prefix, as long as we coordinate and reach
> an agreement on this list.
>
> So, I propose we use:
>
> Engine module:
>  - org.hibernate.search.engine
>
> ORM integration module:
>  - org.hibernate.search.orm
>
> Those names sound good to me.


> JGroups, JMS backends:
>   [ no automatic module name ? Excepting some "guidelines" in the JMS
> module, these are not public API so nobody would benefit from it -
> also we think we might want to phase out the name "backend" in the
> future ]

Elasticsearch integration module [hibernate-search-elasticsearch.jar]:
>  - org.hibernate.search.elasticsearch
>
> Elasticsearch / AWS security integration:
>  [ no automatic module name: no public API ]
>
> Serialization / Avro
>  [ no automatic module name: no public API ]
>
> WDYT?
>

The user may still need to reference those modules when launching a
modularized application. Also if they don't directly declare say the JMS
backend as a dependence of their own module, they'd still have to specify
it via --add-modules, so to resolve these additional modules and add them
to the module graph. Hence I'd declare automatic module names for these,
too.


>
> We could also pick names for the ones which I've listed as "no public
> API" but I see no point: as we're only assigning an "Automatic Module
> Name" we won't be able to explicitly state that the other modules
> depend on these. So nobody will use them, and things are a bit in flux
> anyway in this area because of Hibernate Search 6 plans.
>

I don't fully understand this paragraph.

>
> Another optional altogether: since we have split packages which we'll
> have to resolve before we can actually transform these into fully
> fledged modules, I think an acceptable position is also to say we
> won't be publishing any automatic module name yet. Personally I'm
> inclined to go with the names suggested above, at least some others
> can start making baby steps, even if it's not all there.
>

IMO automatic module names should only be declared after at least some
basic vetting that these modules will actually work when used as modules.
If that's not the case, I wouldn't add these headers, as users rightfully
may consider their presence as endorsement of using them as modules.

That said, I can't seem to find split packages between engine and orm. In
fact I can launch an application with both of them on the module path just
fine. So there may be no problem actually?


> # What I don't like:
> For one, that the typical application will need to import both
> `org.hibernate.search.engine` and `org.hibernate.search.orm`, and
> likely more as well (e.g. Elasticsearch API, Lucene API module is
> coming, ..).
>

I'm not exactly sure what you mean by "import" here. But if it's about the
user having to declare dependences in their module descriptor to
o.h.s.engine and o.h.s.orm modules, you may consider to make the former a
transitive dependence of the latter once you add actual module descriptors:

    module org.hibernate.search.orm {
        requires transitive org.hibernate.search.engine;
        ...
    }

That way the user just has to add declare the dependence to o.h.s.orm.
That's definitely suitable if APIs in o.h.s.orm use types from engine in
their public API signatures.


> Maybe similar to BOM's today we could publish a module which
> statically imports multiple of these, that could be nicer to use but
> we risk needing to publish (and document) one for each of a selection
> of combinations. So let's not start with such things yet.
>
> Thanks,
> Sanne
>
> [1] http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Mon Feb 12 13:28:07 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 12 Feb 2018 18:28:07 +0000
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
	<CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
Message-ID: <CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>

On 12 February 2018 at 18:00, Gunnar Morling <gunnar at hibernate.org> wrote:
>
>
> 2018-02-12 17:55 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> Picking automatic module names for Hibernate Search isn't going to be
>> straight-forward as our two main jars (hibernate-search-engine &
>> hibernate-search-orm) suffer from split package among them.
>>
>> We can't really fix the split package problem without breaking all
>> users, so if we want to consider that, we can debate it but that will
>> need to happen at another round as we're doing a minor release, so
>> let's focus on:
>>  # Which names to pick
>>  # Should we pick the names at all
>>  # Which modules should have a name
>>
>> For a great background on the possible strategies and pitfalls I
>> recommend reading Stephen Colebourne's blog on this subject [1].
>> He persuaded me there are good reasons to use the "reverse DNS, the
>> top level package", however since we have the split package problem we
>> can't simply go with that.
>>
>> Still, we can respect the principles he recommends with a small
>> variation. It's fair to assume that the `org.hibernate.search` prefix
>> is "ours"; since the nature of the suggestion is focused on making
>> sure there are no misunderstandings in the community about which names
>> you can choose - as there is no central authority making sure module
>> names aren't clashing - we should be fine within Hibernate projects
>> with any `org.hibernate.X` prefix, as long as we coordinate and reach
>> an agreement on this list.
>>
>> So, I propose we use:
>>
>> Engine module:
>>  - org.hibernate.search.engine
>>
>> ORM integration module:
>>  - org.hibernate.search.orm
>>
> Those names sound good to me.
>
>>
>> JGroups, JMS backends:
>>   [ no automatic module name ? Excepting some "guidelines" in the JMS
>> module, these are not public API so nobody would benefit from it -
>> also we think we might want to phase out the name "backend" in the
>> future ]
>>
>> Elasticsearch integration module [hibernate-search-elasticsearch.jar]:
>>  - org.hibernate.search.elasticsearch
>>
>> Elasticsearch / AWS security integration:
>>  [ no automatic module name: no public API ]
>>
>> Serialization / Avro
>>  [ no automatic module name: no public API ]
>>
>> WDYT?
>
>
> The user may still need to reference those modules when launching a
> modularized application. Also if they don't directly declare say the JMS
> backend as a dependence of their own module, they'd still have to specify it
> via --add-modules, so to resolve these additional modules and add them to
> the module graph. Hence I'd declare automatic module names for these, too.

Good point, I had not thought that our modules wouldn't be able to
load other extensions from classpath.

>> We could also pick names for the ones which I've listed as "no public
>> API" but I see no point: as we're only assigning an "Automatic Module
>> Name" we won't be able to explicitly state that the other modules
>> depend on these. So nobody will use them, and things are a bit in flux
>> anyway in this area because of Hibernate Search 6 plans.
>
>
> I don't fully understand this paragraph.

You mostly invalidated it with the previous comment, but what I meant
is that we can't have the `org.hibernate.search.engine` declare a
dependency on any implementation module, as we're not adding a
module-info definition.

>> Another optional altogether: since we have split packages which we'll
>> have to resolve before we can actually transform these into fully
>> fledged modules, I think an acceptable position is also to say we
>> won't be publishing any automatic module name yet. Personally I'm
>> inclined to go with the names suggested above, at least some others
>> can start making baby steps, even if it's not all there.
>
>
> IMO automatic module names should only be declared after at least some basic
> vetting that these modules will actually work when used as modules. If
> that's not the case, I wouldn't add these headers, as users rightfully may
> consider their presence as endorsement of using them as modules.
>
> That said, I can't seem to find split packages between engine and orm. In
> fact I can launch an application with both of them on the module path just
> fine. So there may be no problem actually?

Interesting, I'm pretty sure we had some. We had several issues
resolved over time to resolve them, I never realized we might have
completed them all. The "line" defining what belongs where is still
blurry though, we should make sure this won't have future regressions.

I'll see if we can produce fully fledged module-info descriptors then :)

>
>>
>> # What I don't like:
>> For one, that the typical application will need to import both
>> `org.hibernate.search.engine` and `org.hibernate.search.orm`, and
>> likely more as well (e.g. Elasticsearch API, Lucene API module is
>> coming, ..).
>
>
> I'm not exactly sure what you mean by "import" here. But if it's about the
> user having to declare dependences in their module descriptor to
> o.h.s.engine and o.h.s.orm modules, you may consider to make the former a
> transitive dependence of the latter once you add actual module descriptors:
>
>     module org.hibernate.search.orm {
>         requires transitive org.hibernate.search.engine;
>         ...
>     }
>
> That way the user just has to add declare the dependence to o.h.s.orm.
> That's definitely suitable if APIs in o.h.s.orm use types from engine in
> their public API signatures.

+1 that's the better option.

My thought was about automatic module names though, but totally
irrelevant if we go for full modules.

Thanks,
Sanne

>
>>
>> Maybe similar to BOM's today we could publish a module which
>> statically imports multiple of these, that could be nicer to use but
>> we risk needing to publish (and document) one for each of a selection
>> of combinations. So let's not start with such things yet.
>>
>> Thanks,
>> Sanne
>>
>> [1] http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From sanne at hibernate.org  Mon Feb 12 13:30:17 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 12 Feb 2018 18:30:17 +0000
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
	<CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
	<CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
Message-ID: <CAFm4XO2uE0Rz5OBQ1h52yn2ooAazPoEQrZ+si8DKYY-LsgJJww@mail.gmail.com>

On 12 February 2018 at 18:28, Sanne Grinovero <sanne at hibernate.org> wrote:
> On 12 February 2018 at 18:00, Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>>
>> 2018-02-12 17:55 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>>
>>> Picking automatic module names for Hibernate Search isn't going to be
>>> straight-forward as our two main jars (hibernate-search-engine &
>>> hibernate-search-orm) suffer from split package among them.
>>>
>>> We can't really fix the split package problem without breaking all
>>> users, so if we want to consider that, we can debate it but that will
>>> need to happen at another round as we're doing a minor release, so
>>> let's focus on:
>>>  # Which names to pick
>>>  # Should we pick the names at all
>>>  # Which modules should have a name
>>>
>>> For a great background on the possible strategies and pitfalls I
>>> recommend reading Stephen Colebourne's blog on this subject [1].
>>> He persuaded me there are good reasons to use the "reverse DNS, the
>>> top level package", however since we have the split package problem we
>>> can't simply go with that.
>>>
>>> Still, we can respect the principles he recommends with a small
>>> variation. It's fair to assume that the `org.hibernate.search` prefix
>>> is "ours"; since the nature of the suggestion is focused on making
>>> sure there are no misunderstandings in the community about which names
>>> you can choose - as there is no central authority making sure module
>>> names aren't clashing - we should be fine within Hibernate projects
>>> with any `org.hibernate.X` prefix, as long as we coordinate and reach
>>> an agreement on this list.
>>>
>>> So, I propose we use:
>>>
>>> Engine module:
>>>  - org.hibernate.search.engine
>>>
>>> ORM integration module:
>>>  - org.hibernate.search.orm
>>>
>> Those names sound good to me.
>>
>>>
>>> JGroups, JMS backends:
>>>   [ no automatic module name ? Excepting some "guidelines" in the JMS
>>> module, these are not public API so nobody would benefit from it -
>>> also we think we might want to phase out the name "backend" in the
>>> future ]
>>>
>>> Elasticsearch integration module [hibernate-search-elasticsearch.jar]:
>>>  - org.hibernate.search.elasticsearch
>>>
>>> Elasticsearch / AWS security integration:
>>>  [ no automatic module name: no public API ]
>>>
>>> Serialization / Avro
>>>  [ no automatic module name: no public API ]
>>>
>>> WDYT?
>>
>>
>> The user may still need to reference those modules when launching a
>> modularized application. Also if they don't directly declare say the JMS
>> backend as a dependence of their own module, they'd still have to specify it
>> via --add-modules, so to resolve these additional modules and add them to
>> the module graph. Hence I'd declare automatic module names for these, too.
>
> Good point, I had not thought that our modules wouldn't be able to
> load other extensions from classpath.
>
>>> We could also pick names for the ones which I've listed as "no public
>>> API" but I see no point: as we're only assigning an "Automatic Module
>>> Name" we won't be able to explicitly state that the other modules
>>> depend on these. So nobody will use them, and things are a bit in flux
>>> anyway in this area because of Hibernate Search 6 plans.
>>
>>
>> I don't fully understand this paragraph.
>
> You mostly invalidated it with the previous comment, but what I meant
> is that we can't have the `org.hibernate.search.engine` declare a
> dependency on any implementation module, as we're not adding a
> module-info definition.
>
>>> Another optional altogether: since we have split packages which we'll
>>> have to resolve before we can actually transform these into fully
>>> fledged modules, I think an acceptable position is also to say we
>>> won't be publishing any automatic module name yet. Personally I'm
>>> inclined to go with the names suggested above, at least some others
>>> can start making baby steps, even if it's not all there.
>>
>>
>> IMO automatic module names should only be declared after at least some basic
>> vetting that these modules will actually work when used as modules. If
>> that's not the case, I wouldn't add these headers, as users rightfully may
>> consider their presence as endorsement of using them as modules.
>>
>> That said, I can't seem to find split packages between engine and orm. In
>> fact I can launch an application with both of them on the module path just
>> fine. So there may be no problem actually?
>
> Interesting, I'm pretty sure we had some. We had several issues
> resolved over time to resolve them, I never realized we might have
> completed them all. The "line" defining what belongs where is still
> blurry though, we should make sure this won't have future regressions.
>
> I'll see if we can produce fully fledged module-info descriptors then :)

Well, sorry I sent that too fast without thinking.

Of course making full modules is not an option as several of our
dependencies aren't modular yet.

Thanks anyway that was a very interesting observation!

Sanne

>
>>
>>>
>>> # What I don't like:
>>> For one, that the typical application will need to import both
>>> `org.hibernate.search.engine` and `org.hibernate.search.orm`, and
>>> likely more as well (e.g. Elasticsearch API, Lucene API module is
>>> coming, ..).
>>
>>
>> I'm not exactly sure what you mean by "import" here. But if it's about the
>> user having to declare dependences in their module descriptor to
>> o.h.s.engine and o.h.s.orm modules, you may consider to make the former a
>> transitive dependence of the latter once you add actual module descriptors:
>>
>>     module org.hibernate.search.orm {
>>         requires transitive org.hibernate.search.engine;
>>         ...
>>     }
>>
>> That way the user just has to add declare the dependence to o.h.s.orm.
>> That's definitely suitable if APIs in o.h.s.orm use types from engine in
>> their public API signatures.
>
> +1 that's the better option.
>
> My thought was about automatic module names though, but totally
> irrelevant if we go for full modules.
>
> Thanks,
> Sanne
>
>>
>>>
>>> Maybe similar to BOM's today we could publish a module which
>>> statically imports multiple of these, that could be nicer to use but
>>> we risk needing to publish (and document) one for each of a selection
>>> of combinations. So let's not start with such things yet.
>>>
>>> Thanks,
>>> Sanne
>>>
>>> [1] http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>

From gunnar at hibernate.org  Mon Feb 12 14:43:28 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 12 Feb 2018 20:43:28 +0100
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
	<CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
	<CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
Message-ID: <CADGJaX9mG=bz7izuxB+AJGWc9E51VFwJ_aix20B2R0SROWV9vg@mail.gmail.com>

2018-02-12 19:28 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> On 12 February 2018 at 18:00, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> >
> > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> Picking automatic module names for Hibernate Search isn't going to be
> >> straight-forward as our two main jars (hibernate-search-engine &
> >> hibernate-search-orm) suffer from split package among them.
> >>
> >> We can't really fix the split package problem without breaking all
> >> users, so if we want to consider that, we can debate it but that will
> >> need to happen at another round as we're doing a minor release, so
> >> let's focus on:
> >>  # Which names to pick
> >>  # Should we pick the names at all
> >>  # Which modules should have a name
> >>
> >> For a great background on the possible strategies and pitfalls I
> >> recommend reading Stephen Colebourne's blog on this subject [1].
> >> He persuaded me there are good reasons to use the "reverse DNS, the
> >> top level package", however since we have the split package problem we
> >> can't simply go with that.
> >>
> >> Still, we can respect the principles he recommends with a small
> >> variation. It's fair to assume that the `org.hibernate.search` prefix
> >> is "ours"; since the nature of the suggestion is focused on making
> >> sure there are no misunderstandings in the community about which names
> >> you can choose - as there is no central authority making sure module
> >> names aren't clashing - we should be fine within Hibernate projects
> >> with any `org.hibernate.X` prefix, as long as we coordinate and reach
> >> an agreement on this list.
> >>
> >> So, I propose we use:
> >>
> >> Engine module:
> >>  - org.hibernate.search.engine
> >>
> >> ORM integration module:
> >>  - org.hibernate.search.orm
> >>
> > Those names sound good to me.
> >
> >>
> >> JGroups, JMS backends:
> >>   [ no automatic module name ? Excepting some "guidelines" in the JMS
> >> module, these are not public API so nobody would benefit from it -
> >> also we think we might want to phase out the name "backend" in the
> >> future ]
> >>
> >> Elasticsearch integration module [hibernate-search-elasticsearch.jar]:
> >>  - org.hibernate.search.elasticsearch
> >>
> >> Elasticsearch / AWS security integration:
> >>  [ no automatic module name: no public API ]
> >>
> >> Serialization / Avro
> >>  [ no automatic module name: no public API ]
> >>
> >> WDYT?
> >
> >
> > The user may still need to reference those modules when launching a
> > modularized application. Also if they don't directly declare say the JMS
> > backend as a dependence of their own module, they'd still have to
> specify it
> > via --add-modules, so to resolve these additional modules and add them to
> > the module graph. Hence I'd declare automatic module names for these,
> too.
>
> Good point, I had not thought that our modules wouldn't be able to
> load other extensions from classpath.
>
> >> We could also pick names for the ones which I've listed as "no public
> >> API" but I see no point: as we're only assigning an "Automatic Module
> >> Name" we won't be able to explicitly state that the other modules
> >> depend on these. So nobody will use them, and things are a bit in flux
> >> anyway in this area because of Hibernate Search 6 plans.
> >
> >
> > I don't fully understand this paragraph.
>
> You mostly invalidated it with the previous comment, but what I meant
> is that we can't have the `org.hibernate.search.engine` declare a
> dependency on any implementation module, as we're not adding a
> module-info definition.
>
> >> Another optional altogether: since we have split packages which we'll
> >> have to resolve before we can actually transform these into fully
> >> fledged modules, I think an acceptable position is also to say we
> >> won't be publishing any automatic module name yet. Personally I'm
> >> inclined to go with the names suggested above, at least some others
> >> can start making baby steps, even if it's not all there.
> >
> >
> > IMO automatic module names should only be declared after at least some
> basic
> > vetting that these modules will actually work when used as modules. If
> > that's not the case, I wouldn't add these headers, as users rightfully
> may
> > consider their presence as endorsement of using them as modules.
> >
> > That said, I can't seem to find split packages between engine and orm. In
> > fact I can launch an application with both of them on the module path
> just
> > fine. So there may be no problem actually?
>
> Interesting, I'm pretty sure we had some. We had several issues
> resolved over time to resolve them, I never realized we might have
> completed them all. The "line" defining what belongs where is still
> blurry though, we should make sure this won't have future regressions.
>

Where I had problems with split packages was when exploring HSearch @ Java
9 modules last year was Lucene. In the version used back then (not sure
whether it's still an issue today), there was a split package between
Lucene's core and the util module (the one with the uninverting reader).

You might take my example project I had created for running ORM as modules (
https://github.com/gunnarmorling/hibernate-orm-on-java9-modules/compare/orm-modularized)
if you're interested in doing the same for HSearch. IIRC, the Lucene split
package made me give up back then, it's surely worth taking another look
with the current versions in use.

>
> I'll see if we can produce fully fledged module-info descriptors then :)
>
> >
> >>
> >> # What I don't like:
> >> For one, that the typical application will need to import both
> >> `org.hibernate.search.engine` and `org.hibernate.search.orm`, and
> >> likely more as well (e.g. Elasticsearch API, Lucene API module is
> >> coming, ..).
> >
> >
> > I'm not exactly sure what you mean by "import" here. But if it's about
> the
> > user having to declare dependences in their module descriptor to
> > o.h.s.engine and o.h.s.orm modules, you may consider to make the former a
> > transitive dependence of the latter once you add actual module
> descriptors:
> >
> >     module org.hibernate.search.orm {
> >         requires transitive org.hibernate.search.engine;
> >         ...
> >     }
> >
> > That way the user just has to add declare the dependence to o.h.s.orm.
> > That's definitely suitable if APIs in o.h.s.orm use types from engine in
> > their public API signatures.
>
> +1 that's the better option.
>
> My thought was about automatic module names though, but totally
> irrelevant if we go for full modules.
>
> Thanks,
> Sanne
>
> >
> >>
> >> Maybe similar to BOM's today we could publish a module which
> >> statically imports multiple of these, that could be nicer to use but
> >> we risk needing to publish (and document) one for each of a selection
> >> of combinations. So let's not start with such things yet.
> >>
> >> Thanks,
> >> Sanne
> >>
> >> [1] http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>

From sanne at hibernate.org  Mon Feb 12 18:37:17 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 12 Feb 2018 23:37:17 +0000
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CADGJaX9mG=bz7izuxB+AJGWc9E51VFwJ_aix20B2R0SROWV9vg@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
	<CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
	<CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
	<CADGJaX9mG=bz7izuxB+AJGWc9E51VFwJ_aix20B2R0SROWV9vg@mail.gmail.com>
Message-ID: <CAFm4XO0R_Xn0U739ERHP+wKJmByPaeLH=3F9OrVhcivLUYQMUA@mail.gmail.com>

The split package problem with Lucene won't easily go away, as we
can't upgrade Lucene now.

But I vaguely remember working with you on that, didn't we figure out
that one of the Lucene modules wasn't essential?

Either way, that's interesting to experiment with but we can't publish
full modules as almost none of our dependencies are ready; they should
at least all have an automatic module name.

Thanks,
Sanne

On 12 February 2018 at 19:43, Gunnar Morling <gunnar at hibernate.org> wrote:
>
>
> 2018-02-12 19:28 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> On 12 February 2018 at 18:00, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >
>> >
>> > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>
>> >> Picking automatic module names for Hibernate Search isn't going to be
>> >> straight-forward as our two main jars (hibernate-search-engine &
>> >> hibernate-search-orm) suffer from split package among them.
>> >>
>> >> We can't really fix the split package problem without breaking all
>> >> users, so if we want to consider that, we can debate it but that will
>> >> need to happen at another round as we're doing a minor release, so
>> >> let's focus on:
>> >>  # Which names to pick
>> >>  # Should we pick the names at all
>> >>  # Which modules should have a name
>> >>
>> >> For a great background on the possible strategies and pitfalls I
>> >> recommend reading Stephen Colebourne's blog on this subject [1].
>> >> He persuaded me there are good reasons to use the "reverse DNS, the
>> >> top level package", however since we have the split package problem we
>> >> can't simply go with that.
>> >>
>> >> Still, we can respect the principles he recommends with a small
>> >> variation. It's fair to assume that the `org.hibernate.search` prefix
>> >> is "ours"; since the nature of the suggestion is focused on making
>> >> sure there are no misunderstandings in the community about which names
>> >> you can choose - as there is no central authority making sure module
>> >> names aren't clashing - we should be fine within Hibernate projects
>> >> with any `org.hibernate.X` prefix, as long as we coordinate and reach
>> >> an agreement on this list.
>> >>
>> >> So, I propose we use:
>> >>
>> >> Engine module:
>> >>  - org.hibernate.search.engine
>> >>
>> >> ORM integration module:
>> >>  - org.hibernate.search.orm
>> >>
>> > Those names sound good to me.
>> >
>> >>
>> >> JGroups, JMS backends:
>> >>   [ no automatic module name ? Excepting some "guidelines" in the JMS
>> >> module, these are not public API so nobody would benefit from it -
>> >> also we think we might want to phase out the name "backend" in the
>> >> future ]
>> >>
>> >> Elasticsearch integration module [hibernate-search-elasticsearch.jar]:
>> >>  - org.hibernate.search.elasticsearch
>> >>
>> >> Elasticsearch / AWS security integration:
>> >>  [ no automatic module name: no public API ]
>> >>
>> >> Serialization / Avro
>> >>  [ no automatic module name: no public API ]
>> >>
>> >> WDYT?
>> >
>> >
>> > The user may still need to reference those modules when launching a
>> > modularized application. Also if they don't directly declare say the JMS
>> > backend as a dependence of their own module, they'd still have to
>> > specify it
>> > via --add-modules, so to resolve these additional modules and add them
>> > to
>> > the module graph. Hence I'd declare automatic module names for these,
>> > too.
>>
>> Good point, I had not thought that our modules wouldn't be able to
>> load other extensions from classpath.
>>
>> >> We could also pick names for the ones which I've listed as "no public
>> >> API" but I see no point: as we're only assigning an "Automatic Module
>> >> Name" we won't be able to explicitly state that the other modules
>> >> depend on these. So nobody will use them, and things are a bit in flux
>> >> anyway in this area because of Hibernate Search 6 plans.
>> >
>> >
>> > I don't fully understand this paragraph.
>>
>> You mostly invalidated it with the previous comment, but what I meant
>> is that we can't have the `org.hibernate.search.engine` declare a
>> dependency on any implementation module, as we're not adding a
>> module-info definition.
>>
>> >> Another optional altogether: since we have split packages which we'll
>> >> have to resolve before we can actually transform these into fully
>> >> fledged modules, I think an acceptable position is also to say we
>> >> won't be publishing any automatic module name yet. Personally I'm
>> >> inclined to go with the names suggested above, at least some others
>> >> can start making baby steps, even if it's not all there.
>> >
>> >
>> > IMO automatic module names should only be declared after at least some
>> > basic
>> > vetting that these modules will actually work when used as modules. If
>> > that's not the case, I wouldn't add these headers, as users rightfully
>> > may
>> > consider their presence as endorsement of using them as modules.
>> >
>> > That said, I can't seem to find split packages between engine and orm.
>> > In
>> > fact I can launch an application with both of them on the module path
>> > just
>> > fine. So there may be no problem actually?
>>
>> Interesting, I'm pretty sure we had some. We had several issues
>> resolved over time to resolve them, I never realized we might have
>> completed them all. The "line" defining what belongs where is still
>> blurry though, we should make sure this won't have future regressions.
>
>
> Where I had problems with split packages was when exploring HSearch @ Java 9
> modules last year was Lucene. In the version used back then (not sure
> whether it's still an issue today), there was a split package between
> Lucene's core and the util module (the one with the uninverting reader).
>
> You might take my example project I had created for running ORM as modules
> (https://github.com/gunnarmorling/hibernate-orm-on-java9-modules/compare/orm-modularized)
> if you're interested in doing the same for HSearch. IIRC, the Lucene split
> package made me give up back then, it's surely worth taking another look
> with the current versions in use.
>>
>>
>> I'll see if we can produce fully fledged module-info descriptors then :)
>>
>> >
>> >>
>> >> # What I don't like:
>> >> For one, that the typical application will need to import both
>> >> `org.hibernate.search.engine` and `org.hibernate.search.orm`, and
>> >> likely more as well (e.g. Elasticsearch API, Lucene API module is
>> >> coming, ..).
>> >
>> >
>> > I'm not exactly sure what you mean by "import" here. But if it's about
>> > the
>> > user having to declare dependences in their module descriptor to
>> > o.h.s.engine and o.h.s.orm modules, you may consider to make the former
>> > a
>> > transitive dependence of the latter once you add actual module
>> > descriptors:
>> >
>> >     module org.hibernate.search.orm {
>> >         requires transitive org.hibernate.search.engine;
>> >         ...
>> >     }
>> >
>> > That way the user just has to add declare the dependence to o.h.s.orm.
>> > That's definitely suitable if APIs in o.h.s.orm use types from engine in
>> > their public API signatures.
>>
>> +1 that's the better option.
>>
>> My thought was about automatic module names though, but totally
>> irrelevant if we go for full modules.
>>
>> Thanks,
>> Sanne
>>
>> >
>> >>
>> >> Maybe similar to BOM's today we could publish a module which
>> >> statically imports multiple of these, that could be nicer to use but
>> >> we risk needing to publish (and document) one for each of a selection
>> >> of combinations. So let's not start with such things yet.
>> >>
>> >> Thanks,
>> >> Sanne
>> >>
>> >> [1] http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>
>

From yoann at hibernate.org  Tue Feb 13 03:44:39 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Tue, 13 Feb 2018 08:44:39 +0000
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CAFm4XO0R_Xn0U739ERHP+wKJmByPaeLH=3F9OrVhcivLUYQMUA@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
	<CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
	<CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
	<CADGJaX9mG=bz7izuxB+AJGWc9E51VFwJ_aix20B2R0SROWV9vg@mail.gmail.com>
	<CAFm4XO0R_Xn0U739ERHP+wKJmByPaeLH=3F9OrVhcivLUYQMUA@mail.gmail.com>
Message-ID: <CAEqagpoObS3DvgXkwg0xwu0D20LX4sQRupHc6fMfND2u1O_82Q@mail.gmail.com>

> IMO automatic module names should only be declared after at least some
basic vetting that these modules will actually work when used as modules.
If that's not the case, I wouldn't add these headers, as users rightfully
may consider their presence as endorsement of using them as modules.

If I understood correctly, automatic module names were introduced to
facilitate the transition to Jigsaw modules. The point was to allow
projects to give a name to their modules, and, yes, declare them as ready,
but even if they couldn't be made full modules yet because of their
dependencies. Declaring a name doesn't mean the module will work, it means
it will work *when dependencies are fixed*. If we wait for all of our
dependencies to work in a modular environment before we give a name to our
modules, we may very well never do it because of circular dependencies (
Infinispan comes to mind: Infinispan-query depends on Search for, which
depends on ORM, which depends on the Infinispan 2nd level cache provider).
Declaring a full module-info.java is another matter, but as you mentioned,
we simply can't do that yet because of split packages in Lucene.

Back to naming... It looks good and consistent with the current naming our
Maven artifacts. In 6, I would probably choose to rename the Elasticsearch
one to something like
org.hibernate.search.<backendOrSomething>.elasticsearch, but we still have
to coin the right term for "<backendOrSomething>", and I would probably
rename the Maven artifact too, so that can wait.

I think you forgot the JSR 352 integration, but I guess the name would be
rather obvious:
 - org.hibernate.search.jsr352

As to non-public APIs, can you confirm automatic modules can access the
classpath transparently? If so then I agree, no need to name those....
Except for the JMS backend: it is unusable without the user extending
AbstractJMSHibernateSearchController,
so this class at least must be exposed to the user. Even if it's just SPI.

On Tue, 13 Feb 2018 at 00:39 Sanne Grinovero <sanne at hibernate.org> wrote:

> The split package problem with Lucene won't easily go away, as we
> can't upgrade Lucene now.
>
> But I vaguely remember working with you on that, didn't we figure out
> that one of the Lucene modules wasn't essential?
>
> Either way, that's interesting to experiment with but we can't publish
> full modules as almost none of our dependencies are ready; they should
> at least all have an automatic module name.
>
> Thanks,
> Sanne
>
> On 12 February 2018 at 19:43, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> >
> > 2018-02-12 19:28 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> On 12 February 2018 at 18:00, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >> >
> >> >
> >> > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >> >>
> >> >> Picking automatic module names for Hibernate Search isn't going to be
> >> >> straight-forward as our two main jars (hibernate-search-engine &
> >> >> hibernate-search-orm) suffer from split package among them.
> >> >>
> >> >> We can't really fix the split package problem without breaking all
> >> >> users, so if we want to consider that, we can debate it but that will
> >> >> need to happen at another round as we're doing a minor release, so
> >> >> let's focus on:
> >> >>  # Which names to pick
> >> >>  # Should we pick the names at all
> >> >>  # Which modules should have a name
> >> >>
> >> >> For a great background on the possible strategies and pitfalls I
> >> >> recommend reading Stephen Colebourne's blog on this subject [1].
> >> >> He persuaded me there are good reasons to use the "reverse DNS, the
> >> >> top level package", however since we have the split package problem
> we
> >> >> can't simply go with that.
> >> >>
> >> >> Still, we can respect the principles he recommends with a small
> >> >> variation. It's fair to assume that the `org.hibernate.search` prefix
> >> >> is "ours"; since the nature of the suggestion is focused on making
> >> >> sure there are no misunderstandings in the community about which
> names
> >> >> you can choose - as there is no central authority making sure module
> >> >> names aren't clashing - we should be fine within Hibernate projects
> >> >> with any `org.hibernate.X` prefix, as long as we coordinate and reach
> >> >> an agreement on this list.
> >> >>
> >> >> So, I propose we use:
> >> >>
> >> >> Engine module:
> >> >>  - org.hibernate.search.engine
> >> >>
> >> >> ORM integration module:
> >> >>  - org.hibernate.search.orm
> >> >>
> >> > Those names sound good to me.
> >> >
> >> >>
> >> >> JGroups, JMS backends:
> >> >>   [ no automatic module name ? Excepting some "guidelines" in the JMS
> >> >> module, these are not public API so nobody would benefit from it -
> >> >> also we think we might want to phase out the name "backend" in the
> >> >> future ]
> >> >>
> >> >> Elasticsearch integration module
> [hibernate-search-elasticsearch.jar]:
> >> >>  - org.hibernate.search.elasticsearch
> >> >>
> >> >> Elasticsearch / AWS security integration:
> >> >>  [ no automatic module name: no public API ]
> >> >>
> >> >> Serialization / Avro
> >> >>  [ no automatic module name: no public API ]
> >> >>
> >> >> WDYT?
> >> >
> >> >
> >> > The user may still need to reference those modules when launching a
> >> > modularized application. Also if they don't directly declare say the
> JMS
> >> > backend as a dependence of their own module, they'd still have to
> >> > specify it
> >> > via --add-modules, so to resolve these additional modules and add them
> >> > to
> >> > the module graph. Hence I'd declare automatic module names for these,
> >> > too.
> >>
> >> Good point, I had not thought that our modules wouldn't be able to
> >> load other extensions from classpath.
> >>
> >> >> We could also pick names for the ones which I've listed as "no public
> >> >> API" but I see no point: as we're only assigning an "Automatic Module
> >> >> Name" we won't be able to explicitly state that the other modules
> >> >> depend on these. So nobody will use them, and things are a bit in
> flux
> >> >> anyway in this area because of Hibernate Search 6 plans.
> >> >
> >> >
> >> > I don't fully understand this paragraph.
> >>
> >> You mostly invalidated it with the previous comment, but what I meant
> >> is that we can't have the `org.hibernate.search.engine` declare a
> >> dependency on any implementation module, as we're not adding a
> >> module-info definition.
> >>
> >> >> Another optional altogether: since we have split packages which we'll
> >> >> have to resolve before we can actually transform these into fully
> >> >> fledged modules, I think an acceptable position is also to say we
> >> >> won't be publishing any automatic module name yet. Personally I'm
> >> >> inclined to go with the names suggested above, at least some others
> >> >> can start making baby steps, even if it's not all there.
> >> >
> >> >
> >> > IMO automatic module names should only be declared after at least some
> >> > basic
> >> > vetting that these modules will actually work when used as modules. If
> >> > that's not the case, I wouldn't add these headers, as users rightfully
> >> > may
> >> > consider their presence as endorsement of using them as modules.
> >> >
> >> > That said, I can't seem to find split packages between engine and orm.
> >> > In
> >> > fact I can launch an application with both of them on the module path
> >> > just
> >> > fine. So there may be no problem actually?
> >>
> >> Interesting, I'm pretty sure we had some. We had several issues
> >> resolved over time to resolve them, I never realized we might have
> >> completed them all. The "line" defining what belongs where is still
> >> blurry though, we should make sure this won't have future regressions.
> >
> >
> > Where I had problems with split packages was when exploring HSearch @
> Java 9
> > modules last year was Lucene. In the version used back then (not sure
> > whether it's still an issue today), there was a split package between
> > Lucene's core and the util module (the one with the uninverting reader).
> >
> > You might take my example project I had created for running ORM as
> modules
> > (
> https://github.com/gunnarmorling/hibernate-orm-on-java9-modules/compare/orm-modularized
> )
> > if you're interested in doing the same for HSearch. IIRC, the Lucene
> split
> > package made me give up back then, it's surely worth taking another look
> > with the current versions in use.
> >>
> >>
> >> I'll see if we can produce fully fledged module-info descriptors then :)
> >>
> >> >
> >> >>
> >> >> # What I don't like:
> >> >> For one, that the typical application will need to import both
> >> >> `org.hibernate.search.engine` and `org.hibernate.search.orm`, and
> >> >> likely more as well (e.g. Elasticsearch API, Lucene API module is
> >> >> coming, ..).
> >> >
> >> >
> >> > I'm not exactly sure what you mean by "import" here. But if it's about
> >> > the
> >> > user having to declare dependences in their module descriptor to
> >> > o.h.s.engine and o.h.s.orm modules, you may consider to make the
> former
> >> > a
> >> > transitive dependence of the latter once you add actual module
> >> > descriptors:
> >> >
> >> >     module org.hibernate.search.orm {
> >> >         requires transitive org.hibernate.search.engine;
> >> >         ...
> >> >     }
> >> >
> >> > That way the user just has to add declare the dependence to o.h.s.orm.
> >> > That's definitely suitable if APIs in o.h.s.orm use types from engine
> in
> >> > their public API signatures.
> >>
> >> +1 that's the better option.
> >>
> >> My thought was about automatic module names though, but totally
> >> irrelevant if we go for full modules.
> >>
> >> Thanks,
> >> Sanne
> >>
> >> >
> >> >>
> >> >> Maybe similar to BOM's today we could publish a module which
> >> >> statically imports multiple of these, that could be nicer to use but
> >> >> we risk needing to publish (and document) one for each of a selection
> >> >> of combinations. So let's not start with such things yet.
> >> >>
> >> >> Thanks,
> >> >> Sanne
> >> >>
> >> >> [1]
> http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> >
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From gunnar at hibernate.org  Tue Feb 13 03:53:17 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 13 Feb 2018 09:53:17 +0100
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CAFm4XO0R_Xn0U739ERHP+wKJmByPaeLH=3F9OrVhcivLUYQMUA@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
	<CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
	<CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
	<CADGJaX9mG=bz7izuxB+AJGWc9E51VFwJ_aix20B2R0SROWV9vg@mail.gmail.com>
	<CAFm4XO0R_Xn0U739ERHP+wKJmByPaeLH=3F9OrVhcivLUYQMUA@mail.gmail.com>
Message-ID: <CADGJaX8M6nRH7VupTQ4Gj4zG3jGcu5y2VcbuqLMDYqC2g15CHQ@mail.gmail.com>

2018-02-13 0:37 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> The split package problem with Lucene won't easily go away, as we
> can't upgrade Lucene now.
>
> But I vaguely remember working with you on that, didn't we figure out
> that one of the Lucene modules wasn't essential?
>

The split package is only between lucene.core and lucene.misc. I believe
the latter is only needed for the uninverting index reader.

So you could extract the functionality requiring the latter into its own
HSearch module, and only this one would depend on lucene.misc. Then
everything else should be usable as Java 9 modules, only that particular
functionality won't be usable until we're on a Lucene version without that
split package. For users on Java 8 nothing will change, apart from the fact
that they'll have to add this additional dependency should they want to use
the uninverting reader.

But I think using the uninverting reader was a non-preferred fallback only
anyways in case the index doesn't contain all doc fields required for
sorting. So this seems like an acceptable compromise.


> Either way, that's interesting to experiment with but we can't publish
> full modules as almost none of our dependencies are ready; they should
> at least all have an automatic module name.
>
> Thanks,
> Sanne
>
> On 12 February 2018 at 19:43, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> >
> > 2018-02-12 19:28 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> On 12 February 2018 at 18:00, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >> >
> >> >
> >> > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >> >>
> >> >> Picking automatic module names for Hibernate Search isn't going to be
> >> >> straight-forward as our two main jars (hibernate-search-engine &
> >> >> hibernate-search-orm) suffer from split package among them.
> >> >>
> >> >> We can't really fix the split package problem without breaking all
> >> >> users, so if we want to consider that, we can debate it but that will
> >> >> need to happen at another round as we're doing a minor release, so
> >> >> let's focus on:
> >> >>  # Which names to pick
> >> >>  # Should we pick the names at all
> >> >>  # Which modules should have a name
> >> >>
> >> >> For a great background on the possible strategies and pitfalls I
> >> >> recommend reading Stephen Colebourne's blog on this subject [1].
> >> >> He persuaded me there are good reasons to use the "reverse DNS, the
> >> >> top level package", however since we have the split package problem
> we
> >> >> can't simply go with that.
> >> >>
> >> >> Still, we can respect the principles he recommends with a small
> >> >> variation. It's fair to assume that the `org.hibernate.search` prefix
> >> >> is "ours"; since the nature of the suggestion is focused on making
> >> >> sure there are no misunderstandings in the community about which
> names
> >> >> you can choose - as there is no central authority making sure module
> >> >> names aren't clashing - we should be fine within Hibernate projects
> >> >> with any `org.hibernate.X` prefix, as long as we coordinate and reach
> >> >> an agreement on this list.
> >> >>
> >> >> So, I propose we use:
> >> >>
> >> >> Engine module:
> >> >>  - org.hibernate.search.engine
> >> >>
> >> >> ORM integration module:
> >> >>  - org.hibernate.search.orm
> >> >>
> >> > Those names sound good to me.
> >> >
> >> >>
> >> >> JGroups, JMS backends:
> >> >>   [ no automatic module name ? Excepting some "guidelines" in the JMS
> >> >> module, these are not public API so nobody would benefit from it -
> >> >> also we think we might want to phase out the name "backend" in the
> >> >> future ]
> >> >>
> >> >> Elasticsearch integration module [hibernate-search-
> elasticsearch.jar]:
> >> >>  - org.hibernate.search.elasticsearch
> >> >>
> >> >> Elasticsearch / AWS security integration:
> >> >>  [ no automatic module name: no public API ]
> >> >>
> >> >> Serialization / Avro
> >> >>  [ no automatic module name: no public API ]
> >> >>
> >> >> WDYT?
> >> >
> >> >
> >> > The user may still need to reference those modules when launching a
> >> > modularized application. Also if they don't directly declare say the
> JMS
> >> > backend as a dependence of their own module, they'd still have to
> >> > specify it
> >> > via --add-modules, so to resolve these additional modules and add them
> >> > to
> >> > the module graph. Hence I'd declare automatic module names for these,
> >> > too.
> >>
> >> Good point, I had not thought that our modules wouldn't be able to
> >> load other extensions from classpath.
> >>
> >> >> We could also pick names for the ones which I've listed as "no public
> >> >> API" but I see no point: as we're only assigning an "Automatic Module
> >> >> Name" we won't be able to explicitly state that the other modules
> >> >> depend on these. So nobody will use them, and things are a bit in
> flux
> >> >> anyway in this area because of Hibernate Search 6 plans.
> >> >
> >> >
> >> > I don't fully understand this paragraph.
> >>
> >> You mostly invalidated it with the previous comment, but what I meant
> >> is that we can't have the `org.hibernate.search.engine` declare a
> >> dependency on any implementation module, as we're not adding a
> >> module-info definition.
> >>
> >> >> Another optional altogether: since we have split packages which we'll
> >> >> have to resolve before we can actually transform these into fully
> >> >> fledged modules, I think an acceptable position is also to say we
> >> >> won't be publishing any automatic module name yet. Personally I'm
> >> >> inclined to go with the names suggested above, at least some others
> >> >> can start making baby steps, even if it's not all there.
> >> >
> >> >
> >> > IMO automatic module names should only be declared after at least some
> >> > basic
> >> > vetting that these modules will actually work when used as modules. If
> >> > that's not the case, I wouldn't add these headers, as users rightfully
> >> > may
> >> > consider their presence as endorsement of using them as modules.
> >> >
> >> > That said, I can't seem to find split packages between engine and orm.
> >> > In
> >> > fact I can launch an application with both of them on the module path
> >> > just
> >> > fine. So there may be no problem actually?
> >>
> >> Interesting, I'm pretty sure we had some. We had several issues
> >> resolved over time to resolve them, I never realized we might have
> >> completed them all. The "line" defining what belongs where is still
> >> blurry though, we should make sure this won't have future regressions.
> >
> >
> > Where I had problems with split packages was when exploring HSearch @
> Java 9
> > modules last year was Lucene. In the version used back then (not sure
> > whether it's still an issue today), there was a split package between
> > Lucene's core and the util module (the one with the uninverting reader).
> >
> > You might take my example project I had created for running ORM as
> modules
> > (https://github.com/gunnarmorling/hibernate-orm-
> on-java9-modules/compare/orm-modularized)
> > if you're interested in doing the same for HSearch. IIRC, the Lucene
> split
> > package made me give up back then, it's surely worth taking another look
> > with the current versions in use.
> >>
> >>
> >> I'll see if we can produce fully fledged module-info descriptors then :)
> >>
> >> >
> >> >>
> >> >> # What I don't like:
> >> >> For one, that the typical application will need to import both
> >> >> `org.hibernate.search.engine` and `org.hibernate.search.orm`, and
> >> >> likely more as well (e.g. Elasticsearch API, Lucene API module is
> >> >> coming, ..).
> >> >
> >> >
> >> > I'm not exactly sure what you mean by "import" here. But if it's about
> >> > the
> >> > user having to declare dependences in their module descriptor to
> >> > o.h.s.engine and o.h.s.orm modules, you may consider to make the
> former
> >> > a
> >> > transitive dependence of the latter once you add actual module
> >> > descriptors:
> >> >
> >> >     module org.hibernate.search.orm {
> >> >         requires transitive org.hibernate.search.engine;
> >> >         ...
> >> >     }
> >> >
> >> > That way the user just has to add declare the dependence to o.h.s.orm.
> >> > That's definitely suitable if APIs in o.h.s.orm use types from engine
> in
> >> > their public API signatures.
> >>
> >> +1 that's the better option.
> >>
> >> My thought was about automatic module names though, but totally
> >> irrelevant if we go for full modules.
> >>
> >> Thanks,
> >> Sanne
> >>
> >> >
> >> >>
> >> >> Maybe similar to BOM's today we could publish a module which
> >> >> statically imports multiple of these, that could be nicer to use but
> >> >> we risk needing to publish (and document) one for each of a selection
> >> >> of combinations. So let's not start with such things yet.
> >> >>
> >> >> Thanks,
> >> >> Sanne
> >> >>
> >> >> [1] http://blog.joda.org/2017/05/java-se-9-jpms-automatic-
> modules.html
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> >
> >
> >
>

From gunnar at hibernate.org  Tue Feb 13 04:07:49 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 13 Feb 2018 10:07:49 +0100
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CAEqagpoObS3DvgXkwg0xwu0D20LX4sQRupHc6fMfND2u1O_82Q@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
	<CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
	<CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
	<CADGJaX9mG=bz7izuxB+AJGWc9E51VFwJ_aix20B2R0SROWV9vg@mail.gmail.com>
	<CAFm4XO0R_Xn0U739ERHP+wKJmByPaeLH=3F9OrVhcivLUYQMUA@mail.gmail.com>
	<CAEqagpoObS3DvgXkwg0xwu0D20LX4sQRupHc6fMfND2u1O_82Q@mail.gmail.com>
Message-ID: <CADGJaX_AhMmqhDdLUqG23B=n4R=iOZRJXUPmPu+csQgmkHK+nA@mail.gmail.com>

2018-02-13 9:44 GMT+01:00 Yoann Rodiere <yoann at hibernate.org>:

> > IMO automatic module names should only be declared after at least some
> basic vetting that these modules will actually work when used as modules.
> If that's not the case, I wouldn't add these headers, as users rightfully
> may consider their presence as endorsement of using them as modules.
>
> If I understood correctly, automatic module names were introduced to
> facilitate the transition to Jigsaw modules. The point was to allow
> projects to give a name to their modules, and, yes, declare them as ready,
> but even if they couldn't be made full modules yet because of their
> dependencies. Declaring a name doesn't mean the module will work, it means
> it will work *when dependencies are fixed*.
>

How can you be sure of that though without trying it out?


> If we wait for all of our dependencies to work in a modular environment
> before we give a name to our modules, we may very well never do it because
> of circular dependencies (Infinispan comes to mind: Infinispan-query depends
> on Search for, which depends on ORM, which depends on the Infinispan 2nd
> level cache provider).
>

If there are cycles, problems go far beyond finding good names. The default
resolver will not allow cycles between modules.


> Declaring a full module-info.java is another matter, but as you mentioned,
> we simply can't do that yet because of split packages in Lucene.
>
> Back to naming... It looks good and consistent with the current naming our
> Maven artifacts. In 6, I would probably choose to rename the Elasticsearch
> one to something like org.hibernate.search.<backendOrSomething>.elasticsearch,
> but we still have to coin the right term for "<backendOrSomething>", and I
> would probably rename the Maven artifact too, so that can wait.
>
> I think you forgot the JSR 352 integration, but I guess the name would be
> rather obvious:
>  - org.hibernate.search.jsr352
>
> As to non-public APIs, can you confirm automatic modules can access the
> classpath transparently? If so then I agree, no need to name those....
> Except for the JMS backend: it is unusable without the user extending
> AbstractJMSHibernateSearchController, so this class at least must be
> exposed to the user. Even if it's just SPI.
>

Automatic modules can access the classpath (which is represented by the
UNNAMED module, and all automatic modules read that).

But I wouldn't recommend to rely on such mixed set-up as it's cumbersome to
configure. For instance for an app with a module-info.java, Maven will put
all dependencies to the module path when invoking javac; if you wanted to
have some deps on the classpath and some on the module path, that'd be some
manual effort. Hence my suggestion to give automatic module names to all of
them and using them on the module path.


> On Tue, 13 Feb 2018 at 00:39 Sanne Grinovero <sanne at hibernate.org> wrote:
>
>> The split package problem with Lucene won't easily go away, as we
>> can't upgrade Lucene now.
>>
>> But I vaguely remember working with you on that, didn't we figure out
>> that one of the Lucene modules wasn't essential?
>>
>> Either way, that's interesting to experiment with but we can't publish
>> full modules as almost none of our dependencies are ready; they should
>> at least all have an automatic module name.
>>
>> Thanks,
>> Sanne
>>
>> On 12 February 2018 at 19:43, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>> >
>> >
>> > 2018-02-12 19:28 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>
>> >> On 12 February 2018 at 18:00, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>> >> >
>> >> >
>> >> > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >> >>
>> >> >> Picking automatic module names for Hibernate Search isn't going to
>> be
>> >> >> straight-forward as our two main jars (hibernate-search-engine &
>> >> >> hibernate-search-orm) suffer from split package among them.
>> >> >>
>> >> >> We can't really fix the split package problem without breaking all
>> >> >> users, so if we want to consider that, we can debate it but that
>> will
>> >> >> need to happen at another round as we're doing a minor release, so
>> >> >> let's focus on:
>> >> >>  # Which names to pick
>> >> >>  # Should we pick the names at all
>> >> >>  # Which modules should have a name
>> >> >>
>> >> >> For a great background on the possible strategies and pitfalls I
>> >> >> recommend reading Stephen Colebourne's blog on this subject [1].
>> >> >> He persuaded me there are good reasons to use the "reverse DNS, the
>> >> >> top level package", however since we have the split package problem
>> we
>> >> >> can't simply go with that.
>> >> >>
>> >> >> Still, we can respect the principles he recommends with a small
>> >> >> variation. It's fair to assume that the `org.hibernate.search`
>> prefix
>> >> >> is "ours"; since the nature of the suggestion is focused on making
>> >> >> sure there are no misunderstandings in the community about which
>> names
>> >> >> you can choose - as there is no central authority making sure module
>> >> >> names aren't clashing - we should be fine within Hibernate projects
>> >> >> with any `org.hibernate.X` prefix, as long as we coordinate and
>> reach
>> >> >> an agreement on this list.
>> >> >>
>> >> >> So, I propose we use:
>> >> >>
>> >> >> Engine module:
>> >> >>  - org.hibernate.search.engine
>> >> >>
>> >> >> ORM integration module:
>> >> >>  - org.hibernate.search.orm
>> >> >>
>> >> > Those names sound good to me.
>> >> >
>> >> >>
>> >> >> JGroups, JMS backends:
>> >> >>   [ no automatic module name ? Excepting some "guidelines" in the
>> JMS
>> >> >> module, these are not public API so nobody would benefit from it -
>> >> >> also we think we might want to phase out the name "backend" in the
>> >> >> future ]
>> >> >>
>> >> >> Elasticsearch integration module [hibernate-search-
>> elasticsearch.jar]:
>> >> >>  - org.hibernate.search.elasticsearch
>> >> >>
>> >> >> Elasticsearch / AWS security integration:
>> >> >>  [ no automatic module name: no public API ]
>> >> >>
>> >> >> Serialization / Avro
>> >> >>  [ no automatic module name: no public API ]
>> >> >>
>> >> >> WDYT?
>> >> >
>> >> >
>> >> > The user may still need to reference those modules when launching a
>> >> > modularized application. Also if they don't directly declare say the
>> JMS
>> >> > backend as a dependence of their own module, they'd still have to
>> >> > specify it
>> >> > via --add-modules, so to resolve these additional modules and add
>> them
>> >> > to
>> >> > the module graph. Hence I'd declare automatic module names for these,
>> >> > too.
>> >>
>> >> Good point, I had not thought that our modules wouldn't be able to
>> >> load other extensions from classpath.
>> >>
>> >> >> We could also pick names for the ones which I've listed as "no
>> public
>> >> >> API" but I see no point: as we're only assigning an "Automatic
>> Module
>> >> >> Name" we won't be able to explicitly state that the other modules
>> >> >> depend on these. So nobody will use them, and things are a bit in
>> flux
>> >> >> anyway in this area because of Hibernate Search 6 plans.
>> >> >
>> >> >
>> >> > I don't fully understand this paragraph.
>> >>
>> >> You mostly invalidated it with the previous comment, but what I meant
>> >> is that we can't have the `org.hibernate.search.engine` declare a
>> >> dependency on any implementation module, as we're not adding a
>> >> module-info definition.
>> >>
>> >> >> Another optional altogether: since we have split packages which
>> we'll
>> >> >> have to resolve before we can actually transform these into fully
>> >> >> fledged modules, I think an acceptable position is also to say we
>> >> >> won't be publishing any automatic module name yet. Personally I'm
>> >> >> inclined to go with the names suggested above, at least some others
>> >> >> can start making baby steps, even if it's not all there.
>> >> >
>> >> >
>> >> > IMO automatic module names should only be declared after at least
>> some
>> >> > basic
>> >> > vetting that these modules will actually work when used as modules.
>> If
>> >> > that's not the case, I wouldn't add these headers, as users
>> rightfully
>> >> > may
>> >> > consider their presence as endorsement of using them as modules.
>> >> >
>> >> > That said, I can't seem to find split packages between engine and
>> orm.
>> >> > In
>> >> > fact I can launch an application with both of them on the module path
>> >> > just
>> >> > fine. So there may be no problem actually?
>> >>
>> >> Interesting, I'm pretty sure we had some. We had several issues
>> >> resolved over time to resolve them, I never realized we might have
>> >> completed them all. The "line" defining what belongs where is still
>> >> blurry though, we should make sure this won't have future regressions.
>> >
>> >
>> > Where I had problems with split packages was when exploring HSearch @
>> Java 9
>> > modules last year was Lucene. In the version used back then (not sure
>> > whether it's still an issue today), there was a split package between
>> > Lucene's core and the util module (the one with the uninverting reader).
>> >
>> > You might take my example project I had created for running ORM as
>> modules
>> > (https://github.com/gunnarmorling/hibernate-orm-
>> on-java9-modules/compare/orm-modularized)
>> > if you're interested in doing the same for HSearch. IIRC, the Lucene
>> split
>> > package made me give up back then, it's surely worth taking another look
>> > with the current versions in use.
>> >>
>> >>
>> >> I'll see if we can produce fully fledged module-info descriptors then
>> :)
>> >>
>> >> >
>> >> >>
>> >> >> # What I don't like:
>> >> >> For one, that the typical application will need to import both
>> >> >> `org.hibernate.search.engine` and `org.hibernate.search.orm`, and
>> >> >> likely more as well (e.g. Elasticsearch API, Lucene API module is
>> >> >> coming, ..).
>> >> >
>> >> >
>> >> > I'm not exactly sure what you mean by "import" here. But if it's
>> about
>> >> > the
>> >> > user having to declare dependences in their module descriptor to
>> >> > o.h.s.engine and o.h.s.orm modules, you may consider to make the
>> former
>> >> > a
>> >> > transitive dependence of the latter once you add actual module
>> >> > descriptors:
>> >> >
>> >> >     module org.hibernate.search.orm {
>> >> >         requires transitive org.hibernate.search.engine;
>> >> >         ...
>> >> >     }
>> >> >
>> >> > That way the user just has to add declare the dependence to
>> o.h.s.orm.
>> >> > That's definitely suitable if APIs in o.h.s.orm use types from
>> engine in
>> >> > their public API signatures.
>> >>
>> >> +1 that's the better option.
>> >>
>> >> My thought was about automatic module names though, but totally
>> >> irrelevant if we go for full modules.
>> >>
>> >> Thanks,
>> >> Sanne
>> >>
>> >> >
>> >> >>
>> >> >> Maybe similar to BOM's today we could publish a module which
>> >> >> statically imports multiple of these, that could be nicer to use but
>> >> >> we risk needing to publish (and document) one for each of a
>> selection
>> >> >> of combinations. So let's not start with such things yet.
>> >> >>
>> >> >> Thanks,
>> >> >> Sanne
>> >> >>
>> >> >> [1] http://blog.joda.org/2017/05/java-se-9-jpms-automatic-
>> modules.html
>> >> >> _______________________________________________
>> >> >> hibernate-dev mailing list
>> >> >> hibernate-dev at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >
>> >> >
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> --
> Yoann Rodiere
> yoann at hibernate.org / yrodiere at redhat.com
> Software Engineer
> Hibernate NoORM team
>

From yoann at hibernate.org  Tue Feb 13 05:04:39 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Tue, 13 Feb 2018 10:04:39 +0000
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CADGJaX_AhMmqhDdLUqG23B=n4R=iOZRJXUPmPu+csQgmkHK+nA@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
	<CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
	<CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
	<CADGJaX9mG=bz7izuxB+AJGWc9E51VFwJ_aix20B2R0SROWV9vg@mail.gmail.com>
	<CAFm4XO0R_Xn0U739ERHP+wKJmByPaeLH=3F9OrVhcivLUYQMUA@mail.gmail.com>
	<CAEqagpoObS3DvgXkwg0xwu0D20LX4sQRupHc6fMfND2u1O_82Q@mail.gmail.com>
	<CADGJaX_AhMmqhDdLUqG23B=n4R=iOZRJXUPmPu+csQgmkHK+nA@mail.gmail.com>
Message-ID: <CAEqagpoWYqmiMfgoELd2QiPufHqfgMvhDK6ZBZG+JtavUKGNow@mail.gmail.com>

> How can you be sure of that though without trying it out?

If what you meant by "work as modules" was "work as *automatic* modules"
(i.e. with dependencies in the classpath), we already test that. We just
happen to know they can't work as "full" modules (with module-info) yet.

> If there are cycles, problems go far beyond finding good names. The
default resolver will not allow cycles between modules.

The cycles are merely between projects, not between modules. It's more a
release issue than a technical issue. The problem arises mainly from the
fact that Infinispan has two sides: the server, and the client libraries. I
guess one way to do it would be for Infinispan to first switch to Jigsaw
modules for their core modules and client library modules, then we do the
switch on our side, then they can do the switch for their server modules.
But I would expect such plan to be slower than switching to automatic
modules first, then to full modules when every dependency is ready.
In any case, there shouldn't be a problem at runtime, so it shouldn't
prevent us from running Jigsaw modules once they are ready, but it's still
a problem to do the switch to full Jigsaw modules.

> Automatic modules can access the classpath (which is represented by the
UNNAMED module, and all automatic modules read that).

Thanks for confirming that.

> But I wouldn't recommend to rely on such mixed set-up as it's cumbersome
to configure. For instance for an app with a module-info.java, Maven will
put all dependencies to the module path when invoking javac; if you wanted
to have some deps on the classpath and some on the module path, that'd be
some manual effort. Hence my suggestion to give automatic module names to
all of them and using them on the module path.

Let me get this straight: I want to just define automatic module names for
our modules, but still rely exclusively on the classpath for our own
dependencies, including internal ones (dependencies from one of our modules
to another of our own modules).
Are you saying this is not possible? I.e. once a jar is promoted to
automatic module, it is not visible from other automatic modules anymore?
Because the alternative doesn't seem workable either: declaring our
dependencies as module dependencies (e.g. in a module-info) would not give
us the option to have classpath dependencies (or would it?), and thus we
would not be able to depend on Lucene...



On Tue, 13 Feb 2018 at 10:08 Gunnar Morling <gunnar at hibernate.org> wrote:

> 2018-02-13 9:44 GMT+01:00 Yoann Rodiere <yoann at hibernate.org>:
>
>> > IMO automatic module names should only be declared after at least some
>> basic vetting that these modules will actually work when used as modules.
>> If that's not the case, I wouldn't add these headers, as users rightfully
>> may consider their presence as endorsement of using them as modules.
>>
>> If I understood correctly, automatic module names were introduced to
>> facilitate the transition to Jigsaw modules. The point was to allow
>> projects to give a name to their modules, and, yes, declare them as ready,
>> but even if they couldn't be made full modules yet because of their
>> dependencies. Declaring a name doesn't mean the module will work, it means
>> it will work *when dependencies are fixed*.
>>
>
> How can you be sure of that though without trying it out?
>
>
>> If we wait for all of our dependencies to work in a modular environment
>> before we give a name to our modules, we may very well never do it because
>> of circular dependencies (Infinispan comes to mind: Infinispan-query depends
>> on Search for, which depends on ORM, which depends on the Infinispan 2nd
>> level cache provider).
>>
>
> If there are cycles, problems go far beyond finding good names. The
> default resolver will not allow cycles between modules.
>
>
>> Declaring a full module-info.java is another matter, but as you
>> mentioned, we simply can't do that yet because of split packages in Lucene.
>>
>> Back to naming... It looks good and consistent with the current naming
>> our Maven artifacts. In 6, I would probably choose to rename the
>> Elasticsearch one to something like
>> org.hibernate.search.<backendOrSomething>.elasticsearch, but we still have
>> to coin the right term for "<backendOrSomething>", and I would probably
>> rename the Maven artifact too, so that can wait.
>>
>> I think you forgot the JSR 352 integration, but I guess the name would be
>> rather obvious:
>>  - org.hibernate.search.jsr352
>>
>> As to non-public APIs, can you confirm automatic modules can access the
>> classpath transparently? If so then I agree, no need to name those....
>> Except for the JMS backend: it is unusable without the user extending AbstractJMSHibernateSearchController,
>> so this class at least must be exposed to the user. Even if it's just SPI.
>>
>
> Automatic modules can access the classpath (which is represented by the
> UNNAMED module, and all automatic modules read that).
>
> But I wouldn't recommend to rely on such mixed set-up as it's cumbersome
> to configure. For instance for an app with a module-info.java, Maven will
> put all dependencies to the module path when invoking javac; if you wanted
> to have some deps on the classpath and some on the module path, that'd be
> some manual effort. Hence my suggestion to give automatic module names to
> all of them and using them on the module path.
>
>
>> On Tue, 13 Feb 2018 at 00:39 Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>>> The split package problem with Lucene won't easily go away, as we
>>> can't upgrade Lucene now.
>>>
>>> But I vaguely remember working with you on that, didn't we figure out
>>> that one of the Lucene modules wasn't essential?
>>>
>>> Either way, that's interesting to experiment with but we can't publish
>>> full modules as almost none of our dependencies are ready; they should
>>> at least all have an automatic module name.
>>>
>>> Thanks,
>>> Sanne
>>>
>>> On 12 February 2018 at 19:43, Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>> >
>>> >
>>> > 2018-02-12 19:28 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>> >>
>>> >> On 12 February 2018 at 18:00, Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>> >> >
>>> >> >
>>> >> > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>> >> >>
>>> >> >> Picking automatic module names for Hibernate Search isn't going to
>>> be
>>> >> >> straight-forward as our two main jars (hibernate-search-engine &
>>> >> >> hibernate-search-orm) suffer from split package among them.
>>> >> >>
>>> >> >> We can't really fix the split package problem without breaking all
>>> >> >> users, so if we want to consider that, we can debate it but that
>>> will
>>> >> >> need to happen at another round as we're doing a minor release, so
>>> >> >> let's focus on:
>>> >> >>  # Which names to pick
>>> >> >>  # Should we pick the names at all
>>> >> >>  # Which modules should have a name
>>> >> >>
>>> >> >> For a great background on the possible strategies and pitfalls I
>>> >> >> recommend reading Stephen Colebourne's blog on this subject [1].
>>> >> >> He persuaded me there are good reasons to use the "reverse DNS, the
>>> >> >> top level package", however since we have the split package
>>> problem we
>>> >> >> can't simply go with that.
>>> >> >>
>>> >> >> Still, we can respect the principles he recommends with a small
>>> >> >> variation. It's fair to assume that the `org.hibernate.search`
>>> prefix
>>> >> >> is "ours"; since the nature of the suggestion is focused on making
>>> >> >> sure there are no misunderstandings in the community about which
>>> names
>>> >> >> you can choose - as there is no central authority making sure
>>> module
>>> >> >> names aren't clashing - we should be fine within Hibernate projects
>>> >> >> with any `org.hibernate.X` prefix, as long as we coordinate and
>>> reach
>>> >> >> an agreement on this list.
>>> >> >>
>>> >> >> So, I propose we use:
>>> >> >>
>>> >> >> Engine module:
>>> >> >>  - org.hibernate.search.engine
>>> >> >>
>>> >> >> ORM integration module:
>>> >> >>  - org.hibernate.search.orm
>>> >> >>
>>> >> > Those names sound good to me.
>>> >> >
>>> >> >>
>>> >> >> JGroups, JMS backends:
>>> >> >>   [ no automatic module name ? Excepting some "guidelines" in the
>>> JMS
>>> >> >> module, these are not public API so nobody would benefit from it -
>>> >> >> also we think we might want to phase out the name "backend" in the
>>> >> >> future ]
>>> >> >>
>>> >> >> Elasticsearch integration module
>>> [hibernate-search-elasticsearch.jar]:
>>> >> >>  - org.hibernate.search.elasticsearch
>>> >> >>
>>> >> >> Elasticsearch / AWS security integration:
>>> >> >>  [ no automatic module name: no public API ]
>>> >> >>
>>> >> >> Serialization / Avro
>>> >> >>  [ no automatic module name: no public API ]
>>> >> >>
>>> >> >> WDYT?
>>> >> >
>>> >> >
>>> >> > The user may still need to reference those modules when launching a
>>> >> > modularized application. Also if they don't directly declare say
>>> the JMS
>>> >> > backend as a dependence of their own module, they'd still have to
>>> >> > specify it
>>> >> > via --add-modules, so to resolve these additional modules and add
>>> them
>>> >> > to
>>> >> > the module graph. Hence I'd declare automatic module names for
>>> these,
>>> >> > too.
>>> >>
>>> >> Good point, I had not thought that our modules wouldn't be able to
>>> >> load other extensions from classpath.
>>> >>
>>> >> >> We could also pick names for the ones which I've listed as "no
>>> public
>>> >> >> API" but I see no point: as we're only assigning an "Automatic
>>> Module
>>> >> >> Name" we won't be able to explicitly state that the other modules
>>> >> >> depend on these. So nobody will use them, and things are a bit in
>>> flux
>>> >> >> anyway in this area because of Hibernate Search 6 plans.
>>> >> >
>>> >> >
>>> >> > I don't fully understand this paragraph.
>>> >>
>>> >> You mostly invalidated it with the previous comment, but what I meant
>>> >> is that we can't have the `org.hibernate.search.engine` declare a
>>> >> dependency on any implementation module, as we're not adding a
>>> >> module-info definition.
>>> >>
>>> >> >> Another optional altogether: since we have split packages which
>>> we'll
>>> >> >> have to resolve before we can actually transform these into fully
>>> >> >> fledged modules, I think an acceptable position is also to say we
>>> >> >> won't be publishing any automatic module name yet. Personally I'm
>>> >> >> inclined to go with the names suggested above, at least some others
>>> >> >> can start making baby steps, even if it's not all there.
>>> >> >
>>> >> >
>>> >> > IMO automatic module names should only be declared after at least
>>> some
>>> >> > basic
>>> >> > vetting that these modules will actually work when used as modules.
>>> If
>>> >> > that's not the case, I wouldn't add these headers, as users
>>> rightfully
>>> >> > may
>>> >> > consider their presence as endorsement of using them as modules.
>>> >> >
>>> >> > That said, I can't seem to find split packages between engine and
>>> orm.
>>> >> > In
>>> >> > fact I can launch an application with both of them on the module
>>> path
>>> >> > just
>>> >> > fine. So there may be no problem actually?
>>> >>
>>> >> Interesting, I'm pretty sure we had some. We had several issues
>>> >> resolved over time to resolve them, I never realized we might have
>>> >> completed them all. The "line" defining what belongs where is still
>>> >> blurry though, we should make sure this won't have future regressions.
>>> >
>>> >
>>> > Where I had problems with split packages was when exploring HSearch @
>>> Java 9
>>> > modules last year was Lucene. In the version used back then (not sure
>>> > whether it's still an issue today), there was a split package between
>>> > Lucene's core and the util module (the one with the uninverting
>>> reader).
>>> >
>>> > You might take my example project I had created for running ORM as
>>> modules
>>> > (
>>> https://github.com/gunnarmorling/hibernate-orm-on-java9-modules/compare/orm-modularized
>>> )
>>> > if you're interested in doing the same for HSearch. IIRC, the Lucene
>>> split
>>> > package made me give up back then, it's surely worth taking another
>>> look
>>> > with the current versions in use.
>>> >>
>>> >>
>>> >> I'll see if we can produce fully fledged module-info descriptors then
>>> :)
>>> >>
>>> >> >
>>> >> >>
>>> >> >> # What I don't like:
>>> >> >> For one, that the typical application will need to import both
>>> >> >> `org.hibernate.search.engine` and `org.hibernate.search.orm`, and
>>> >> >> likely more as well (e.g. Elasticsearch API, Lucene API module is
>>> >> >> coming, ..).
>>> >> >
>>> >> >
>>> >> > I'm not exactly sure what you mean by "import" here. But if it's
>>> about
>>> >> > the
>>> >> > user having to declare dependences in their module descriptor to
>>> >> > o.h.s.engine and o.h.s.orm modules, you may consider to make the
>>> former
>>> >> > a
>>> >> > transitive dependence of the latter once you add actual module
>>> >> > descriptors:
>>> >> >
>>> >> >     module org.hibernate.search.orm {
>>> >> >         requires transitive org.hibernate.search.engine;
>>> >> >         ...
>>> >> >     }
>>> >> >
>>> >> > That way the user just has to add declare the dependence to
>>> o.h.s.orm.
>>> >> > That's definitely suitable if APIs in o.h.s.orm use types from
>>> engine in
>>> >> > their public API signatures.
>>> >>
>>> >> +1 that's the better option.
>>> >>
>>> >> My thought was about automatic module names though, but totally
>>> >> irrelevant if we go for full modules.
>>> >>
>>> >> Thanks,
>>> >> Sanne
>>> >>
>>> >> >
>>> >> >>
>>> >> >> Maybe similar to BOM's today we could publish a module which
>>> >> >> statically imports multiple of these, that could be nicer to use
>>> but
>>> >> >> we risk needing to publish (and document) one for each of a
>>> selection
>>> >> >> of combinations. So let's not start with such things yet.
>>> >> >>
>>> >> >> Thanks,
>>> >> >> Sanne
>>> >> >>
>>> >> >> [1]
>>> http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
>>> >> >> _______________________________________________
>>> >> >> hibernate-dev mailing list
>>> >> >> hibernate-dev at lists.jboss.org
>>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >> >
>>> >> >
>>> >
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> --
>> Yoann Rodiere
>> yoann at hibernate.org / yrodiere at redhat.com
>> Software Engineer
>> Hibernate NoORM team
>>
> --
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From rory.odonnell at oracle.com  Tue Feb 13 05:23:34 2018
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Tue, 13 Feb 2018 10:23:34 +0000
Subject: [hibernate-dev] JDK 10: First Release Candidate - JDK 10 b43
Message-ID: <f000619f-2f50-4a4b-e772-6ce1c920997b@oracle.com>

Hi Sanne,

*JDK 10 build 43 is our first JDK 10 Release Candidate [1]*

  * JDK 10 Early Access? build 43 is available at : - jdk.java.net/10/

Notable changes since previous email.**

*build 43
*

  * JDK-8194764 <https://bugs.openjdk.java.net/browse/JDK-8194764> -
    javac incorrectly flags deprecated for removal imports
  * JDK-8196678 <https://bugs.openjdk.java.net/browse/JDK-8196678> -
    avoid printing uninitialized buffer in os::print_memory_info on AIX
  * JDK-8195837 <https://bugs.openjdk.java.net/browse/JDK-8195837> -
    (tz) Upgrade time-zone data to tzdata2018c

**

*Bug fixes reported by Open Source Projects? :*

  * JDK-8196296 <https://bugs.openjdk.java.net/browse/JDK-8196296>
    Lucene test crashes C2 compilation

*Security Manager Survey
*

If you have written or maintain code that uses the SecurityManager or 
related APIs such as the AccessController,
then we would appreciate if you would complete this survey: 
https://www.surveymonkey.com/r/RSGMF3K
More info on the survey? [2]


Regards,
Rory

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000742.html
[2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000649.html

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


From sanne at hibernate.org  Tue Feb 13 05:42:48 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 13 Feb 2018 10:42:48 +0000
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CAEqagpoObS3DvgXkwg0xwu0D20LX4sQRupHc6fMfND2u1O_82Q@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
	<CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
	<CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
	<CADGJaX9mG=bz7izuxB+AJGWc9E51VFwJ_aix20B2R0SROWV9vg@mail.gmail.com>
	<CAFm4XO0R_Xn0U739ERHP+wKJmByPaeLH=3F9OrVhcivLUYQMUA@mail.gmail.com>
	<CAEqagpoObS3DvgXkwg0xwu0D20LX4sQRupHc6fMfND2u1O_82Q@mail.gmail.com>
Message-ID: <CAFm4XO26EK-8qHyXwSMtbp6eYi-hfs7uwPThTBYdpcy4m92tLA@mail.gmail.com>

On 13 February 2018 at 08:44, Yoann Rodiere <yoann at hibernate.org> wrote:
>> IMO automatic module names should only be declared after at least some
> basic vetting that these modules will actually work when used as modules.
> If that's not the case, I wouldn't add these headers, as users rightfully
> may consider their presence as endorsement of using them as modules.
>
> If I understood correctly, automatic module names were introduced to
> facilitate the transition to Jigsaw modules. The point was to allow projects
> to give a name to their modules, and, yes, declare them as ready, but even
> if they couldn't be made full modules yet because of their dependencies.
> Declaring a name doesn't mean the module will work, it means it will work
> when dependencies are fixed. If we wait for all of our dependencies to work
> in a modular environment before we give a name to our modules, we may very
> well never do it because of circular dependencies (Infinispan comes to mind:
> Infinispan-query depends on Search for, which depends on ORM, which depends
> on the Infinispan 2nd level cache provider).
> Declaring a full module-info.java is another matter, but as you mentioned,
> we simply can't do that yet because of split packages in Lucene.

Understood and agree. We should add the automatic module names to get
people unstuck, and I wouldn't propose this if I didn't have enough
confidence that they should work: we have some basic tests.


> Back to naming... It looks good and consistent with the current naming our
> Maven artifacts. In 6, I would probably choose to rename the Elasticsearch
> one to something like
> org.hibernate.search.<backendOrSomething>.elasticsearch, but we still have
> to coin the right term for "<backendOrSomething>", and I would probably
> rename the Maven artifact too, so that can wait.
>
> I think you forgot the JSR 352 integration, but I guess the name would be
> rather obvious:
>  - org.hibernate.search.jsr352

+1, thanks


> As to non-public APIs, can you confirm automatic modules can access the
> classpath transparently? If so then I agree, no need to name those....
> Except for the JMS backend: it is unusable without the user extending
> AbstractJMSHibernateSearchController, so this class at least must be exposed
> to the user. Even if it's just SPI.

That's the "guidelines" I was referring to in my first email.
We could give it a name, so let's suggest one, but I feel like this is
not essential as while we suggest people to extend our SPI, there are
alternatives to that.
I wanted to avoid this one at a first shot as it might be controversial ;)

Proposed name:
  - org.hibernate.search.jms-support

Why:
 # I'd like to avoid using "backend" in the name.
 # Makes it clear this is the module you want to add when you're into
JMS - or at the opposite if your system doesn't care about JMS.

IMO the goal of Jigsaw modules is to trim a system from unnecessary
stuff, so having the names express what kind of technologies it brings
in is most helpful.

Thanks,
Sanne

> On Tue, 13 Feb 2018 at 00:39 Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> The split package problem with Lucene won't easily go away, as we
>> can't upgrade Lucene now.
>>
>> But I vaguely remember working with you on that, didn't we figure out
>> that one of the Lucene modules wasn't essential?
>>
>> Either way, that's interesting to experiment with but we can't publish
>> full modules as almost none of our dependencies are ready; they should
>> at least all have an automatic module name.
>>
>> Thanks,
>> Sanne
>>
>> On 12 February 2018 at 19:43, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >
>> >
>> > 2018-02-12 19:28 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>
>> >> On 12 February 2018 at 18:00, Gunnar Morling <gunnar at hibernate.org>
>> >> wrote:
>> >> >
>> >> >
>> >> > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >> >>
>> >> >> Picking automatic module names for Hibernate Search isn't going to
>> >> >> be
>> >> >> straight-forward as our two main jars (hibernate-search-engine &
>> >> >> hibernate-search-orm) suffer from split package among them.
>> >> >>
>> >> >> We can't really fix the split package problem without breaking all
>> >> >> users, so if we want to consider that, we can debate it but that
>> >> >> will
>> >> >> need to happen at another round as we're doing a minor release, so
>> >> >> let's focus on:
>> >> >>  # Which names to pick
>> >> >>  # Should we pick the names at all
>> >> >>  # Which modules should have a name
>> >> >>
>> >> >> For a great background on the possible strategies and pitfalls I
>> >> >> recommend reading Stephen Colebourne's blog on this subject [1].
>> >> >> He persuaded me there are good reasons to use the "reverse DNS, the
>> >> >> top level package", however since we have the split package problem
>> >> >> we
>> >> >> can't simply go with that.
>> >> >>
>> >> >> Still, we can respect the principles he recommends with a small
>> >> >> variation. It's fair to assume that the `org.hibernate.search`
>> >> >> prefix
>> >> >> is "ours"; since the nature of the suggestion is focused on making
>> >> >> sure there are no misunderstandings in the community about which
>> >> >> names
>> >> >> you can choose - as there is no central authority making sure module
>> >> >> names aren't clashing - we should be fine within Hibernate projects
>> >> >> with any `org.hibernate.X` prefix, as long as we coordinate and
>> >> >> reach
>> >> >> an agreement on this list.
>> >> >>
>> >> >> So, I propose we use:
>> >> >>
>> >> >> Engine module:
>> >> >>  - org.hibernate.search.engine
>> >> >>
>> >> >> ORM integration module:
>> >> >>  - org.hibernate.search.orm
>> >> >>
>> >> > Those names sound good to me.
>> >> >
>> >> >>
>> >> >> JGroups, JMS backends:
>> >> >>   [ no automatic module name ? Excepting some "guidelines" in the
>> >> >> JMS
>> >> >> module, these are not public API so nobody would benefit from it -
>> >> >> also we think we might want to phase out the name "backend" in the
>> >> >> future ]
>> >> >>
>> >> >> Elasticsearch integration module
>> >> >> [hibernate-search-elasticsearch.jar]:
>> >> >>  - org.hibernate.search.elasticsearch
>> >> >>
>> >> >> Elasticsearch / AWS security integration:
>> >> >>  [ no automatic module name: no public API ]
>> >> >>
>> >> >> Serialization / Avro
>> >> >>  [ no automatic module name: no public API ]
>> >> >>
>> >> >> WDYT?
>> >> >
>> >> >
>> >> > The user may still need to reference those modules when launching a
>> >> > modularized application. Also if they don't directly declare say the
>> >> > JMS
>> >> > backend as a dependence of their own module, they'd still have to
>> >> > specify it
>> >> > via --add-modules, so to resolve these additional modules and add
>> >> > them
>> >> > to
>> >> > the module graph. Hence I'd declare automatic module names for these,
>> >> > too.
>> >>
>> >> Good point, I had not thought that our modules wouldn't be able to
>> >> load other extensions from classpath.
>> >>
>> >> >> We could also pick names for the ones which I've listed as "no
>> >> >> public
>> >> >> API" but I see no point: as we're only assigning an "Automatic
>> >> >> Module
>> >> >> Name" we won't be able to explicitly state that the other modules
>> >> >> depend on these. So nobody will use them, and things are a bit in
>> >> >> flux
>> >> >> anyway in this area because of Hibernate Search 6 plans.
>> >> >
>> >> >
>> >> > I don't fully understand this paragraph.
>> >>
>> >> You mostly invalidated it with the previous comment, but what I meant
>> >> is that we can't have the `org.hibernate.search.engine` declare a
>> >> dependency on any implementation module, as we're not adding a
>> >> module-info definition.
>> >>
>> >> >> Another optional altogether: since we have split packages which
>> >> >> we'll
>> >> >> have to resolve before we can actually transform these into fully
>> >> >> fledged modules, I think an acceptable position is also to say we
>> >> >> won't be publishing any automatic module name yet. Personally I'm
>> >> >> inclined to go with the names suggested above, at least some others
>> >> >> can start making baby steps, even if it's not all there.
>> >> >
>> >> >
>> >> > IMO automatic module names should only be declared after at least
>> >> > some
>> >> > basic
>> >> > vetting that these modules will actually work when used as modules.
>> >> > If
>> >> > that's not the case, I wouldn't add these headers, as users
>> >> > rightfully
>> >> > may
>> >> > consider their presence as endorsement of using them as modules.
>> >> >
>> >> > That said, I can't seem to find split packages between engine and
>> >> > orm.
>> >> > In
>> >> > fact I can launch an application with both of them on the module path
>> >> > just
>> >> > fine. So there may be no problem actually?
>> >>
>> >> Interesting, I'm pretty sure we had some. We had several issues
>> >> resolved over time to resolve them, I never realized we might have
>> >> completed them all. The "line" defining what belongs where is still
>> >> blurry though, we should make sure this won't have future regressions.
>> >
>> >
>> > Where I had problems with split packages was when exploring HSearch @
>> > Java 9
>> > modules last year was Lucene. In the version used back then (not sure
>> > whether it's still an issue today), there was a split package between
>> > Lucene's core and the util module (the one with the uninverting reader).
>> >
>> > You might take my example project I had created for running ORM as
>> > modules
>> >
>> > (https://github.com/gunnarmorling/hibernate-orm-on-java9-modules/compare/orm-modularized)
>> > if you're interested in doing the same for HSearch. IIRC, the Lucene
>> > split
>> > package made me give up back then, it's surely worth taking another look
>> > with the current versions in use.
>> >>
>> >>
>> >> I'll see if we can produce fully fledged module-info descriptors then
>> >> :)
>> >>
>> >> >
>> >> >>
>> >> >> # What I don't like:
>> >> >> For one, that the typical application will need to import both
>> >> >> `org.hibernate.search.engine` and `org.hibernate.search.orm`, and
>> >> >> likely more as well (e.g. Elasticsearch API, Lucene API module is
>> >> >> coming, ..).
>> >> >
>> >> >
>> >> > I'm not exactly sure what you mean by "import" here. But if it's
>> >> > about
>> >> > the
>> >> > user having to declare dependences in their module descriptor to
>> >> > o.h.s.engine and o.h.s.orm modules, you may consider to make the
>> >> > former
>> >> > a
>> >> > transitive dependence of the latter once you add actual module
>> >> > descriptors:
>> >> >
>> >> >     module org.hibernate.search.orm {
>> >> >         requires transitive org.hibernate.search.engine;
>> >> >         ...
>> >> >     }
>> >> >
>> >> > That way the user just has to add declare the dependence to
>> >> > o.h.s.orm.
>> >> > That's definitely suitable if APIs in o.h.s.orm use types from engine
>> >> > in
>> >> > their public API signatures.
>> >>
>> >> +1 that's the better option.
>> >>
>> >> My thought was about automatic module names though, but totally
>> >> irrelevant if we go for full modules.
>> >>
>> >> Thanks,
>> >> Sanne
>> >>
>> >> >
>> >> >>
>> >> >> Maybe similar to BOM's today we could publish a module which
>> >> >> statically imports multiple of these, that could be nicer to use but
>> >> >> we risk needing to publish (and document) one for each of a
>> >> >> selection
>> >> >> of combinations. So let's not start with such things yet.
>> >> >>
>> >> >> Thanks,
>> >> >> Sanne
>> >> >>
>> >> >> [1]
>> >> >> http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
>> >> >> _______________________________________________
>> >> >> hibernate-dev mailing list
>> >> >> hibernate-dev at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >
>> >> >
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> --
> Yoann Rodiere
> yoann at hibernate.org / yrodiere at redhat.com
> Software Engineer
> Hibernate NoORM team

From yoann at hibernate.org  Tue Feb 13 05:59:36 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Tue, 13 Feb 2018 10:59:36 +0000
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CAFm4XO26EK-8qHyXwSMtbp6eYi-hfs7uwPThTBYdpcy4m92tLA@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
	<CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
	<CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
	<CADGJaX9mG=bz7izuxB+AJGWc9E51VFwJ_aix20B2R0SROWV9vg@mail.gmail.com>
	<CAFm4XO0R_Xn0U739ERHP+wKJmByPaeLH=3F9OrVhcivLUYQMUA@mail.gmail.com>
	<CAEqagpoObS3DvgXkwg0xwu0D20LX4sQRupHc6fMfND2u1O_82Q@mail.gmail.com>
	<CAFm4XO26EK-8qHyXwSMtbp6eYi-hfs7uwPThTBYdpcy4m92tLA@mail.gmail.com>
Message-ID: <CAEqagpppLa7YhQ63oeQuYSRoPvNSfBWzEdEbAFosmCVWqLWteA@mail.gmail.com>

>   - org.hibernate.search.jms-support

Not sure it's a valid name (aren't hyphens forbidden in package names, and
aren't module names constrained by the same rules?), but apart from that it
looks good. Maybe "jms_support" instead, if "jms-support" is not allowed.
I would like to find a name for what the JMS and JGroups modules provide in
Hibernate Search 6 though, something less misleading than "backend".
Something like "work routing" or "clustering support" or "distribution
support" or whatever. Would you be ok with changing the module name in 6?
If not, maybe we have to think about it now... Note that we'll change the
Maven group ID anyway, so it's arguably just another breaking change.

On Tue, 13 Feb 2018 at 11:43 Sanne Grinovero <sanne at hibernate.org> wrote:

> On 13 February 2018 at 08:44, Yoann Rodiere <yoann at hibernate.org> wrote:
> >> IMO automatic module names should only be declared after at least some
> > basic vetting that these modules will actually work when used as modules.
> > If that's not the case, I wouldn't add these headers, as users rightfully
> > may consider their presence as endorsement of using them as modules.
> >
> > If I understood correctly, automatic module names were introduced to
> > facilitate the transition to Jigsaw modules. The point was to allow
> projects
> > to give a name to their modules, and, yes, declare them as ready, but
> even
> > if they couldn't be made full modules yet because of their dependencies.
> > Declaring a name doesn't mean the module will work, it means it will work
> > when dependencies are fixed. If we wait for all of our dependencies to
> work
> > in a modular environment before we give a name to our modules, we may
> very
> > well never do it because of circular dependencies (Infinispan comes to
> mind:
> > Infinispan-query depends on Search for, which depends on ORM, which
> depends
> > on the Infinispan 2nd level cache provider).
> > Declaring a full module-info.java is another matter, but as you
> mentioned,
> > we simply can't do that yet because of split packages in Lucene.
>
> Understood and agree. We should add the automatic module names to get
> people unstuck, and I wouldn't propose this if I didn't have enough
> confidence that they should work: we have some basic tests.
>
>
> > Back to naming... It looks good and consistent with the current naming
> our
> > Maven artifacts. In 6, I would probably choose to rename the
> Elasticsearch
> > one to something like
> > org.hibernate.search.<backendOrSomething>.elasticsearch, but we still
> have
> > to coin the right term for "<backendOrSomething>", and I would probably
> > rename the Maven artifact too, so that can wait.
> >
> > I think you forgot the JSR 352 integration, but I guess the name would be
> > rather obvious:
> >  - org.hibernate.search.jsr352
>
> +1, thanks
>
>
> > As to non-public APIs, can you confirm automatic modules can access the
> > classpath transparently? If so then I agree, no need to name those....
> > Except for the JMS backend: it is unusable without the user extending
> > AbstractJMSHibernateSearchController, so this class at least must be
> exposed
> > to the user. Even if it's just SPI.
>
> That's the "guidelines" I was referring to in my first email.
> We could give it a name, so let's suggest one, but I feel like this is
> not essential as while we suggest people to extend our SPI, there are
> alternatives to that.
> I wanted to avoid this one at a first shot as it might be controversial ;)
>
> Proposed name:
>   - org.hibernate.search.jms-support
>
> Why:
>  # I'd like to avoid using "backend" in the name.
>  # Makes it clear this is the module you want to add when you're into
> JMS - or at the opposite if your system doesn't care about JMS.
>
> IMO the goal of Jigsaw modules is to trim a system from unnecessary
> stuff, so having the names express what kind of technologies it brings
> in is most helpful.
>
> Thanks,
> Sanne
>
> > On Tue, 13 Feb 2018 at 00:39 Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> The split package problem with Lucene won't easily go away, as we
> >> can't upgrade Lucene now.
> >>
> >> But I vaguely remember working with you on that, didn't we figure out
> >> that one of the Lucene modules wasn't essential?
> >>
> >> Either way, that's interesting to experiment with but we can't publish
> >> full modules as almost none of our dependencies are ready; they should
> >> at least all have an automatic module name.
> >>
> >> Thanks,
> >> Sanne
> >>
> >> On 12 February 2018 at 19:43, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >> >
> >> >
> >> > 2018-02-12 19:28 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >> >>
> >> >> On 12 February 2018 at 18:00, Gunnar Morling <gunnar at hibernate.org>
> >> >> wrote:
> >> >> >
> >> >> >
> >> >> > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >> >> >>
> >> >> >> Picking automatic module names for Hibernate Search isn't going to
> >> >> >> be
> >> >> >> straight-forward as our two main jars (hibernate-search-engine &
> >> >> >> hibernate-search-orm) suffer from split package among them.
> >> >> >>
> >> >> >> We can't really fix the split package problem without breaking all
> >> >> >> users, so if we want to consider that, we can debate it but that
> >> >> >> will
> >> >> >> need to happen at another round as we're doing a minor release, so
> >> >> >> let's focus on:
> >> >> >>  # Which names to pick
> >> >> >>  # Should we pick the names at all
> >> >> >>  # Which modules should have a name
> >> >> >>
> >> >> >> For a great background on the possible strategies and pitfalls I
> >> >> >> recommend reading Stephen Colebourne's blog on this subject [1].
> >> >> >> He persuaded me there are good reasons to use the "reverse DNS,
> the
> >> >> >> top level package", however since we have the split package
> problem
> >> >> >> we
> >> >> >> can't simply go with that.
> >> >> >>
> >> >> >> Still, we can respect the principles he recommends with a small
> >> >> >> variation. It's fair to assume that the `org.hibernate.search`
> >> >> >> prefix
> >> >> >> is "ours"; since the nature of the suggestion is focused on making
> >> >> >> sure there are no misunderstandings in the community about which
> >> >> >> names
> >> >> >> you can choose - as there is no central authority making sure
> module
> >> >> >> names aren't clashing - we should be fine within Hibernate
> projects
> >> >> >> with any `org.hibernate.X` prefix, as long as we coordinate and
> >> >> >> reach
> >> >> >> an agreement on this list.
> >> >> >>
> >> >> >> So, I propose we use:
> >> >> >>
> >> >> >> Engine module:
> >> >> >>  - org.hibernate.search.engine
> >> >> >>
> >> >> >> ORM integration module:
> >> >> >>  - org.hibernate.search.orm
> >> >> >>
> >> >> > Those names sound good to me.
> >> >> >
> >> >> >>
> >> >> >> JGroups, JMS backends:
> >> >> >>   [ no automatic module name ? Excepting some "guidelines" in the
> >> >> >> JMS
> >> >> >> module, these are not public API so nobody would benefit from it -
> >> >> >> also we think we might want to phase out the name "backend" in the
> >> >> >> future ]
> >> >> >>
> >> >> >> Elasticsearch integration module
> >> >> >> [hibernate-search-elasticsearch.jar]:
> >> >> >>  - org.hibernate.search.elasticsearch
> >> >> >>
> >> >> >> Elasticsearch / AWS security integration:
> >> >> >>  [ no automatic module name: no public API ]
> >> >> >>
> >> >> >> Serialization / Avro
> >> >> >>  [ no automatic module name: no public API ]
> >> >> >>
> >> >> >> WDYT?
> >> >> >
> >> >> >
> >> >> > The user may still need to reference those modules when launching a
> >> >> > modularized application. Also if they don't directly declare say
> the
> >> >> > JMS
> >> >> > backend as a dependence of their own module, they'd still have to
> >> >> > specify it
> >> >> > via --add-modules, so to resolve these additional modules and add
> >> >> > them
> >> >> > to
> >> >> > the module graph. Hence I'd declare automatic module names for
> these,
> >> >> > too.
> >> >>
> >> >> Good point, I had not thought that our modules wouldn't be able to
> >> >> load other extensions from classpath.
> >> >>
> >> >> >> We could also pick names for the ones which I've listed as "no
> >> >> >> public
> >> >> >> API" but I see no point: as we're only assigning an "Automatic
> >> >> >> Module
> >> >> >> Name" we won't be able to explicitly state that the other modules
> >> >> >> depend on these. So nobody will use them, and things are a bit in
> >> >> >> flux
> >> >> >> anyway in this area because of Hibernate Search 6 plans.
> >> >> >
> >> >> >
> >> >> > I don't fully understand this paragraph.
> >> >>
> >> >> You mostly invalidated it with the previous comment, but what I meant
> >> >> is that we can't have the `org.hibernate.search.engine` declare a
> >> >> dependency on any implementation module, as we're not adding a
> >> >> module-info definition.
> >> >>
> >> >> >> Another optional altogether: since we have split packages which
> >> >> >> we'll
> >> >> >> have to resolve before we can actually transform these into fully
> >> >> >> fledged modules, I think an acceptable position is also to say we
> >> >> >> won't be publishing any automatic module name yet. Personally I'm
> >> >> >> inclined to go with the names suggested above, at least some
> others
> >> >> >> can start making baby steps, even if it's not all there.
> >> >> >
> >> >> >
> >> >> > IMO automatic module names should only be declared after at least
> >> >> > some
> >> >> > basic
> >> >> > vetting that these modules will actually work when used as modules.
> >> >> > If
> >> >> > that's not the case, I wouldn't add these headers, as users
> >> >> > rightfully
> >> >> > may
> >> >> > consider their presence as endorsement of using them as modules.
> >> >> >
> >> >> > That said, I can't seem to find split packages between engine and
> >> >> > orm.
> >> >> > In
> >> >> > fact I can launch an application with both of them on the module
> path
> >> >> > just
> >> >> > fine. So there may be no problem actually?
> >> >>
> >> >> Interesting, I'm pretty sure we had some. We had several issues
> >> >> resolved over time to resolve them, I never realized we might have
> >> >> completed them all. The "line" defining what belongs where is still
> >> >> blurry though, we should make sure this won't have future
> regressions.
> >> >
> >> >
> >> > Where I had problems with split packages was when exploring HSearch @
> >> > Java 9
> >> > modules last year was Lucene. In the version used back then (not sure
> >> > whether it's still an issue today), there was a split package between
> >> > Lucene's core and the util module (the one with the uninverting
> reader).
> >> >
> >> > You might take my example project I had created for running ORM as
> >> > modules
> >> >
> >> > (
> https://github.com/gunnarmorling/hibernate-orm-on-java9-modules/compare/orm-modularized
> )
> >> > if you're interested in doing the same for HSearch. IIRC, the Lucene
> >> > split
> >> > package made me give up back then, it's surely worth taking another
> look
> >> > with the current versions in use.
> >> >>
> >> >>
> >> >> I'll see if we can produce fully fledged module-info descriptors then
> >> >> :)
> >> >>
> >> >> >
> >> >> >>
> >> >> >> # What I don't like:
> >> >> >> For one, that the typical application will need to import both
> >> >> >> `org.hibernate.search.engine` and `org.hibernate.search.orm`, and
> >> >> >> likely more as well (e.g. Elasticsearch API, Lucene API module is
> >> >> >> coming, ..).
> >> >> >
> >> >> >
> >> >> > I'm not exactly sure what you mean by "import" here. But if it's
> >> >> > about
> >> >> > the
> >> >> > user having to declare dependences in their module descriptor to
> >> >> > o.h.s.engine and o.h.s.orm modules, you may consider to make the
> >> >> > former
> >> >> > a
> >> >> > transitive dependence of the latter once you add actual module
> >> >> > descriptors:
> >> >> >
> >> >> >     module org.hibernate.search.orm {
> >> >> >         requires transitive org.hibernate.search.engine;
> >> >> >         ...
> >> >> >     }
> >> >> >
> >> >> > That way the user just has to add declare the dependence to
> >> >> > o.h.s.orm.
> >> >> > That's definitely suitable if APIs in o.h.s.orm use types from
> engine
> >> >> > in
> >> >> > their public API signatures.
> >> >>
> >> >> +1 that's the better option.
> >> >>
> >> >> My thought was about automatic module names though, but totally
> >> >> irrelevant if we go for full modules.
> >> >>
> >> >> Thanks,
> >> >> Sanne
> >> >>
> >> >> >
> >> >> >>
> >> >> >> Maybe similar to BOM's today we could publish a module which
> >> >> >> statically imports multiple of these, that could be nicer to use
> but
> >> >> >> we risk needing to publish (and document) one for each of a
> >> >> >> selection
> >> >> >> of combinations. So let's not start with such things yet.
> >> >> >>
> >> >> >> Thanks,
> >> >> >> Sanne
> >> >> >>
> >> >> >> [1]
> >> >> >>
> http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
> >> >> >> _______________________________________________
> >> >> >> hibernate-dev mailing list
> >> >> >> hibernate-dev at lists.jboss.org
> >> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> >
> >> >> >
> >> >
> >> >
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > --
> > Yoann Rodiere
> > yoann at hibernate.org / yrodiere at redhat.com
> > Software Engineer
> > Hibernate NoORM team
>
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From gunnar at hibernate.org  Tue Feb 13 06:14:41 2018
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 13 Feb 2018 12:14:41 +0100
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CAEqagpoWYqmiMfgoELd2QiPufHqfgMvhDK6ZBZG+JtavUKGNow@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
	<CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
	<CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
	<CADGJaX9mG=bz7izuxB+AJGWc9E51VFwJ_aix20B2R0SROWV9vg@mail.gmail.com>
	<CAFm4XO0R_Xn0U739ERHP+wKJmByPaeLH=3F9OrVhcivLUYQMUA@mail.gmail.com>
	<CAEqagpoObS3DvgXkwg0xwu0D20LX4sQRupHc6fMfND2u1O_82Q@mail.gmail.com>
	<CADGJaX_AhMmqhDdLUqG23B=n4R=iOZRJXUPmPu+csQgmkHK+nA@mail.gmail.com>
	<CAEqagpoWYqmiMfgoELd2QiPufHqfgMvhDK6ZBZG+JtavUKGNow@mail.gmail.com>
Message-ID: <CADGJaX8-uOOtHorhJxg3ej9MKv08TO4HV9a9MkTHtt4KeMxSTQ@mail.gmail.com>

2018-02-13 11:04 GMT+01:00 Yoann Rodiere <yoann at hibernate.org>:

> > How can you be sure of that though without trying it out?
>
> If what you meant by "work as modules" was "work as *automatic* modules"
> (i.e. with dependencies in the classpath), we already test that. We just
> happen to know they can't work as "full" modules (with module-info) yet.
>

Automatic modules don't imply "dependencies in the classpath". While they
*can* read everything from the unnamed module, they also read all resolved
real modules (automatic or named ones). I'd recommend to gain some
certainty that things work when only using the module path. As said, tool
support isn't great for mixing them from what I know.

>
> > If there are cycles, problems go far beyond finding good names. The
> default resolver will not allow cycles between modules.
>
> The cycles are merely between projects, not between modules. It's more a
> release issue than a technical issue. The problem arises mainly from the
> fact that Infinispan has two sides: the server, and the client libraries. I
> guess one way to do it would be for Infinispan to first switch to Jigsaw
> modules for their core modules and client library modules, then we do the
> switch on our side, then they can do the switch for their server modules.
> But I would expect such plan to be slower than switching to automatic
> modules first, then to full modules when every dependency is ready.
> In any case, there shouldn't be a problem at runtime, so it shouldn't
> prevent us from running Jigsaw modules once they are ready, but it's still
> a problem to do the switch to full Jigsaw modules.
>
> > Automatic modules can access the classpath (which is represented by the
> UNNAMED module, and all automatic modules read that).
>
> Thanks for confirming that.
>
> > But I wouldn't recommend to rely on such mixed set-up as it's cumbersome
> to configure. For instance for an app with a module-info.java, Maven will
> put all dependencies to the module path when invoking javac; if you wanted
> to have some deps on the classpath and some on the module path, that'd be
> some manual effort. Hence my suggestion to give automatic module names to
> all of them and using them on the module path.
>
> Let me get this straight: I want to just define automatic module names
> for our modules, but still rely exclusively on the classpath for our own
> dependencies, including internal ones (dependencies from one of our modules
> to another of our own modules).
> Are you saying this is not possible?
>

No, that's not what I'm saying. This is possible, but it's not what I'd
recommend. I.e. also the backends should be provided on the module path,
and for that they should have defined automatic module names, so users
don't need to reference implict names in their --add-modules options.


> I.e. once a jar is promoted to automatic module, it is not visible from
> other automatic modules anymore?
>

No, see above.

Because the alternative doesn't seem workable either: declaring our
> dependencies as module dependencies (e.g. in a module-info) would not give
> us the option to have classpath dependencies (or would it?), and thus we
> would not be able to depend on Lucene...
>

I'm not quite following on this reasoning. But yes, a named module
shouldn't depend on the UNNAMED module. But as per my previous mail you
should be able to use Lucene as automatic modules (i.e. on the module path)
as long as you exclude the lucene.misc module which shouldn't be too
difficult as described.

>
>
>
> On Tue, 13 Feb 2018 at 10:08 Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> 2018-02-13 9:44 GMT+01:00 Yoann Rodiere <yoann at hibernate.org>:
>>
>>> > IMO automatic module names should only be declared after at least some
>>> basic vetting that these modules will actually work when used as modules.
>>> If that's not the case, I wouldn't add these headers, as users rightfully
>>> may consider their presence as endorsement of using them as modules.
>>>
>>> If I understood correctly, automatic module names were introduced to
>>> facilitate the transition to Jigsaw modules. The point was to allow
>>> projects to give a name to their modules, and, yes, declare them as ready,
>>> but even if they couldn't be made full modules yet because of their
>>> dependencies. Declaring a name doesn't mean the module will work, it means
>>> it will work *when dependencies are fixed*.
>>>
>>
>> How can you be sure of that though without trying it out?
>>
>>
>>> If we wait for all of our dependencies to work in a modular environment
>>> before we give a name to our modules, we may very well never do it because
>>> of circular dependencies (Infinispan comes to mind: Infinispan-query depends
>>> on Search for, which depends on ORM, which depends on the Infinispan 2nd
>>> level cache provider).
>>>
>>
>> If there are cycles, problems go far beyond finding good names. The
>> default resolver will not allow cycles between modules.
>>
>>
>>> Declaring a full module-info.java is another matter, but as you
>>> mentioned, we simply can't do that yet because of split packages in Lucene.
>>>
>>> Back to naming... It looks good and consistent with the current naming
>>> our Maven artifacts. In 6, I would probably choose to rename the
>>> Elasticsearch one to something like org.hibernate.search.<
>>> backendOrSomething>.elasticsearch, but we still have to coin the right
>>> term for "<backendOrSomething>", and I would probably rename the Maven
>>> artifact too, so that can wait.
>>>
>>> I think you forgot the JSR 352 integration, but I guess the name would
>>> be rather obvious:
>>>  - org.hibernate.search.jsr352
>>>
>>> As to non-public APIs, can you confirm automatic modules can access the
>>> classpath transparently? If so then I agree, no need to name those....
>>> Except for the JMS backend: it is unusable without the user extending
>>> AbstractJMSHibernateSearchController, so this class at least must be
>>> exposed to the user. Even if it's just SPI.
>>>
>>
>> Automatic modules can access the classpath (which is represented by the
>> UNNAMED module, and all automatic modules read that).
>>
>> But I wouldn't recommend to rely on such mixed set-up as it's cumbersome
>> to configure. For instance for an app with a module-info.java, Maven
>> will put all dependencies to the module path when invoking javac; if you
>> wanted to have some deps on the classpath and some on the module path,
>> that'd be some manual effort. Hence my suggestion to give automatic module
>> names to all of them and using them on the module path.
>>
>>
>>> On Tue, 13 Feb 2018 at 00:39 Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>>
>>>> The split package problem with Lucene won't easily go away, as we
>>>> can't upgrade Lucene now.
>>>>
>>>> But I vaguely remember working with you on that, didn't we figure out
>>>> that one of the Lucene modules wasn't essential?
>>>>
>>>> Either way, that's interesting to experiment with but we can't publish
>>>> full modules as almost none of our dependencies are ready; they should
>>>> at least all have an automatic module name.
>>>>
>>>> Thanks,
>>>> Sanne
>>>>
>>>> On 12 February 2018 at 19:43, Gunnar Morling <gunnar at hibernate.org>
>>>> wrote:
>>>> >
>>>> >
>>>> > 2018-02-12 19:28 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>>> >>
>>>> >> On 12 February 2018 at 18:00, Gunnar Morling <gunnar at hibernate.org>
>>>> wrote:
>>>> >> >
>>>> >> >
>>>> >> > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>>> >> >>
>>>> >> >> Picking automatic module names for Hibernate Search isn't going
>>>> to be
>>>> >> >> straight-forward as our two main jars (hibernate-search-engine &
>>>> >> >> hibernate-search-orm) suffer from split package among them.
>>>> >> >>
>>>> >> >> We can't really fix the split package problem without breaking all
>>>> >> >> users, so if we want to consider that, we can debate it but that
>>>> will
>>>> >> >> need to happen at another round as we're doing a minor release, so
>>>> >> >> let's focus on:
>>>> >> >>  # Which names to pick
>>>> >> >>  # Should we pick the names at all
>>>> >> >>  # Which modules should have a name
>>>> >> >>
>>>> >> >> For a great background on the possible strategies and pitfalls I
>>>> >> >> recommend reading Stephen Colebourne's blog on this subject [1].
>>>> >> >> He persuaded me there are good reasons to use the "reverse DNS,
>>>> the
>>>> >> >> top level package", however since we have the split package
>>>> problem we
>>>> >> >> can't simply go with that.
>>>> >> >>
>>>> >> >> Still, we can respect the principles he recommends with a small
>>>> >> >> variation. It's fair to assume that the `org.hibernate.search`
>>>> prefix
>>>> >> >> is "ours"; since the nature of the suggestion is focused on making
>>>> >> >> sure there are no misunderstandings in the community about which
>>>> names
>>>> >> >> you can choose - as there is no central authority making sure
>>>> module
>>>> >> >> names aren't clashing - we should be fine within Hibernate
>>>> projects
>>>> >> >> with any `org.hibernate.X` prefix, as long as we coordinate and
>>>> reach
>>>> >> >> an agreement on this list.
>>>> >> >>
>>>> >> >> So, I propose we use:
>>>> >> >>
>>>> >> >> Engine module:
>>>> >> >>  - org.hibernate.search.engine
>>>> >> >>
>>>> >> >> ORM integration module:
>>>> >> >>  - org.hibernate.search.orm
>>>> >> >>
>>>> >> > Those names sound good to me.
>>>> >> >
>>>> >> >>
>>>> >> >> JGroups, JMS backends:
>>>> >> >>   [ no automatic module name ? Excepting some "guidelines" in the
>>>> JMS
>>>> >> >> module, these are not public API so nobody would benefit from it -
>>>> >> >> also we think we might want to phase out the name "backend" in the
>>>> >> >> future ]
>>>> >> >>
>>>> >> >> Elasticsearch integration module [hibernate-search-
>>>> elasticsearch.jar]:
>>>> >> >>  - org.hibernate.search.elasticsearch
>>>> >> >>
>>>> >> >> Elasticsearch / AWS security integration:
>>>> >> >>  [ no automatic module name: no public API ]
>>>> >> >>
>>>> >> >> Serialization / Avro
>>>> >> >>  [ no automatic module name: no public API ]
>>>> >> >>
>>>> >> >> WDYT?
>>>> >> >
>>>> >> >
>>>> >> > The user may still need to reference those modules when launching a
>>>> >> > modularized application. Also if they don't directly declare say
>>>> the JMS
>>>> >> > backend as a dependence of their own module, they'd still have to
>>>> >> > specify it
>>>> >> > via --add-modules, so to resolve these additional modules and add
>>>> them
>>>> >> > to
>>>> >> > the module graph. Hence I'd declare automatic module names for
>>>> these,
>>>> >> > too.
>>>> >>
>>>> >> Good point, I had not thought that our modules wouldn't be able to
>>>> >> load other extensions from classpath.
>>>> >>
>>>> >> >> We could also pick names for the ones which I've listed as "no
>>>> public
>>>> >> >> API" but I see no point: as we're only assigning an "Automatic
>>>> Module
>>>> >> >> Name" we won't be able to explicitly state that the other modules
>>>> >> >> depend on these. So nobody will use them, and things are a bit in
>>>> flux
>>>> >> >> anyway in this area because of Hibernate Search 6 plans.
>>>> >> >
>>>> >> >
>>>> >> > I don't fully understand this paragraph.
>>>> >>
>>>> >> You mostly invalidated it with the previous comment, but what I meant
>>>> >> is that we can't have the `org.hibernate.search.engine` declare a
>>>> >> dependency on any implementation module, as we're not adding a
>>>> >> module-info definition.
>>>> >>
>>>> >> >> Another optional altogether: since we have split packages which
>>>> we'll
>>>> >> >> have to resolve before we can actually transform these into fully
>>>> >> >> fledged modules, I think an acceptable position is also to say we
>>>> >> >> won't be publishing any automatic module name yet. Personally I'm
>>>> >> >> inclined to go with the names suggested above, at least some
>>>> others
>>>> >> >> can start making baby steps, even if it's not all there.
>>>> >> >
>>>> >> >
>>>> >> > IMO automatic module names should only be declared after at least
>>>> some
>>>> >> > basic
>>>> >> > vetting that these modules will actually work when used as
>>>> modules. If
>>>> >> > that's not the case, I wouldn't add these headers, as users
>>>> rightfully
>>>> >> > may
>>>> >> > consider their presence as endorsement of using them as modules.
>>>> >> >
>>>> >> > That said, I can't seem to find split packages between engine and
>>>> orm.
>>>> >> > In
>>>> >> > fact I can launch an application with both of them on the module
>>>> path
>>>> >> > just
>>>> >> > fine. So there may be no problem actually?
>>>> >>
>>>> >> Interesting, I'm pretty sure we had some. We had several issues
>>>> >> resolved over time to resolve them, I never realized we might have
>>>> >> completed them all. The "line" defining what belongs where is still
>>>> >> blurry though, we should make sure this won't have future
>>>> regressions.
>>>> >
>>>> >
>>>> > Where I had problems with split packages was when exploring HSearch @
>>>> Java 9
>>>> > modules last year was Lucene. In the version used back then (not sure
>>>> > whether it's still an issue today), there was a split package between
>>>> > Lucene's core and the util module (the one with the uninverting
>>>> reader).
>>>> >
>>>> > You might take my example project I had created for running ORM as
>>>> modules
>>>> > (https://github.com/gunnarmorling/hibernate-orm-
>>>> on-java9-modules/compare/orm-modularized)
>>>> > if you're interested in doing the same for HSearch. IIRC, the Lucene
>>>> split
>>>> > package made me give up back then, it's surely worth taking another
>>>> look
>>>> > with the current versions in use.
>>>> >>
>>>> >>
>>>> >> I'll see if we can produce fully fledged module-info descriptors
>>>> then :)
>>>> >>
>>>> >> >
>>>> >> >>
>>>> >> >> # What I don't like:
>>>> >> >> For one, that the typical application will need to import both
>>>> >> >> `org.hibernate.search.engine` and `org.hibernate.search.orm`, and
>>>> >> >> likely more as well (e.g. Elasticsearch API, Lucene API module is
>>>> >> >> coming, ..).
>>>> >> >
>>>> >> >
>>>> >> > I'm not exactly sure what you mean by "import" here. But if it's
>>>> about
>>>> >> > the
>>>> >> > user having to declare dependences in their module descriptor to
>>>> >> > o.h.s.engine and o.h.s.orm modules, you may consider to make the
>>>> former
>>>> >> > a
>>>> >> > transitive dependence of the latter once you add actual module
>>>> >> > descriptors:
>>>> >> >
>>>> >> >     module org.hibernate.search.orm {
>>>> >> >         requires transitive org.hibernate.search.engine;
>>>> >> >         ...
>>>> >> >     }
>>>> >> >
>>>> >> > That way the user just has to add declare the dependence to
>>>> o.h.s.orm.
>>>> >> > That's definitely suitable if APIs in o.h.s.orm use types from
>>>> engine in
>>>> >> > their public API signatures.
>>>> >>
>>>> >> +1 that's the better option.
>>>> >>
>>>> >> My thought was about automatic module names though, but totally
>>>> >> irrelevant if we go for full modules.
>>>> >>
>>>> >> Thanks,
>>>> >> Sanne
>>>> >>
>>>> >> >
>>>> >> >>
>>>> >> >> Maybe similar to BOM's today we could publish a module which
>>>> >> >> statically imports multiple of these, that could be nicer to use
>>>> but
>>>> >> >> we risk needing to publish (and document) one for each of a
>>>> selection
>>>> >> >> of combinations. So let's not start with such things yet.
>>>> >> >>
>>>> >> >> Thanks,
>>>> >> >> Sanne
>>>> >> >>
>>>> >> >> [1] http://blog.joda.org/2017/05/java-se-9-jpms-automatic-
>>>> modules.html
>>>> >> >> _______________________________________________
>>>> >> >> hibernate-dev mailing list
>>>> >> >> hibernate-dev at lists.jboss.org
>>>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>> --
>>> Yoann Rodiere
>>> yoann at hibernate.org / yrodiere at redhat.com
>>> Software Engineer
>>> Hibernate NoORM team
>>>
>> --
> Yoann Rodiere
> yoann at hibernate.org / yrodiere at redhat.com
> Software Engineer
> Hibernate NoORM team
>

From sanne at hibernate.org  Tue Feb 13 06:35:57 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 13 Feb 2018 11:35:57 +0000
Subject: [hibernate-dev] HCANN 6
Message-ID: <CAFm4XO0G_KCjN5in8dkrbCe_=uWvMkukY2KnoueOBeuwoB6_xg@mail.gmail.com>

I'd like to push some updates to Hibernate Commons Annotations, looks
like a good time to plan it as a 6.0 release to nicely align with
plans of our other projects.

I plan to:
 - bump its version to 6.0.0-SNAPSHOT
 - upgrade the Gradle build
 - upgrade its dependencies to latest (which means just JBoss Logger)
 - baseline the requirement to Java 8 (still was on old Java 6 bytecode)
 - merge the one open PR: looks good to me and we were not confident
on merging it in 5.x
 - if possible, include a proper Jigsaw module definition.

Any objections? I hope not as I've already mostly done it all locally ;)

I'll create JIRA issues soon.

Thanks,
Sanne

From guillaume.smet at gmail.com  Tue Feb 13 06:48:05 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 13 Feb 2018 12:48:05 +0100
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CAEqagpppLa7YhQ63oeQuYSRoPvNSfBWzEdEbAFosmCVWqLWteA@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
	<CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
	<CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
	<CADGJaX9mG=bz7izuxB+AJGWc9E51VFwJ_aix20B2R0SROWV9vg@mail.gmail.com>
	<CAFm4XO0R_Xn0U739ERHP+wKJmByPaeLH=3F9OrVhcivLUYQMUA@mail.gmail.com>
	<CAEqagpoObS3DvgXkwg0xwu0D20LX4sQRupHc6fMfND2u1O_82Q@mail.gmail.com>
	<CAFm4XO26EK-8qHyXwSMtbp6eYi-hfs7uwPThTBYdpcy4m92tLA@mail.gmail.com>
	<CAEqagpppLa7YhQ63oeQuYSRoPvNSfBWzEdEbAFosmCVWqLWteA@mail.gmail.com>
Message-ID: <CALt0+o8Z8THJc7cPhnXHquqX-qn4kKHKya7V2902CjYdgk+PyQ@mail.gmail.com>

On Tue, Feb 13, 2018 at 11:59 AM, Yoann Rodiere <yoann at hibernate.org> wrote:

> >   - org.hibernate.search.jms-support
>
> Not sure it's a valid name (aren't hyphens forbidden in package names, and
> aren't module names constrained by the same rules?), but apart from that it
> looks good. Maybe "jms_support" instead, if "jms-support" is not allowed.
> I would like to find a name for what the JMS and JGroups modules provide in
> Hibernate Search 6 though, something less misleading than "backend".
> Something like "work routing" or "clustering support" or "distribution
> support" or whatever. Would you be ok with changing the module name in 6?
> If not, maybe we have to think about it now... Note that we'll change the
> Maven group ID anyway, so it's arguably just another breaking change.
>

+1 to find a distinctive name for JGroups and JMS artifacts and same for
Lucene and Elasticsearch (either this round or for 6).

org.hibernate.search.clustering.jms
org.hibernate.search.clustering.jgroups

and

org.hibernate.search.indexing.lucene
org.hibernate.search.indexing.elasticsearch

would be my choice as it's very understandable by the end user.

It might be an orthogonal discussion so feel free to ignore me :).

-- 
Guillaume

From daltodavide at gmail.com  Tue Feb 13 08:08:13 2018
From: daltodavide at gmail.com (Davide D'Alto)
Date: Tue, 13 Feb 2018 13:08:13 +0000
Subject: [hibernate-dev] Jenkins Updates on Friday
Message-ID: <CANoTJYM6SdL772+pYiuqBuW6yctuwpJuLPgV+_JJ92O2bo0C3g@mail.gmail.com>

Hi,
I'm going to run some updates on Jenkins this Friday.

They are minor updates and should be painless but you never know.

Cheers,
Davide

From lalmeras at gmail.com  Tue Feb 13 09:15:05 2018
From: lalmeras at gmail.com (Laurent Almeras)
Date: Tue, 13 Feb 2018 15:15:05 +0100
Subject: [hibernate-dev] Some insight about HHH-12101 / remove HQL-style
 positional parameters
In-Reply-To: <CAFdSV9uEL3gXTiWrj=L7b-qwfj2sV4fRYujb-6vka08Mftb+pg@mail.gmail.com>
References: <45104e7b-6032-db91-14dd-7ba0f6405641@gmail.com>
	<cbdb45f7-8ebf-0c90-9d43-3c6dc9ebec6d@gmail.com>
	<CAFdSV9vY=3cVgbRcJZ0_jQ_Kg-gUSQUsp2tftx0HaAQ0kxzGpA@mail.gmail.com>
	<66af1316-dc1a-c3a1-a6dd-4bc0fc897ee7@laposte.net>
	<CAFdSV9uGHPiepyqXKBf_ir0tAzbzgqM_3G+6yQ17wtdQcYswiw@mail.gmail.com>
	<CAFdSV9uEL3gXTiWrj=L7b-qwfj2sV4fRYujb-6vka08Mftb+pg@mail.gmail.com>
Message-ID: <8cffafb3-32a0-6b65-496c-d528abffa978@gmail.com>

Thanks for your feedback.

As I currently use QueryDSL generated queries, it's not easy to switch 
the way my queries are generated.

I post an issue with a github branch with some simple test-cases here: 
https://hibernate.atlassian.net/browse/HHH-12290


Laurent Almeras


Le 07/02/2018 ? 19:43, Steve Ebersole a ?crit?:
> And I did say that this is indeed a problem assuming you are right, 
> and I have no reason to believe you are not.? In fact I can see how 
> that would happen.? Yes all based on Hibernate internals.
>
> So I am not trying to blow you off as "this is not a bug". I think it 
> is a bug.? I'm just saying I do not yet know what to do about it.
>
> On Wed, Feb 7, 2018 at 12:41 PM Steve Ebersole <steve at hibernate.org 
> <mailto:steve at hibernate.org>> wrote:
>
>     Yes, I understood the situation.
>
>     I'm saying that in your query you should just be able to switch to
>     use named parameters (prefixed with `:`, rather than `?`) as a
>     workaround
>
>     On Wed, Feb 7, 2018 at 11:21 AM Laurent Almeras
>     <laurent.almeras at laposte.net <mailto:laurent.almeras at laposte.net>>
>     wrote:
>
>         Hi,
>
>         Thanks for this insight ; but as I stated (and this is a
>         correction of the assumptions of my first email) in my second
>         email, it seems that the wrong query (with mixed positional
>         and named parameters) is built in hibernate inside layers (and
>         not in QueryDSL).
>
>         I get rid of my QueryDSL query and replace it with raw JPQL
>         query :
>
>
>         ============================
>         ??? ??? Query query = getEntityManager().createQuery("select
>         queuedTaskHolder\n" +
>         ??? ??? ??? ??? "from QueuedTaskHolder queuedTaskHolder\n" +
>         ??? ??? ??? ??? "where queuedTaskHolder.status in (?1) and
>         queuedTaskHolder.queueId = ?2\n" +
>         ??? ??? ??? ??? "order by queuedTaskHolder.id
>         asc").setParameter(1, ImmutableList.of(TaskStatus.CANCELLED,
>         TaskStatus.COMPLETED)).setParameter(2, "queue");
>         ??? ??? return query.getResultList();
>         ============================
>
>         And it fails with the very same message :
>
>
>         ============================
>
>
>         Cannot define positional and named parameterSpecs : select
>         queuedTaskHolder
>         from
>         org.iglooproject.jpa.more.business.task.model.QueuedTaskHolder
>         queuedTaskHolder
>
>         where queuedTaskHolder.status in (:x1_0, :x1_1) and
>         queuedTaskHolder.queueId = ?2
>         order by queuedTaskHolder.id asc
>         ??? at
>         org.hibernate.hql.internal.ast.HqlSqlWalker.generatePositionalParameter(HqlSqlWalker.java:1094)
>         ??? at
>         org.hibernate.hql.internal.antlr.HqlSqlBaseWalker.parameter(HqlSqlBaseWalker.java:3463)
>         ============================
>
>         It used to work with Hibernate 5.2.x ; and by reading JPQL
>         spec (not sure if this is the right version -
>         https://docs.oracle.com/html/E13946_01/ejb3_langref.html#ejb3_langref_in
>         ) it seems that " IN (?param) " is a valid syntax.
>
>         I agree that mixed query may not be supported, but even if
>         positional parameter queries bring nothing more than named
>         parameters ones, there are also required for JPA compliance ?
>
>         Can you say me if I made some wrong assumptions ? If not, is
>         it usefull I provide some minimal test-case ?
>
>
>
>         *Side-note:* same query written with named parameters is OK
>         (as expected):
>
>
>         ============================
>         ??? ??? Query query = getEntityManager().createQuery("select
>         queuedTaskHolder\n" +
>         ??? ??? "from QueuedTaskHolder queuedTaskHolder\n" +
>         ??? ??? "where queuedTaskHolder.status in (:statuses) and
>         queuedTaskHolder.queueId = :queue\n" +
>         ??? ??? "order by queuedTaskHolder.id
>         asc").setParameter("statuses",
>         ImmutableList.of(TaskStatus.CANCELLED,
>         TaskStatus.COMPLETED)).setParameter("queue", "queue");
>         ??? ??? return query.getResultList();
>         ============================
>
>
>
>         Thanks,
>
>
>         Le 07/02/2018 ? 17:30, Steve Ebersole a ?crit?:
>>         Yes, I can see this being a problem. Its caused by some very
>>         old, fulgy code in how "list-valued parameters" are handled
>>         internally.
>>
>>         I'm not sure the best way to deal with this. Unfortunately
>>         reverting this is not possible - its necessary for JPA
>>         compliance.? The simple workaround of course is to use named
>>         parameters yourself.? Honestly JPA's notion of "positional"
>>         parameters is nonsensical since they are not positional - the
>>         ordinals can repeat and can appear in any order... nothing
>>         particularly positional about that.? In fact they are really
>>         nothing more than named parameters that happen to use
>>         int-valued labels.
>>
>>         Longer term 6.0 will address this because it changes that
>>         "old, fulgy" internal code - but those same changes are not
>>         possibly in 5.3.
>>
>>
>


From sanne at hibernate.org  Tue Feb 13 09:22:22 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 13 Feb 2018 14:22:22 +0000
Subject: [hibernate-dev] ORM CI jobs - erroneous github triggers
In-Reply-To: <CAFm4XO3XtDFw4JGZRX-b2g1RHu_rnayzb1aG3aR1xaGXS2Xb0A@mail.gmail.com>
References: <CAFdSV9teR_BdF_Zpa-79XLLhM8-sgWpRBCQ8=rp7U3mXSr4hug@mail.gmail.com>
	<CAFdSV9s5YLyZZ6E+-JPo4t2fvh9saPsO+nCuR-uc7i-WyRPV4g@mail.gmail.com>
	<CAFm4XO2bH9GJVDp2Pn-6CG=fjj-=DWz7zXGDZu=2nB_48i4JbA@mail.gmail.com>
	<CAFm4XO1ZpNRTNJPxWLLA5CpAX_7abYKaogsPRBPQ=ufc0nCgfg@mail.gmail.com>
	<CAFdSV9vWko75G+Je8p6-OB1tKYuLgtF9tMaX6sY9Pdb-RiZRkQ@mail.gmail.com>
	<CAFm4XO3XtDFw4JGZRX-b2g1RHu_rnayzb1aG3aR1xaGXS2Xb0A@mail.gmail.com>
Message-ID: <CAFm4XO1NB83SC+fA8uadeMQ3kT0ocP3Jd1s_L5Dn3ML+JvAFCQ@mail.gmail.com>

Unfortunately we have to reopen this thread. The issue is affecting us
again (since some weeks I think) and in larger scale, affecting all
builds. I guess it means the previous workaround is no longer
effective after some of the recent Jenkins / plugins updates.

On IRC we where wondering if we could fix this issue ourselves, or if
it's even possible with the metadata that GitHub provides. I'm not
sure of that but since we have the impression this previously worked
fine, maybe the metadata is available?

I won't have time for this this week but if someone else wishes to
look into it I can give some pointers, let me know.

Thanks,
Sanne


On 4 January 2018 at 12:09, Sanne Grinovero <sanne at hibernate.org> wrote:
> Also these jobs were configured to build automatically every 5 hours:
>  - hibernate-orm-4.2-h2
>  - hibernate-orm-4.3-h2
>
> I removed the schedule, they will be built when (and only when)
> anything is committed to their respective branches.
>
>
> On 3 January 2018 at 19:15, Steve Ebersole <steve at hibernate.org> wrote:
>> Nice!  Glad you found something.  Thanks for making the changes.
>>
>>
>>
>> On Wed, Jan 3, 2018 at 12:16 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>>
>>> I've made the change on:
>>>    - hibernate-orm-5.0-h2
>>>    - hibernate-orm-5.1-h2
>>>    - hibernate-orm-master-h2-main
>>>
>>> Let's see if it helps, then we can figure out a way to check all jobs
>>> are using this workaround.
>>>
>>>
>>> On 3 January 2018 at 18:12, Sanne Grinovero <sanne at hibernate.org> wrote:
>>> > Hi Steve,
>>> >
>>> > this rings a bell, we had this bug in the past and apparently it's
>>> > regressed again :(
>>> >
>>> > The latest Jenkins bug seems to be:
>>> >  - https://issues.jenkins-ci.org/browse/JENKINS-42161
>>> >
>>> > I'll try the suggested workarount, aka to enable SCM poll without any
>>> > frequency.
>>> >
>>> > Thanks,
>>> > Sanne
>>> >
>>> >
>>> > On 3 January 2018 at 17:35, Steve Ebersole <steve at hibernate.org> wrote:
>>> >> So I just pushed to the ORM master branch, which has caused the
>>> >> following
>>> >> jobs to be queued up:
>>> >>
>>> >>
>>> >>    - hibernate-orm-5.0-h2
>>> >>    - hibernate-orm-5.1-h2
>>> >>    - hibernate-orm-master-h2-main
>>> >>
>>> >> Only one of those jobs is configured to "watch" master.  So why do
>>> >> these
>>> >> other jobs keep getting triggered?
>>> >>
>>> >> I see the same exact thing on my personal fork as well.  At the same
>>> >> time I
>>> >> pushed to my fork's 5.3 branch, which triggered the 6.0 job to be
>>> >> queued.
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Jan 2, 2018 at 1:54 PM Steve Ebersole <steve at hibernate.org>
>>> >> wrote:
>>> >>
>>> >>> The legacy ORM jobs (5.1-based ones at least) are getting triggered
>>> >>> when
>>> >>> they should not be.  Generally they all show they the run is triggered
>>> >>> by a
>>> >>> "SCM change", but it does not show any changes.  The underlying
>>> >>> problem
>>> >>> (although I am at a loss as to why) is that there has indeed been SCM
>>> >>> changes pushed to Github, but against completely different branches.
>>> >>> As
>>> >>> far as I can tell these job's Github setting are correct.  Any ideas
>>> >>> what
>>> >>> is going on?
>>> >>>
>>> >>> This would not be such a big deal if the CI environment did not
>>> >>> throttle
>>> >>> all waiting jobs down to one active job.  So the jobs I am actually
>>> >>> interested in are forced to wait (sometimes over an hour) for these
>>> >>> jobs
>>> >>> that should not even be running.
>>> >>>
>>> >>>
>>> >>>
>>> >> _______________________________________________
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From davide at hibernate.org  Tue Feb 13 09:45:36 2018
From: davide at hibernate.org (Davide D'Alto)
Date: Tue, 13 Feb 2018 14:45:36 +0000
Subject: [hibernate-dev] ORM CI jobs - erroneous github triggers
In-Reply-To: <CAFm4XO1NB83SC+fA8uadeMQ3kT0ocP3Jd1s_L5Dn3ML+JvAFCQ@mail.gmail.com>
References: <CAFdSV9teR_BdF_Zpa-79XLLhM8-sgWpRBCQ8=rp7U3mXSr4hug@mail.gmail.com>
	<CAFdSV9s5YLyZZ6E+-JPo4t2fvh9saPsO+nCuR-uc7i-WyRPV4g@mail.gmail.com>
	<CAFm4XO2bH9GJVDp2Pn-6CG=fjj-=DWz7zXGDZu=2nB_48i4JbA@mail.gmail.com>
	<CAFm4XO1ZpNRTNJPxWLLA5CpAX_7abYKaogsPRBPQ=ufc0nCgfg@mail.gmail.com>
	<CAFdSV9vWko75G+Je8p6-OB1tKYuLgtF9tMaX6sY9Pdb-RiZRkQ@mail.gmail.com>
	<CAFm4XO3XtDFw4JGZRX-b2g1RHu_rnayzb1aG3aR1xaGXS2Xb0A@mail.gmail.com>
	<CAFm4XO1NB83SC+fA8uadeMQ3kT0ocP3Jd1s_L5Dn3ML+JvAFCQ@mail.gmail.com>
Message-ID: <CANoTJYOtGQG+eaQ_fPY+cbkMnoLQ9b1fHdP60-HRDmH833MkrA@mail.gmail.com>

I can have a look at this issue.

If you have any suggestions, let me know.

Thanks

On Tue, Feb 13, 2018 at 2:22 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> Unfortunately we have to reopen this thread. The issue is affecting us
> again (since some weeks I think) and in larger scale, affecting all
> builds. I guess it means the previous workaround is no longer
> effective after some of the recent Jenkins / plugins updates.
>
> On IRC we where wondering if we could fix this issue ourselves, or if
> it's even possible with the metadata that GitHub provides. I'm not
> sure of that but since we have the impression this previously worked
> fine, maybe the metadata is available?
>
> I won't have time for this this week but if someone else wishes to
> look into it I can give some pointers, let me know.
>
> Thanks,
> Sanne
>
>
> On 4 January 2018 at 12:09, Sanne Grinovero <sanne at hibernate.org> wrote:
>> Also these jobs were configured to build automatically every 5 hours:
>>  - hibernate-orm-4.2-h2
>>  - hibernate-orm-4.3-h2
>>
>> I removed the schedule, they will be built when (and only when)
>> anything is committed to their respective branches.
>>
>>
>> On 3 January 2018 at 19:15, Steve Ebersole <steve at hibernate.org> wrote:
>>> Nice!  Glad you found something.  Thanks for making the changes.
>>>
>>>
>>>
>>> On Wed, Jan 3, 2018 at 12:16 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>>>
>>>> I've made the change on:
>>>>    - hibernate-orm-5.0-h2
>>>>    - hibernate-orm-5.1-h2
>>>>    - hibernate-orm-master-h2-main
>>>>
>>>> Let's see if it helps, then we can figure out a way to check all jobs
>>>> are using this workaround.
>>>>
>>>>
>>>> On 3 January 2018 at 18:12, Sanne Grinovero <sanne at hibernate.org> wrote:
>>>> > Hi Steve,
>>>> >
>>>> > this rings a bell, we had this bug in the past and apparently it's
>>>> > regressed again :(
>>>> >
>>>> > The latest Jenkins bug seems to be:
>>>> >  - https://issues.jenkins-ci.org/browse/JENKINS-42161
>>>> >
>>>> > I'll try the suggested workarount, aka to enable SCM poll without any
>>>> > frequency.
>>>> >
>>>> > Thanks,
>>>> > Sanne
>>>> >
>>>> >
>>>> > On 3 January 2018 at 17:35, Steve Ebersole <steve at hibernate.org> wrote:
>>>> >> So I just pushed to the ORM master branch, which has caused the
>>>> >> following
>>>> >> jobs to be queued up:
>>>> >>
>>>> >>
>>>> >>    - hibernate-orm-5.0-h2
>>>> >>    - hibernate-orm-5.1-h2
>>>> >>    - hibernate-orm-master-h2-main
>>>> >>
>>>> >> Only one of those jobs is configured to "watch" master.  So why do
>>>> >> these
>>>> >> other jobs keep getting triggered?
>>>> >>
>>>> >> I see the same exact thing on my personal fork as well.  At the same
>>>> >> time I
>>>> >> pushed to my fork's 5.3 branch, which triggered the 6.0 job to be
>>>> >> queued.
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Jan 2, 2018 at 1:54 PM Steve Ebersole <steve at hibernate.org>
>>>> >> wrote:
>>>> >>
>>>> >>> The legacy ORM jobs (5.1-based ones at least) are getting triggered
>>>> >>> when
>>>> >>> they should not be.  Generally they all show they the run is triggered
>>>> >>> by a
>>>> >>> "SCM change", but it does not show any changes.  The underlying
>>>> >>> problem
>>>> >>> (although I am at a loss as to why) is that there has indeed been SCM
>>>> >>> changes pushed to Github, but against completely different branches.
>>>> >>> As
>>>> >>> far as I can tell these job's Github setting are correct.  Any ideas
>>>> >>> what
>>>> >>> is going on?
>>>> >>>
>>>> >>> This would not be such a big deal if the CI environment did not
>>>> >>> throttle
>>>> >>> all waiting jobs down to one active job.  So the jobs I am actually
>>>> >>> interested in are forced to wait (sometimes over an hour) for these
>>>> >>> jobs
>>>> >>> that should not even be running.
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >> _______________________________________________
>>>> >> hibernate-dev mailing list
>>>> >> hibernate-dev at lists.jboss.org
>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at hibernate.org  Tue Feb 13 10:03:06 2018
From: guillaume.smet at hibernate.org (Guillaume Smet)
Date: Tue, 13 Feb 2018 16:03:06 +0100
Subject: [hibernate-dev] NoORM IRC meeting minutes
Message-ID: <CALt0+o_sdGnW42t_v7p6MWhvm47DAFvtHfnrvEgpiB6L0hHAGA@mail.gmail.com>

Hi,

Here are the minutes of our biweekly meeting:

16:01 < jbott> Meeting ended Tue Feb 13 15:01:26 2018 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:01 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-02-13-14.07.html
16:01 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-02-13-14.07.txt
16:01 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-02-13-14.07.log.html

Have a nice day.

-- 
Guillaume

From fercoli at redhat.com  Tue Feb 13 11:55:41 2018
From: fercoli at redhat.com (Fabio Massimo Ercoli)
Date: Tue, 13 Feb 2018 17:55:41 +0100
Subject: [hibernate-dev] Hibernate OGM 5.3 CR1 released
Message-ID: <CAFiQRE9Uzm_Gx0jfTw7_-9ErkDtTwAsnHWU08KfJbRHANehioA@mail.gmail.com>

HIbernate OGM 5.3 CR1 is ready!

The major improvement was the version upgrade for Hibernate ORM
(5.2.13.Final) and Hibernate Search (5.9.0.Final).
The application of Clustered Counters, for Infinispan Embedded dialect, has
been improved in this version.

All the details in the blog post:
http://in.relation.to/2018/02/13/hibernate-ogm-5-3-CR1-released/

Thanks, ?Fabio

From sanne at hibernate.org  Tue Feb 13 12:24:59 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 13 Feb 2018 17:24:59 +0000
Subject: [hibernate-dev] ORM 5.1 vs compatibility with Java 6
Message-ID: <CAFm4XO2m9H4r+QQtE+PS36MhDxhEGPv4DYxDjknd_oXKHy7sEQ@mail.gmail.com>

Is Hibernate ORM 5.1 still meant to be compatible with Java 6?

The readme seems to promise that it should be, but it's not: I
happened to try compiling it and it failed, as some recent changes are
using JDK classes which have been introduced in 7.

Turns out it builds fine for Andrea an Chris, as they don't have the
JAVA6_HOME variable set: in this case the build will be lenient: log a
warning and move on.

I guess the same was done by all others on the team? CI is not
checking this either.

Wondering if you all feel like it's worth fixing branch 5.1, or if
it's a dead branch anyway.

Thanks,
Sanne

From sanne at hibernate.org  Tue Feb 13 16:41:37 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 13 Feb 2018 21:41:37 +0000
Subject: [hibernate-dev] module org.hibernate.commons.annotations
Message-ID: <CAFm4XO1_E1YVc6CSfsxCGm_TfH_StetzKo3B8H4YQLgzpWSoBw@mail.gmail.com>

I'd like to release an Hibernate Commons Annotations version
5.0.2.Final to declare its Jigsaw module name as an automatic module
name. Version 6 - whihch I proposed in a different thread - should
then use this module but have a proper module definition.

Is module name `org.hibernate.commons.annotations` acceptable for you all?

Incidentally, there happens to be another nice improvement in branch
5.0 which was never released so it would be nice to upgrade to this
version even if you have no interest in modularity yet.

As soon as there's agreement on the module name I'll release it.

Thanks,
Sanne

From sanne at hibernate.org  Tue Feb 13 16:43:43 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 13 Feb 2018 21:43:43 +0000
Subject: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names
 for all published modules
In-Reply-To: <CALt0+o8Z8THJc7cPhnXHquqX-qn4kKHKya7V2902CjYdgk+PyQ@mail.gmail.com>
References: <CAFm4XO0znHpnT7GY=Omt8_aNLG1YYKqu-vQ-uXXcdKW_mc2j6Q@mail.gmail.com>
	<CADGJaX9VuDNZQQgNMJNjcZQGQ11REombWn1-jU-Wfi+kTm32fw@mail.gmail.com>
	<CAFm4XO2iZ0mjA2cox+4Mwn+efObxmX5p2xxa8z6nhQpCpFTweg@mail.gmail.com>
	<CADGJaX9mG=bz7izuxB+AJGWc9E51VFwJ_aix20B2R0SROWV9vg@mail.gmail.com>
	<CAFm4XO0R_Xn0U739ERHP+wKJmByPaeLH=3F9OrVhcivLUYQMUA@mail.gmail.com>
	<CAEqagpoObS3DvgXkwg0xwu0D20LX4sQRupHc6fMfND2u1O_82Q@mail.gmail.com>
	<CAFm4XO26EK-8qHyXwSMtbp6eYi-hfs7uwPThTBYdpcy4m92tLA@mail.gmail.com>
	<CAEqagpppLa7YhQ63oeQuYSRoPvNSfBWzEdEbAFosmCVWqLWteA@mail.gmail.com>
	<CALt0+o8Z8THJc7cPhnXHquqX-qn4kKHKya7V2902CjYdgk+PyQ@mail.gmail.com>
Message-ID: <CAFm4XO0HmE60s+ZK=mYc-TbeOmfU5b8LKqvV=5cpdyKjnT6PHw@mail.gmail.com>

On 13 February 2018 at 11:48, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> On Tue, Feb 13, 2018 at 11:59 AM, Yoann Rodiere <yoann at hibernate.org> wrote:
>>
>> >   - org.hibernate.search.jms-support
>>
>> Not sure it's a valid name (aren't hyphens forbidden in package names, and
>> aren't module names constrained by the same rules?), but apart from that
>> it
>> looks good. Maybe "jms_support" instead, if "jms-support" is not allowed.
>> I would like to find a name for what the JMS and JGroups modules provide
>> in
>> Hibernate Search 6 though, something less misleading than "backend".
>> Something like "work routing" or "clustering support" or "distribution
>> support" or whatever. Would you be ok with changing the module name in 6?
>> If not, maybe we have to think about it now... Note that we'll change the
>> Maven group ID anyway, so it's arguably just another breaking change.
>
>
> +1 to find a distinctive name for JGroups and JMS artifacts and same for
> Lucene and Elasticsearch (either this round or for 6).
>
> org.hibernate.search.clustering.jms
> org.hibernate.search.clustering.jgroups
>
> and
>
> org.hibernate.search.indexing.lucene
> org.hibernate.search.indexing.elasticsearch
>
> would be my choice as it's very understandable by the end user.

Great names! I'll take them. These will allow us to gracefully phase
out the backend terminology, and also suggest the additional
dependency tree they will pull in.

>
> It might be an orthogonal discussion so feel free to ignore me :).
>
> --
> Guillaume
>

From steve at hibernate.org  Tue Feb 13 16:52:24 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 13 Feb 2018 21:52:24 +0000
Subject: [hibernate-dev] module org.hibernate.commons.annotations
In-Reply-To: <CAFm4XO1_E1YVc6CSfsxCGm_TfH_StetzKo3B8H4YQLgzpWSoBw@mail.gmail.com>
References: <CAFm4XO1_E1YVc6CSfsxCGm_TfH_StetzKo3B8H4YQLgzpWSoBw@mail.gmail.com>
Message-ID: <CAFdSV9stfEO2CWEUwUa4L8kv-H=-DyCP8AveFpfqeV6+aqhhWA@mail.gmail.com>

+1

On Tue, Feb 13, 2018, 3:42 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> I'd like to release an Hibernate Commons Annotations version
> 5.0.2.Final to declare its Jigsaw module name as an automatic module
> name. Version 6 - whihch I proposed in a different thread - should
> then use this module but have a proper module definition.
>
> Is module name `org.hibernate.commons.annotations` acceptable for you all?
>
> Incidentally, there happens to be another nice improvement in branch
> 5.0 which was never released so it would be nice to upgrade to this
> version even if you have no interest in modularity yet.
>
> As soon as there's agreement on the module name I'll release it.
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Tue Feb 13 18:06:02 2018
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 13 Feb 2018 15:06:02 -0800
Subject: [hibernate-dev] ORM 5.1 vs compatibility with Java 6
In-Reply-To: <CAFm4XO2m9H4r+QQtE+PS36MhDxhEGPv4DYxDjknd_oXKHy7sEQ@mail.gmail.com>
References: <CAFm4XO2m9H4r+QQtE+PS36MhDxhEGPv4DYxDjknd_oXKHy7sEQ@mail.gmail.com>
Message-ID: <CAFDzhiR0-SiTfr=e4JUo7FN9Qi-iLWFxxSdNKr8F33w14ctejg@mail.gmail.com>

Hi Sanne,

I didn't notice the failures either. I've been running it with JAVA6_HOME
pointing to jdk7, but I can't remember why I would have changed it to that.

It sounds like 5.1 branch will be a product branch for a while, so if it's
easy to make it compatible to JDK6, then I'd prefer to do that.

It looks like there are only 2 failures:
1) an unused import for import java.util.Objects, which is easily deleted.
2) ReflectHelper#JAVA_CONSTANT_PATTERN uses java.util.regex.
Pattern.UNICODE_CHARACTER_CLASS.

Vlad, is there some other flag that can be used that is compatible with
JDK6? If not, is there some other reasonable flag that we can use instead?

Regards,
Gail

On Tue, Feb 13, 2018 at 9:24 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Is Hibernate ORM 5.1 still meant to be compatible with Java 6?
>
> The readme seems to promise that it should be, but it's not: I
> happened to try compiling it and it failed, as some recent changes are
> using JDK classes which have been introduced in 7.
>
> Turns out it builds fine for Andrea an Chris, as they don't have the
> JAVA6_HOME variable set: in this case the build will be lenient: log a
> warning and move on.
>
> I guess the same was done by all others on the team? CI is not
> checking this either.
>
> Wondering if you all feel like it's worth fixing branch 5.1, or if
> it's a dead branch anyway.
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Feb 14 08:33:40 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 14 Feb 2018 13:33:40 +0000
Subject: [hibernate-dev] module org.hibernate.commons.annotations
In-Reply-To: <CAEqagpqXLCQrVqiY-m_N8BeH1eErcRnvJ3cQGyH7Z4991drdnw@mail.gmail.com>
References: <CAFm4XO1_E1YVc6CSfsxCGm_TfH_StetzKo3B8H4YQLgzpWSoBw@mail.gmail.com>
	<CAFdSV9stfEO2CWEUwUa4L8kv-H=-DyCP8AveFpfqeV6+aqhhWA@mail.gmail.com>
	<CAEqagpqXLCQrVqiY-m_N8BeH1eErcRnvJ3cQGyH7Z4991drdnw@mail.gmail.com>
Message-ID: <CAFm4XO1NGWeR96C+2t25eHVVke75c0XSXUdKdMOjqzPjJjzB7Q@mail.gmail.com>

Thanks all, HCANN 5.0.2.Final is released.

Changelog:
 - https://hibernate.atlassian.net/projects/HCANN/versions/30400/tab/release-report-all-issues

Andrej Golovnin had contributed a neat patch improving memory
allocation last year, but we never released the branch so this wasn't
effective. I'll send PRs to upgrade all projects to benefit from it.

Thanks,
Sanne

On 14 February 2018 at 08:37, Yoann Rodiere <yrodiere at redhat.com> wrote:
> Sounds good.
>
> On Tue, 13 Feb 2018 at 22:53 Steve Ebersole <steve at hibernate.org> wrote:
>>
>> +1
>>
>> On Tue, Feb 13, 2018, 3:42 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> > I'd like to release an Hibernate Commons Annotations version
>> > 5.0.2.Final to declare its Jigsaw module name as an automatic module
>> > name. Version 6 - whihch I proposed in a different thread - should
>> > then use this module but have a proper module definition.
>> >
>> > Is module name `org.hibernate.commons.annotations` acceptable for you
>> > all?
>> >
>> > Incidentally, there happens to be another nice improvement in branch
>> > 5.0 which was never released so it would be nice to upgrade to this
>> > version even if you have no interest in modularity yet.
>> >
>> > As soon as there's agreement on the module name I'll release it.
>> >
>> > Thanks,
>> > Sanne
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> --
> Yoann Rodiere
> yoann at hibernate.org / yrodiere at redhat.com
> Software Engineer
> Hibernate NoORM team

From sanne at hibernate.org  Wed Feb 14 09:16:21 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 14 Feb 2018 14:16:21 +0000
Subject: [hibernate-dev] ORM 5.1 vs compatibility with Java 6
In-Reply-To: <CAFDzhiR0-SiTfr=e4JUo7FN9Qi-iLWFxxSdNKr8F33w14ctejg@mail.gmail.com>
References: <CAFm4XO2m9H4r+QQtE+PS36MhDxhEGPv4DYxDjknd_oXKHy7sEQ@mail.gmail.com>
	<CAFDzhiR0-SiTfr=e4JUo7FN9Qi-iLWFxxSdNKr8F33w14ctejg@mail.gmail.com>
Message-ID: <CAFm4XO1jKQY8hj5O2icQs7mRFaq7ak8ty3JXyx7WBiDcrbs74Q@mail.gmail.com>

Thanks for all feedback; I've opened:
 - https://hibernate.atlassian.net/browse/HHH-12295

Please if you plan to make changes on branch 5.1 could you set
JAVA6_HOME point to an actual JDK6: Animal Sniffer is helpful but it
wil never be as good as testing with the real thing.

Thanks,
Sanne


On 13 February 2018 at 23:06, Gail Badner <gbadner at redhat.com> wrote:
> Hi Sanne,
>
> I didn't notice the failures either. I've been running it with JAVA6_HOME
> pointing to jdk7, but I can't remember why I would have changed it to that.
>
> It sounds like 5.1 branch will be a product branch for a while, so if it's
> easy to make it compatible to JDK6, then I'd prefer to do that.
>
> It looks like there are only 2 failures:
> 1) an unused import for import java.util.Objects, which is easily deleted.
> 2) ReflectHelper#JAVA_CONSTANT_PATTERN uses
> java.util.regex.Pattern.UNICODE_CHARACTER_CLASS.
>
> Vlad, is there some other flag that can be used that is compatible with
> JDK6? If not, is there some other reasonable flag that we can use instead?
>
> Regards,
> Gail
>
> On Tue, Feb 13, 2018 at 9:24 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> Is Hibernate ORM 5.1 still meant to be compatible with Java 6?
>>
>> The readme seems to promise that it should be, but it's not: I
>> happened to try compiling it and it failed, as some recent changes are
>> using JDK classes which have been introduced in 7.
>>
>> Turns out it builds fine for Andrea an Chris, as they don't have the
>> JAVA6_HOME variable set: in this case the build will be lenient: log a
>> warning and move on.
>>
>> I guess the same was done by all others on the team? CI is not
>> checking this either.
>>
>> Wondering if you all feel like it's worth fixing branch 5.1, or if
>> it's a dead branch anyway.
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Wed Feb 14 09:32:22 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 14 Feb 2018 14:32:22 +0000
Subject: [hibernate-dev] 5.3.0 and JPA TCK
Message-ID: <CAFdSV9s5BnkzVQd-33bMJKBX_9SMFTvqd=2dfow-P5Qh5XR85A@mail.gmail.com>

At this point, all of our challenges with Oracle over JPA TCK tests are
resolved.  Today I will be rerunning the ful TCK to verify that.

Anyway, long story short unless there are objections I plan to make this
version CR1 considering we've really just been waiting on the resolution of
these challenges to "finalize" 5.3.

P.S. it might be very late until I can do the release depending on how long
the TCK takes to run (it generally takes a looooong time).

From steve at hibernate.org  Wed Feb 14 09:33:11 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 14 Feb 2018 14:33:11 +0000
Subject: [hibernate-dev] ORM 5.1 vs compatibility with Java 6
In-Reply-To: <CAFm4XO1jKQY8hj5O2icQs7mRFaq7ak8ty3JXyx7WBiDcrbs74Q@mail.gmail.com>
References: <CAFm4XO2m9H4r+QQtE+PS36MhDxhEGPv4DYxDjknd_oXKHy7sEQ@mail.gmail.com>
	<CAFDzhiR0-SiTfr=e4JUo7FN9Qi-iLWFxxSdNKr8F33w14ctejg@mail.gmail.com>
	<CAFm4XO1jKQY8hj5O2icQs7mRFaq7ak8ty3JXyx7WBiDcrbs74Q@mail.gmail.com>
Message-ID: <CAFdSV9spg_6TCpL8nciZdYoT_wVqM70W8Tf6+1gGReG_jaVVuw@mail.gmail.com>

The only consistent way that is going to happen is to set it up on CI

On Wed, Feb 14, 2018 at 8:27 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Thanks for all feedback; I've opened:
>  - https://hibernate.atlassian.net/browse/HHH-12295
>
> Please if you plan to make changes on branch 5.1 could you set
> JAVA6_HOME point to an actual JDK6: Animal Sniffer is helpful but it
> wil never be as good as testing with the real thing.
>
> Thanks,
> Sanne
>
>
> On 13 February 2018 at 23:06, Gail Badner <gbadner at redhat.com> wrote:
> > Hi Sanne,
> >
> > I didn't notice the failures either. I've been running it with JAVA6_HOME
> > pointing to jdk7, but I can't remember why I would have changed it to
> that.
> >
> > It sounds like 5.1 branch will be a product branch for a while, so if
> it's
> > easy to make it compatible to JDK6, then I'd prefer to do that.
> >
> > It looks like there are only 2 failures:
> > 1) an unused import for import java.util.Objects, which is easily
> deleted.
> > 2) ReflectHelper#JAVA_CONSTANT_PATTERN uses
> > java.util.regex.Pattern.UNICODE_CHARACTER_CLASS.
> >
> > Vlad, is there some other flag that can be used that is compatible with
> > JDK6? If not, is there some other reasonable flag that we can use
> instead?
> >
> > Regards,
> > Gail
> >
> > On Tue, Feb 13, 2018 at 9:24 AM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> Is Hibernate ORM 5.1 still meant to be compatible with Java 6?
> >>
> >> The readme seems to promise that it should be, but it's not: I
> >> happened to try compiling it and it failed, as some recent changes are
> >> using JDK classes which have been introduced in 7.
> >>
> >> Turns out it builds fine for Andrea an Chris, as they don't have the
> >> JAVA6_HOME variable set: in this case the build will be lenient: log a
> >> warning and move on.
> >>
> >> I guess the same was done by all others on the team? CI is not
> >> checking this either.
> >>
> >> Wondering if you all feel like it's worth fixing branch 5.1, or if
> >> it's a dead branch anyway.
> >>
> >> Thanks,
> >> Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From davide at hibernate.org  Wed Feb 14 10:18:24 2018
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 14 Feb 2018 15:18:24 +0000
Subject: [hibernate-dev] Hibernate OGM integration with ORM 5.3
Message-ID: <CANoTJYO_j5TXib=AsSAqBCLsncDdbDFo=cje08f3oCZqqngnZw@mail.gmail.com>

Hi,
I'm working on the integration with ORM 5.3 and I've created a branch
where I'm applying the changes.

You can see some initial discussions on the pull request I've sent as
preview: https://github.com/hibernate/hibernate-ogm/pull/961

I didn't find any specific issue with ORM 5.3 that could create a
problem for OGM so far.

Main problems are
1)  check the JpaCompliance property and behave the same way as ORM
from a user point of view when possible
2) Positional parameters can now start from 1
3) The method that creates the factory doesn't thow exceptions anymoew
and in OGM we will have to do something similar when the OGM provider
is used


Anyway, it doesn't seem that these issues require changes in ORM.
I still have to update the integration tests with WildFly, so
something else might appears.

Cheers,
Davide

From gbadner at redhat.com  Wed Feb 14 13:05:29 2018
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 14 Feb 2018 10:05:29 -0800
Subject: [hibernate-dev] API incompatibilities between Hibernate ORM 5.3 and
	6.0
Message-ID: <CAFDzhiTD0td4La8zSaddsKBvxDO_hsBjNQK3vHxNhT7U+TxN9g@mail.gmail.com>

I sent this last night with a huge report file, and it seems that it didn't
get out.

I'm re-sending without the report file...

I ran japi-compliance-checker to compare differences in APIs
between hibernate-core-5.3.0-SNAPSHOT.jar and hibernate-core-6.0.0-
SNAPSHOT.jar.

I ran it last week, so it may not include updates made since that time.

Differences in Envers shown in the report should be disregarded because it
only reflects that hibernate-envers was merged into hibernate-core. A
separate comparison between hibernate-envers-5.3.0-SNAPSHOT.jar and
hibernate-core-6.0.0-SNAPSHOT.jar needs to be done to see Envers changes.

Chris will provide details about Envers differences in a separate email.

The report is huge; it took me 3 to 4 hours to scan it. AFAICT, what I've
documented are the only non-Envers API changes that could affect
applications. They all involve removed classes/methods.

My intention here is just to get this information out, so we have some
solid examples to discuss.

Regards,
Gail

------------------------------------------------------------
----------------------------------------------------------------------

Custom types: I am not familiar with how this will work in 6.0. Steve,
please fill in details about any incompatibilities.

org.hibernate.Criteria and org.hibernate.criterion.DetachedCriteria:

In 5.0/5.1/5.2:
* user guides say, "This appendix covers the legacy Hibernate
org.hibernate.Criteria API, which should be considered deprecated. New
development should focus on the JPA javax.persistence.criteria.CriteriaQuery
API. Eventually, Hibernate-specific criteria features will be ported as
extensions to the JPA javax.persistence.criteria.CriteriaQuery. For details
on the JPA APIs, see Criteria."

In 5.2/5.3:
* Criteria and DetachedCriteria are not deprecated;
* all SharedSessionContract#createCriteria methods are deprecated;
* public static methods in DetachedCriteria are not deprecated;

In 6.0:
* Criteria and DetachedCriteria are removed along with other classes in
org.hibernate.criterion.

Incompatibilities migrating from 5.3 -> 6.0:
1) Existing applications using legacy org.hibernate.Criteria will need to
be updated to use javax.persistence.criteria.CriteriaQuery;
2) If Hibernate's implementation of javax.persistence.criteria.CriteriaQuery
does not include the Hibernate-specific extensions that were available
using org.hibernate.Criteria, applications may not have a straightforward
way to change their applications to work.

org.hibernate.Query

In 5.1:
* SharedSessionContract#createQuery returns org.hibernate.Query
(org.hibernate.Session extends SharedSessionContract);

In 5.2/5.3:
* org.hibernate.Query was deprecated; org.hibernate.query.Query should be
used instead; org.hibernate.query.Query extends org.hibernate.Query;
* SharedSessionContract#createQuery moved to
org.hibernate.query.QueryProducer#createQuery,
returning  org.hibernate.query.Query (which extends org.hibernate.Query);
(org.hibernate.Session extends QueryProducer);

In 6.0:
* org.hibernate.Query was removed.

Incompatibilities migrating from 5.3 -> 6.0:
1) Existing applications that explicitly use org.hibernate.Query (including
javax.persistence.Query.unwrap( org.hibernate.Query.class )) will have to
be changed to use org.hibernate.query.Query.

org.hibernate.SQLQuery:

In 5.1:
* SharedSessionContract#createSQLQuery returns org.hibernate.SQLQuery
(org.hibernate.Session extends SharedSessionContract);

In 5.2/5.3:
* SQLQuery was deprecated; NativeQuery should be used instead; NativeQuery
extends SQLQuery;
* SharedSessionContract#createSQLQuery moved to
QueryProducer#createSQLQuery, returning  NativeQuery (which extends
SQLQuery); Session extends QueryProducer;
* QueryProducer#createSQLQuery is deprecated; QueryProducer#createNativeQuery
should be used instead

In 6.0:
* SQLQuery and org.hibernate.query.QueryProducer#createSQLQuery are removed.

Incompatibilities migrating from 5.3 -> 6.0:
1) Existing applications using Session#createSQLQuery will need to be
updated to use Session#createNativeQuery.
2) Existing applications that explicitly use org.hibernate.SQLQuery
(including javax.persistence.Query.unwrap( SQLQuery.class )) will have to
be changed to use NativeQuery.

org.hibernate.SynchronizeableQuery

In 5.2/5.3:
* org.hibernate.SynchronizeableQuery is not deprecated;
* SQLQuery, NativeQuery and ProcedureCall extend org.hibernate.
SynchronizeableQuery

In 6.0:
* org.hibernate.SynchronizeableQuery is moved to org.hibernate.query.
SynchronizeableQuery;
* NativeQuery and ProcedureCall extend
org.hibernate.query.SynchronizeableQuery;
(SQLQuery was removed as mentioned above)

Incompatibilities migrating from 5.3 -> 6.0:
1) In 6.0, existing applications that use org.hibernate.SynchronizeableQuery
(including javax.persistence.Query.unwrap(
org.hibernate.SynchronizeableQuery.class
)) will need to be updated to use org.hibernate.query.SynchronizeableQuery

org.hibernate.Session#createFilter

In 5.1:
* Session#createFilter returns org.hibernate.Query;

In 5.2/5.3:
* Session#createFilter returns org.hibernate.query.Query (which extends
org.hibernate.Query);
* org.hibernate.Session#createFilter is not deprecated;

In 6.0:
* org.hibernate.Session#createFilter is removed.

Incompatibilities migrating from 5.3 -> 6.0:
1) Existing applications that call Session#createFilter will need to be
updated (to what???); does collection filter functionality exist in 6.0???

org.hibernate.Session.#getTypeHelper

In 5.1/5.2/5.3:
* org.hibernate.Session.#getTypeHelper returns org.hibernate.TypeHelper;
* Session#getTypeHelper is not deprecated;

In 6.0: org.hibernate.Session.#getTypeHelper is removed;

Incompatibilities migrating from 5.3 -> 6.0:
1) In 6.0, existing applications that call Session.#getTypeHelper will need
to be updated (to what???).

org.hibernate.metadata.ClassMetadata, org.hibernate.metadata.
CollectionMetadata

In 5.2/5.3:
* SessionFactory#getClassMetadata(Class), #getClassMetadata(String),
#getAllClassMetadata, #getCollectionMetadata, #getAllCollectionMetadata
were deprecated; descriptors from
javax.persistence.EntityManagerFactory#getMetamodel
should be used instead; org.hibernate.SessionFactory extends
javax.persistence.EntityManagerFactory;

In 6.0:
* ClassMetadata and CollectionMetadata removed.

Incompatibilities migrating from 5.3 -> 6.0:
1) In 6.0, existing applications that call
org.hibernate.SessionFactory#getClassMetadata(Class),
#getClassMetadata(String), #getAllClassMetadata, #getCollectionMetadata,
#getAllCollectionMetadata will need to be updated to use descripters from
javax.persistence.EntityManagerFactory#getMetamodel.

org.hibernate.stat.NaturalIdCacheStatistics

In 5.2/5.3:
* Statistics#getNaturalIdCacheStatistics returns NaturalIdCacheStatistics;

In 6.0:
* NaturalIdCacheStatistics is renamed to NaturalIdQueryStatistics;
* NaturalIdQueryStatistics excludes #getHitCount, #getMissCount,
#getPutCount, #getElementCountInMemory, #getElementCountOnDisk,
#getSizeInMemory, and #getEntries which were originally in
NaturalIdCacheStatistics; instead org.hibernate.stat.
SecondLevelCacheStatistics#getHitCount, #getMissCount, #getPutCount,
#getElementCountInMemory, #getElementCountOnDisk, #getSizeInMemory should
be used.
(SecondLevelCacheStatistics#getEntries was removed due to HHH-11356, so
there is no substitute for org.hibernate.stat.NaturalIdCacheStatistics#
getEntries;
* Statistics#getNaturalIdCacheStatistics is renamed to
#getNaturalIdStatistics.

Incompatibilities migrating from 5.3 -> 6.0:
1) Existing applications that explicitly use NaturalIdCacheStatistics will
need to be updated to use NaturalIdCacheStatistics.
2) Existing applications that call Statistics#getNaturalIdCacheStatistics
will need to be updated to use Statistics#getNaturalIdCacheStatistics.
3) Existing applications that call org.hibernate.stat.
NaturalIdCacheStatistics#getHitCount, #getMissCount, #getPutCount,
#getElementCountInMemory, #getElementCountOnDisk, #getSizeInMemory, or
#getEntries will need to be updated to obtain the
SecondLevelCacheStatistics object for the particular natural ID using
Statistics#getSecondLevelCacheStatistics( naturalIdRegionName??? ) (How is
naturalIdRegionName determined???). The application will need to be changed
to used SecondLevelCacheStatistics#getHitCount, #getMissCount,
#getPutCount, #getElementCountInMemory, #getElementCountOnDisk, and
#getSizeInMemory instead.
4) Existing applications that call NaturalIdCacheStatistics#getEntries will
need to be updated to no longer call that method.

org.hibernate.stat.SecondLevelCacheStatistics

In 5.3:
* SecondLevelCacheStatistics#getEntries is not deprecated;

In 6.0:
* SecondLevelCacheStatistics#getEntries is removed due to HHH-11356.
* SecondLevelCacheStatistics no longer implements Serializable;

Incompatibilities migrating from 5.3 -> 6.0:
1) Existing applications that call SecondLevelCacheStatistics#getEntries
will need to be updated to no longer call that method.
2) Existing applications that implement SecondLevelCacheStatistics (SPI)
will need to explicitly implement Serializable.

QueryStatistics#getCacheHitCount, #getCacheMissCount, and #getCachePutCount

In 5.3:
* QueryStatistics#getCacheHitCount, #getCacheMissCount, and
#getCachePutCount are not deprecated;

In 6.0:
* QueryStatistics#getCacheHitCount, #getCacheMissCount, and
#getCachePutCount were removed;
* ConcurrentQueryStatisticsImpl implements QueryStatistics and still
contains public methods, #getCacheHitCount, #getCacheMissCount, and
#getCachePutCount (why???).

Incompatibilities migrating from 5.3 -> 6.0:
1) Existing applications that use
org.hibernate.stat.QueryStatistics#getCacheHitCount,
#getCacheMissCount, and #getCachePutCount will need to be changed (to use
SecondLevelCacheStatistics???).

org.hibernate.jpa.HibernateEntityManager

In 5.2/5.3:
* HibernateEntityManager is deprecated; Session (or SessionImplementor
(SPI)) should be used instead;
* Session extends HibernateEntityManager;

In 6.0:
* HibernateEntityManager is removed.

Incompatibilities migrating from 5.3 -> 6.0:
1) In 6.0, existing applications that  explicitly use
org.hibernate.jpa.HibernateEntityManager
(including javax.persistence.EntityManager.unwrap(
HibernateEntityManager.class )) will have to be changed to use Session (or
SessionImplementor (SPI)).

org.hibernate.jpa.HibernateEntityManagerFactory

In 5.2/5.3:
* HibernateEntityManagerFactory is deprecated; SessionFactory (or
SessionFactoryImplementor (SPI)) should be used instead;
* SessionFactory extends HibernateEntityManagerFactory;

In 6.0:
* HibernateEntityManagerFactory is removed.

Incompatibilities migrating from 5.3 -> 6.0:
1) In 6.0, existing applications that explicitly use
org.hibernate.jpa.HibernateEntityManagerFactory
(including javax.persistence.EntityManagerFactory.unwrap(
HibernateEntityManagerFactory.class )) will have to be changed to use
Session (or SessionImplementor (SPI)).

org.hibernate.Hibernate#unproxy

In 5.2/5.3:
* Hibernate#unproxy was introduced by HHH-10831 in 5.2.10

In 6.0:
* the fix for HHH-10831 has not been incorporated into 6.0, so it is not
present. Will it be??

Incompatibilities migrating from 5.3 -> 6.0:
1) Existing applications that use Hibernate#unproxy will have to be be
changed to explicitly initialize and unproxy.

From sanne at hibernate.org  Wed Feb 14 15:48:20 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 14 Feb 2018 20:48:20 +0000
Subject: [hibernate-dev] JDK 10: First Release Candidate - JDK 10 b43
In-Reply-To: <f000619f-2f50-4a4b-e772-6ce1c920997b@oracle.com>
References: <f000619f-2f50-4a4b-e772-6ce1c920997b@oracle.com>
Message-ID: <CAFm4XO08NZt35Jj-RuZAMqWDnhkRjdficNgq2kOxt_2syPTXng@mail.gmail.com>

Hi Rory,

thanks for the update!

I've updated our ci.hibernate.org infrastructure and installed the
JDK10 Release Candidate 1.

We still have problems with several Maven plugins but we're now able
to work around them. Ideally for full test coverage we also need
Byteman, which in turn requires ASM to release 6.1, but at least it's
good to see that the (many) other tests which we can now run are fine.

Just to remind, some of the tools we'd normally use aren't running on
JDK9 yet either, but at least we're able to verify that people
consuming any Hibernate libraries should have no issues.

All : please create new jobs on ci.hibernate.org using "JDK 10 CR1",
now available in the drop down menu on the Jenkins job configuration;
so far we only have Hibernate Search testing.

Regards and thanks,
Sanne


On 13 February 2018 at 10:23, Rory O'Donnell <rory.odonnell at oracle.com> wrote:
> Hi Sanne,
>
> *JDK 10 build 43 is our first JDK 10 Release Candidate [1]*
>
>   * JDK 10 Early Access  build 43 is available at : - jdk.java.net/10/
>
> Notable changes since previous email.**
>
> *build 43
> *
>
>   * JDK-8194764 <https://bugs.openjdk.java.net/browse/JDK-8194764> -
>     javac incorrectly flags deprecated for removal imports
>   * JDK-8196678 <https://bugs.openjdk.java.net/browse/JDK-8196678> -
>     avoid printing uninitialized buffer in os::print_memory_info on AIX
>   * JDK-8195837 <https://bugs.openjdk.java.net/browse/JDK-8195837> -
>     (tz) Upgrade time-zone data to tzdata2018c
>
> **
>
> *Bug fixes reported by Open Source Projects  :*
>
>   * JDK-8196296 <https://bugs.openjdk.java.net/browse/JDK-8196296>
>     Lucene test crashes C2 compilation
>
> *Security Manager Survey
> *
>
> If you have written or maintain code that uses the SecurityManager or
> related APIs such as the AccessController,
> then we would appreciate if you would complete this survey:
> https://www.surveymonkey.com/r/RSGMF3K
> More info on the survey  [2]
>
>
> Regards,
> Rory
>
> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000742.html
> [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000649.html
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From rory.odonnell at oracle.com  Thu Feb 15 03:41:39 2018
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Thu, 15 Feb 2018 08:41:39 +0000
Subject: [hibernate-dev] JDK 10: First Release Candidate - JDK 10 b43
In-Reply-To: <CAFm4XO08NZt35Jj-RuZAMqWDnhkRjdficNgq2kOxt_2syPTXng@mail.gmail.com>
References: <f000619f-2f50-4a4b-e772-6ce1c920997b@oracle.com>
	<CAFm4XO08NZt35Jj-RuZAMqWDnhkRjdficNgq2kOxt_2syPTXng@mail.gmail.com>
Message-ID: <1bb40a36-8257-1829-86c7-38b3f786ccbd@oracle.com>

Thanks for the update Sanne!

Rgds,Rory


On 14/02/2018 20:48, Sanne Grinovero wrote:
> Hi Rory,
>
> thanks for the update!
>
> I've updated our ci.hibernate.org infrastructure and installed the
> JDK10 Release Candidate 1.
>
> We still have problems with several Maven plugins but we're now able
> to work around them. Ideally for full test coverage we also need
> Byteman, which in turn requires ASM to release 6.1, but at least it's
> good to see that the (many) other tests which we can now run are fine.
>
> Just to remind, some of the tools we'd normally use aren't running on
> JDK9 yet either, but at least we're able to verify that people
> consuming any Hibernate libraries should have no issues.
>
> All : please create new jobs on ci.hibernate.org using "JDK 10 CR1",
> now available in the drop down menu on the Jenkins job configuration;
> so far we only have Hibernate Search testing.
>
> Regards and thanks,
> Sanne
>
>
> On 13 February 2018 at 10:23, Rory O'Donnell <rory.odonnell at oracle.com> wrote:
>> Hi Sanne,
>>
>> *JDK 10 build 43 is our first JDK 10 Release Candidate [1]*
>>
>>    * JDK 10 Early Access  build 43 is available at : - jdk.java.net/10/
>>
>> Notable changes since previous email.**
>>
>> *build 43
>> *
>>
>>    * JDK-8194764 <https://bugs.openjdk.java.net/browse/JDK-8194764> -
>>      javac incorrectly flags deprecated for removal imports
>>    * JDK-8196678 <https://bugs.openjdk.java.net/browse/JDK-8196678> -
>>      avoid printing uninitialized buffer in os::print_memory_info on AIX
>>    * JDK-8195837 <https://bugs.openjdk.java.net/browse/JDK-8195837> -
>>      (tz) Upgrade time-zone data to tzdata2018c
>>
>> **
>>
>> *Bug fixes reported by Open Source Projects  :*
>>
>>    * JDK-8196296 <https://bugs.openjdk.java.net/browse/JDK-8196296>
>>      Lucene test crashes C2 compilation
>>
>> *Security Manager Survey
>> *
>>
>> If you have written or maintain code that uses the SecurityManager or
>> related APIs such as the AccessController,
>> then we would appreciate if you would complete this survey:
>> https://www.surveymonkey.com/r/RSGMF3K
>> More info on the survey  [2]
>>
>>
>> Regards,
>> Rory
>>
>> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000742.html
>> [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000649.html
>>
>> --
>> Rgds,Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA , Dublin, Ireland
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland


From steve at hibernate.org  Thu Feb 15 09:50:19 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 15 Feb 2018 14:50:19 +0000
Subject: [hibernate-dev] Starting 5.3 release
Message-ID: <CAFdSV9smv7Xt3Q649ejTP4aohF99TJaHYCOWsTPiiw-3o5sBYA@mail.gmail.com>

Per subject.  Please do not push to master for the time being...

From steve at hibernate.org  Thu Feb 15 12:13:03 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 15 Feb 2018 17:13:03 +0000
Subject: [hibernate-dev] API incompatibilities between Hibernate ORM 5.3
 and 6.0
In-Reply-To: <CAFDzhiTD0td4La8zSaddsKBvxDO_hsBjNQK3vHxNhT7U+TxN9g@mail.gmail.com>
References: <CAFDzhiTD0td4La8zSaddsKBvxDO_hsBjNQK3vHxNhT7U+TxN9g@mail.gmail.com>
Message-ID: <CAFdSV9seErrZbtQMbmUM5Ob16ga_8k0=9PxB2ur9xRPtN2JLOw@mail.gmail.com>

We have not integrated changes from master into 6.0 for a long time.  And
we probably won't for some time yet either.  So comparisons between 5.2 or
5.3 and 6.0 right now are pointless

On Wed, Feb 14, 2018 at 12:09 PM Gail Badner <gbadner at redhat.com> wrote:

> I sent this last night with a huge report file, and it seems that it didn't
> get out.
>
> I'm re-sending without the report file...
>
> I ran japi-compliance-checker to compare differences in APIs
> between hibernate-core-5.3.0-SNAPSHOT.jar and hibernate-core-6.0.0-
> SNAPSHOT.jar.
>
> I ran it last week, so it may not include updates made since that time.
>
> Differences in Envers shown in the report should be disregarded because it
> only reflects that hibernate-envers was merged into hibernate-core. A
> separate comparison between hibernate-envers-5.3.0-SNAPSHOT.jar and
> hibernate-core-6.0.0-SNAPSHOT.jar needs to be done to see Envers changes.
>
> Chris will provide details about Envers differences in a separate email.
>
> The report is huge; it took me 3 to 4 hours to scan it. AFAICT, what I've
> documented are the only non-Envers API changes that could affect
> applications. They all involve removed classes/methods.
>
> My intention here is just to get this information out, so we have some
> solid examples to discuss.
>
> Regards,
> Gail
>
> ------------------------------------------------------------
> ----------------------------------------------------------------------
>
> Custom types: I am not familiar with how this will work in 6.0. Steve,
> please fill in details about any incompatibilities.
>
> org.hibernate.Criteria and org.hibernate.criterion.DetachedCriteria:
>
> In 5.0/5.1/5.2:
> * user guides say, "This appendix covers the legacy Hibernate
> org.hibernate.Criteria API, which should be considered deprecated. New
> development should focus on the JPA
> javax.persistence.criteria.CriteriaQuery
> API. Eventually, Hibernate-specific criteria features will be ported as
> extensions to the JPA javax.persistence.criteria.CriteriaQuery. For details
> on the JPA APIs, see Criteria."
>
> In 5.2/5.3:
> * Criteria and DetachedCriteria are not deprecated;
> * all SharedSessionContract#createCriteria methods are deprecated;
> * public static methods in DetachedCriteria are not deprecated;
>
> In 6.0:
> * Criteria and DetachedCriteria are removed along with other classes in
> org.hibernate.criterion.
>
> Incompatibilities migrating from 5.3 -> 6.0:
> 1) Existing applications using legacy org.hibernate.Criteria will need to
> be updated to use javax.persistence.criteria.CriteriaQuery;
> 2) If Hibernate's implementation of
> javax.persistence.criteria.CriteriaQuery
> does not include the Hibernate-specific extensions that were available
> using org.hibernate.Criteria, applications may not have a straightforward
> way to change their applications to work.
>
> org.hibernate.Query
>
> In 5.1:
> * SharedSessionContract#createQuery returns org.hibernate.Query
> (org.hibernate.Session extends SharedSessionContract);
>
> In 5.2/5.3:
> * org.hibernate.Query was deprecated; org.hibernate.query.Query should be
> used instead; org.hibernate.query.Query extends org.hibernate.Query;
> * SharedSessionContract#createQuery moved to
> org.hibernate.query.QueryProducer#createQuery,
> returning  org.hibernate.query.Query (which extends org.hibernate.Query);
> (org.hibernate.Session extends QueryProducer);
>
> In 6.0:
> * org.hibernate.Query was removed.
>
> Incompatibilities migrating from 5.3 -> 6.0:
> 1) Existing applications that explicitly use org.hibernate.Query (including
> javax.persistence.Query.unwrap( org.hibernate.Query.class )) will have to
> be changed to use org.hibernate.query.Query.
>
> org.hibernate.SQLQuery:
>
> In 5.1:
> * SharedSessionContract#createSQLQuery returns org.hibernate.SQLQuery
> (org.hibernate.Session extends SharedSessionContract);
>
> In 5.2/5.3:
> * SQLQuery was deprecated; NativeQuery should be used instead; NativeQuery
> extends SQLQuery;
> * SharedSessionContract#createSQLQuery moved to
> QueryProducer#createSQLQuery, returning  NativeQuery (which extends
> SQLQuery); Session extends QueryProducer;
> * QueryProducer#createSQLQuery is deprecated;
> QueryProducer#createNativeQuery
> should be used instead
>
> In 6.0:
> * SQLQuery and org.hibernate.query.QueryProducer#createSQLQuery are
> removed.
>
> Incompatibilities migrating from 5.3 -> 6.0:
> 1) Existing applications using Session#createSQLQuery will need to be
> updated to use Session#createNativeQuery.
> 2) Existing applications that explicitly use org.hibernate.SQLQuery
> (including javax.persistence.Query.unwrap( SQLQuery.class )) will have to
> be changed to use NativeQuery.
>
> org.hibernate.SynchronizeableQuery
>
> In 5.2/5.3:
> * org.hibernate.SynchronizeableQuery is not deprecated;
> * SQLQuery, NativeQuery and ProcedureCall extend org.hibernate.
> SynchronizeableQuery
>
> In 6.0:
> * org.hibernate.SynchronizeableQuery is moved to org.hibernate.query.
> SynchronizeableQuery;
> * NativeQuery and ProcedureCall extend
> org.hibernate.query.SynchronizeableQuery;
> (SQLQuery was removed as mentioned above)
>
> Incompatibilities migrating from 5.3 -> 6.0:
> 1) In 6.0, existing applications that use
> org.hibernate.SynchronizeableQuery
> (including javax.persistence.Query.unwrap(
> org.hibernate.SynchronizeableQuery.class
> )) will need to be updated to use org.hibernate.query.SynchronizeableQuery
>
> org.hibernate.Session#createFilter
>
> In 5.1:
> * Session#createFilter returns org.hibernate.Query;
>
> In 5.2/5.3:
> * Session#createFilter returns org.hibernate.query.Query (which extends
> org.hibernate.Query);
> * org.hibernate.Session#createFilter is not deprecated;
>
> In 6.0:
> * org.hibernate.Session#createFilter is removed.
>
> Incompatibilities migrating from 5.3 -> 6.0:
> 1) Existing applications that call Session#createFilter will need to be
> updated (to what???); does collection filter functionality exist in 6.0???
>
> org.hibernate.Session.#getTypeHelper
>
> In 5.1/5.2/5.3:
> * org.hibernate.Session.#getTypeHelper returns org.hibernate.TypeHelper;
> * Session#getTypeHelper is not deprecated;
>
> In 6.0: org.hibernate.Session.#getTypeHelper is removed;
>
> Incompatibilities migrating from 5.3 -> 6.0:
> 1) In 6.0, existing applications that call Session.#getTypeHelper will need
> to be updated (to what???).
>
> org.hibernate.metadata.ClassMetadata, org.hibernate.metadata.
> CollectionMetadata
>
> In 5.2/5.3:
> * SessionFactory#getClassMetadata(Class), #getClassMetadata(String),
> #getAllClassMetadata, #getCollectionMetadata, #getAllCollectionMetadata
> were deprecated; descriptors from
> javax.persistence.EntityManagerFactory#getMetamodel
> should be used instead; org.hibernate.SessionFactory extends
> javax.persistence.EntityManagerFactory;
>
> In 6.0:
> * ClassMetadata and CollectionMetadata removed.
>
> Incompatibilities migrating from 5.3 -> 6.0:
> 1) In 6.0, existing applications that call
> org.hibernate.SessionFactory#getClassMetadata(Class),
> #getClassMetadata(String), #getAllClassMetadata, #getCollectionMetadata,
> #getAllCollectionMetadata will need to be updated to use descripters from
> javax.persistence.EntityManagerFactory#getMetamodel.
>
> org.hibernate.stat.NaturalIdCacheStatistics
>
> In 5.2/5.3:
> * Statistics#getNaturalIdCacheStatistics returns NaturalIdCacheStatistics;
>
> In 6.0:
> * NaturalIdCacheStatistics is renamed to NaturalIdQueryStatistics;
> * NaturalIdQueryStatistics excludes #getHitCount, #getMissCount,
> #getPutCount, #getElementCountInMemory, #getElementCountOnDisk,
> #getSizeInMemory, and #getEntries which were originally in
> NaturalIdCacheStatistics; instead org.hibernate.stat.
> SecondLevelCacheStatistics#getHitCount, #getMissCount, #getPutCount,
> #getElementCountInMemory, #getElementCountOnDisk, #getSizeInMemory should
> be used.
> (SecondLevelCacheStatistics#getEntries was removed due to HHH-11356, so
> there is no substitute for org.hibernate.stat.NaturalIdCacheStatistics#
> getEntries;
> * Statistics#getNaturalIdCacheStatistics is renamed to
> #getNaturalIdStatistics.
>
> Incompatibilities migrating from 5.3 -> 6.0:
> 1) Existing applications that explicitly use NaturalIdCacheStatistics will
> need to be updated to use NaturalIdCacheStatistics.
> 2) Existing applications that call Statistics#getNaturalIdCacheStatistics
> will need to be updated to use Statistics#getNaturalIdCacheStatistics.
> 3) Existing applications that call org.hibernate.stat.
> NaturalIdCacheStatistics#getHitCount, #getMissCount, #getPutCount,
> #getElementCountInMemory, #getElementCountOnDisk, #getSizeInMemory, or
> #getEntries will need to be updated to obtain the
> SecondLevelCacheStatistics object for the particular natural ID using
> Statistics#getSecondLevelCacheStatistics( naturalIdRegionName??? ) (How is
> naturalIdRegionName determined???). The application will need to be changed
> to used SecondLevelCacheStatistics#getHitCount, #getMissCount,
> #getPutCount, #getElementCountInMemory, #getElementCountOnDisk, and
> #getSizeInMemory instead.
> 4) Existing applications that call NaturalIdCacheStatistics#getEntries will
> need to be updated to no longer call that method.
>
> org.hibernate.stat.SecondLevelCacheStatistics
>
> In 5.3:
> * SecondLevelCacheStatistics#getEntries is not deprecated;
>
> In 6.0:
> * SecondLevelCacheStatistics#getEntries is removed due to HHH-11356.
> * SecondLevelCacheStatistics no longer implements Serializable;
>
> Incompatibilities migrating from 5.3 -> 6.0:
> 1) Existing applications that call SecondLevelCacheStatistics#getEntries
> will need to be updated to no longer call that method.
> 2) Existing applications that implement SecondLevelCacheStatistics (SPI)
> will need to explicitly implement Serializable.
>
> QueryStatistics#getCacheHitCount, #getCacheMissCount, and #getCachePutCount
>
> In 5.3:
> * QueryStatistics#getCacheHitCount, #getCacheMissCount, and
> #getCachePutCount are not deprecated;
>
> In 6.0:
> * QueryStatistics#getCacheHitCount, #getCacheMissCount, and
> #getCachePutCount were removed;
> * ConcurrentQueryStatisticsImpl implements QueryStatistics and still
> contains public methods, #getCacheHitCount, #getCacheMissCount, and
> #getCachePutCount (why???).
>
> Incompatibilities migrating from 5.3 -> 6.0:
> 1) Existing applications that use
> org.hibernate.stat.QueryStatistics#getCacheHitCount,
> #getCacheMissCount, and #getCachePutCount will need to be changed (to use
> SecondLevelCacheStatistics???).
>
> org.hibernate.jpa.HibernateEntityManager
>
> In 5.2/5.3:
> * HibernateEntityManager is deprecated; Session (or SessionImplementor
> (SPI)) should be used instead;
> * Session extends HibernateEntityManager;
>
> In 6.0:
> * HibernateEntityManager is removed.
>
> Incompatibilities migrating from 5.3 -> 6.0:
> 1) In 6.0, existing applications that  explicitly use
> org.hibernate.jpa.HibernateEntityManager
> (including javax.persistence.EntityManager.unwrap(
> HibernateEntityManager.class )) will have to be changed to use Session (or
> SessionImplementor (SPI)).
>
> org.hibernate.jpa.HibernateEntityManagerFactory
>
> In 5.2/5.3:
> * HibernateEntityManagerFactory is deprecated; SessionFactory (or
> SessionFactoryImplementor (SPI)) should be used instead;
> * SessionFactory extends HibernateEntityManagerFactory;
>
> In 6.0:
> * HibernateEntityManagerFactory is removed.
>
> Incompatibilities migrating from 5.3 -> 6.0:
> 1) In 6.0, existing applications that explicitly use
> org.hibernate.jpa.HibernateEntityManagerFactory
> (including javax.persistence.EntityManagerFactory.unwrap(
> HibernateEntityManagerFactory.class )) will have to be changed to use
> Session (or SessionImplementor (SPI)).
>
> org.hibernate.Hibernate#unproxy
>
> In 5.2/5.3:
> * Hibernate#unproxy was introduced by HHH-10831 in 5.2.10
>
> In 6.0:
> * the fix for HHH-10831 has not been incorporated into 6.0, so it is not
> present. Will it be??
>
> Incompatibilities migrating from 5.3 -> 6.0:
> 1) Existing applications that use Hibernate#unproxy will have to be be
> changed to explicitly initialize and unproxy.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Feb 15 13:10:15 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 15 Feb 2018 18:10:15 +0000
Subject: [hibernate-dev] Starting 5.3 release
In-Reply-To: <CAFdSV9smv7Xt3Q649ejTP4aohF99TJaHYCOWsTPiiw-3o5sBYA@mail.gmail.com>
References: <CAFdSV9smv7Xt3Q649ejTP4aohF99TJaHYCOWsTPiiw-3o5sBYA@mail.gmail.com>
Message-ID: <CAFdSV9sza5GyRPhtW=6i5nXjmfxJCkpkf=-nhn_vRnuYrNJVCg@mail.gmail.com>

Well someone pushed.  Now I'm going to have to force push.  Grr


On Thu, Feb 15, 2018 at 8:50 AM Steve Ebersole <steve at hibernate.org> wrote:

> Per subject.  Please do not push to master for the time being...
>

From steve at hibernate.org  Thu Feb 15 13:12:47 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 15 Feb 2018 18:12:47 +0000
Subject: [hibernate-dev] Starting 5.3 release
In-Reply-To: <CAFdSV9sza5GyRPhtW=6i5nXjmfxJCkpkf=-nhn_vRnuYrNJVCg@mail.gmail.com>
References: <CAFdSV9smv7Xt3Q649ejTP4aohF99TJaHYCOWsTPiiw-3o5sBYA@mail.gmail.com>
	<CAFdSV9sza5GyRPhtW=6i5nXjmfxJCkpkf=-nhn_vRnuYrNJVCg@mail.gmail.com>
Message-ID: <CAFdSV9tXyhWkiYmuXd4G5Nv3=SjBFw8wng55v3AE0Q71Z9sD4Q@mail.gmail.com>

Actually I'll just rebase mine to the end.  History will be wrong for a few
commits, but it is what it is at this point

On Thu, Feb 15, 2018 at 12:10 PM Steve Ebersole <steve at hibernate.org> wrote:

> Well someone pushed.  Now I'm going to have to force push.  Grr
>
>
> On Thu, Feb 15, 2018 at 8:50 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Per subject.  Please do not push to master for the time being...
>>
>

From steve at hibernate.org  Thu Feb 15 13:54:15 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 15 Feb 2018 18:54:15 +0000
Subject: [hibernate-dev] Hibernate ORM 5.3.0.CR1 released
Message-ID: <CAFdSV9u8goc2AcvAPHFrmbZWWJTYqmJamQ0KnR2cUZGo1vc9rg@mail.gmail.com>

First release fully passing the standalone JPA TCK.

See http://in.relation.to/2018/02/15/hibernate-orm-530-cr1-release/

From sanne at hibernate.org  Thu Feb 15 14:46:45 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 15 Feb 2018 19:46:45 +0000
Subject: [hibernate-dev] Starting 5.3 release
In-Reply-To: <CAFdSV9tXyhWkiYmuXd4G5Nv3=SjBFw8wng55v3AE0Q71Z9sD4Q@mail.gmail.com>
References: <CAFdSV9smv7Xt3Q649ejTP4aohF99TJaHYCOWsTPiiw-3o5sBYA@mail.gmail.com>
	<CAFdSV9sza5GyRPhtW=6i5nXjmfxJCkpkf=-nhn_vRnuYrNJVCg@mail.gmail.com>
	<CAFdSV9tXyhWkiYmuXd4G5Nv3=SjBFw8wng55v3AE0Q71Z9sD4Q@mail.gmail.com>
Message-ID: <CAFm4XO2SfXvV=LJz_ihxfQSx2Ck3ZfF=uSeehbkRKWK=m5522w@mail.gmail.com>

You mean the tag of the release will be wrong? That's not so nice.

And what about Vlad's commits, are they included or not in the release
and changelogs?

On 15 February 2018 at 18:12, Steve Ebersole <steve at hibernate.org> wrote:
> Actually I'll just rebase mine to the end.  History will be wrong for a few
> commits, but it is what it is at this point
>
> On Thu, Feb 15, 2018 at 12:10 PM Steve Ebersole <steve at hibernate.org> wrote:
>
>> Well someone pushed.  Now I'm going to have to force push.  Grr
>>
>>
>> On Thu, Feb 15, 2018 at 8:50 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Per subject.  Please do not push to master for the time being...
>>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gbadner at redhat.com  Thu Feb 15 19:48:02 2018
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 15 Feb 2018 16:48:02 -0800
Subject: [hibernate-dev] API incompatibilities between Hibernate ORM 5.3
 and 6.0
In-Reply-To: <CAFdSV9seErrZbtQMbmUM5Ob16ga_8k0=9PxB2ur9xRPtN2JLOw@mail.gmail.com>
References: <CAFDzhiTD0td4La8zSaddsKBvxDO_hsBjNQK3vHxNhT7U+TxN9g@mail.gmail.com>
	<CAFdSV9seErrZbtQMbmUM5Ob16ga_8k0=9PxB2ur9xRPtN2JLOw@mail.gmail.com>
Message-ID: <CAFDzhiQHvLSr+DLPU_ZQKhA17FiHZfSXVkZCxy+amsgPjJsbWw@mail.gmail.com>

Hi Steve,

The list I provided contains removals from your fork in wip/6.0 branch.

IIUC, integrating changes from master will not restore what was deleted or
moved to a different package.  After integrating from master and resolving
conflicts, we'll have the same incompatibilities.

Am I missing something? Is there some other branch I should be comparing?

Regards,
Gail

On Thu, Feb 15, 2018 at 9:13 AM, Steve Ebersole <steve at hibernate.org> wrote:

> We have not integrated changes from master into 6.0 for a long time.  And
> we probably won't for some time yet either.  So comparisons between 5.2 or
> 5.3 and 6.0 right now are pointless
>
> On Wed, Feb 14, 2018 at 12:09 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> I sent this last night with a huge report file, and it seems that it
>> didn't
>> get out.
>>
>> I'm re-sending without the report file...
>>
>> I ran japi-compliance-checker to compare differences in APIs
>> between hibernate-core-5.3.0-SNAPSHOT.jar and hibernate-core-6.0.0-
>> SNAPSHOT.jar.
>>
>> I ran it last week, so it may not include updates made since that time.
>>
>> Differences in Envers shown in the report should be disregarded because it
>> only reflects that hibernate-envers was merged into hibernate-core. A
>> separate comparison between hibernate-envers-5.3.0-SNAPSHOT.jar and
>> hibernate-core-6.0.0-SNAPSHOT.jar needs to be done to see Envers changes.
>>
>> Chris will provide details about Envers differences in a separate email.
>>
>> The report is huge; it took me 3 to 4 hours to scan it. AFAICT, what I've
>> documented are the only non-Envers API changes that could affect
>> applications. They all involve removed classes/methods.
>>
>> My intention here is just to get this information out, so we have some
>> solid examples to discuss.
>>
>> Regards,
>> Gail
>>
>> ------------------------------------------------------------
>> ----------------------------------------------------------------------
>>
>> Custom types: I am not familiar with how this will work in 6.0. Steve,
>> please fill in details about any incompatibilities.
>>
>> org.hibernate.Criteria and org.hibernate.criterion.DetachedCriteria:
>>
>> In 5.0/5.1/5.2:
>> * user guides say, "This appendix covers the legacy Hibernate
>> org.hibernate.Criteria API, which should be considered deprecated. New
>> development should focus on the JPA javax.persistence.criteria.Cri
>> teriaQuery
>> API. Eventually, Hibernate-specific criteria features will be ported as
>> extensions to the JPA javax.persistence.criteria.CriteriaQuery. For
>> details
>> on the JPA APIs, see Criteria."
>>
>> In 5.2/5.3:
>> * Criteria and DetachedCriteria are not deprecated;
>> * all SharedSessionContract#createCriteria methods are deprecated;
>> * public static methods in DetachedCriteria are not deprecated;
>>
>> In 6.0:
>> * Criteria and DetachedCriteria are removed along with other classes in
>> org.hibernate.criterion.
>>
>> Incompatibilities migrating from 5.3 -> 6.0:
>> 1) Existing applications using legacy org.hibernate.Criteria will need to
>> be updated to use javax.persistence.criteria.CriteriaQuery;
>> 2) If Hibernate's implementation of javax.persistence.criteria.Cri
>> teriaQuery
>> does not include the Hibernate-specific extensions that were available
>> using org.hibernate.Criteria, applications may not have a straightforward
>> way to change their applications to work.
>>
>> org.hibernate.Query
>>
>> In 5.1:
>> * SharedSessionContract#createQuery returns org.hibernate.Query
>> (org.hibernate.Session extends SharedSessionContract);
>>
>> In 5.2/5.3:
>> * org.hibernate.Query was deprecated; org.hibernate.query.Query should be
>> used instead; org.hibernate.query.Query extends org.hibernate.Query;
>> * SharedSessionContract#createQuery moved to
>> org.hibernate.query.QueryProducer#createQuery,
>> returning  org.hibernate.query.Query (which extends org.hibernate.Query);
>> (org.hibernate.Session extends QueryProducer);
>>
>> In 6.0:
>> * org.hibernate.Query was removed.
>>
>> Incompatibilities migrating from 5.3 -> 6.0:
>> 1) Existing applications that explicitly use org.hibernate.Query
>> (including
>> javax.persistence.Query.unwrap( org.hibernate.Query.class )) will have to
>> be changed to use org.hibernate.query.Query.
>>
>> org.hibernate.SQLQuery:
>>
>> In 5.1:
>> * SharedSessionContract#createSQLQuery returns org.hibernate.SQLQuery
>> (org.hibernate.Session extends SharedSessionContract);
>>
>> In 5.2/5.3:
>> * SQLQuery was deprecated; NativeQuery should be used instead; NativeQuery
>> extends SQLQuery;
>> * SharedSessionContract#createSQLQuery moved to
>> QueryProducer#createSQLQuery, returning  NativeQuery (which extends
>> SQLQuery); Session extends QueryProducer;
>> * QueryProducer#createSQLQuery is deprecated;
>> QueryProducer#createNativeQuery
>> should be used instead
>>
>> In 6.0:
>> * SQLQuery and org.hibernate.query.QueryProducer#createSQLQuery are
>> removed.
>>
>> Incompatibilities migrating from 5.3 -> 6.0:
>> 1) Existing applications using Session#createSQLQuery will need to be
>> updated to use Session#createNativeQuery.
>> 2) Existing applications that explicitly use org.hibernate.SQLQuery
>> (including javax.persistence.Query.unwrap( SQLQuery.class )) will have to
>> be changed to use NativeQuery.
>>
>> org.hibernate.SynchronizeableQuery
>>
>> In 5.2/5.3:
>> * org.hibernate.SynchronizeableQuery is not deprecated;
>> * SQLQuery, NativeQuery and ProcedureCall extend org.hibernate.
>> SynchronizeableQuery
>>
>> In 6.0:
>> * org.hibernate.SynchronizeableQuery is moved to org.hibernate.query.
>> SynchronizeableQuery;
>> * NativeQuery and ProcedureCall extend
>> org.hibernate.query.SynchronizeableQuery;
>> (SQLQuery was removed as mentioned above)
>>
>> Incompatibilities migrating from 5.3 -> 6.0:
>> 1) In 6.0, existing applications that use org.hibernate.SynchronizeableQ
>> uery
>> (including javax.persistence.Query.unwrap(
>> org.hibernate.SynchronizeableQuery.class
>> )) will need to be updated to use org.hibernate.query.Synchroniz
>> eableQuery
>>
>> org.hibernate.Session#createFilter
>>
>> In 5.1:
>> * Session#createFilter returns org.hibernate.Query;
>>
>> In 5.2/5.3:
>> * Session#createFilter returns org.hibernate.query.Query (which extends
>> org.hibernate.Query);
>> * org.hibernate.Session#createFilter is not deprecated;
>>
>> In 6.0:
>> * org.hibernate.Session#createFilter is removed.
>>
>> Incompatibilities migrating from 5.3 -> 6.0:
>> 1) Existing applications that call Session#createFilter will need to be
>> updated (to what???); does collection filter functionality exist in 6.0???
>>
>> org.hibernate.Session.#getTypeHelper
>>
>> In 5.1/5.2/5.3:
>> * org.hibernate.Session.#getTypeHelper returns org.hibernate.TypeHelper;
>> * Session#getTypeHelper is not deprecated;
>>
>> In 6.0: org.hibernate.Session.#getTypeHelper is removed;
>>
>> Incompatibilities migrating from 5.3 -> 6.0:
>> 1) In 6.0, existing applications that call Session.#getTypeHelper will
>> need
>> to be updated (to what???).
>>
>> org.hibernate.metadata.ClassMetadata, org.hibernate.metadata.
>> CollectionMetadata
>>
>> In 5.2/5.3:
>> * SessionFactory#getClassMetadata(Class), #getClassMetadata(String),
>> #getAllClassMetadata, #getCollectionMetadata, #getAllCollectionMetadata
>> were deprecated; descriptors from
>> javax.persistence.EntityManagerFactory#getMetamodel
>> should be used instead; org.hibernate.SessionFactory extends
>> javax.persistence.EntityManagerFactory;
>>
>> In 6.0:
>> * ClassMetadata and CollectionMetadata removed.
>>
>> Incompatibilities migrating from 5.3 -> 6.0:
>> 1) In 6.0, existing applications that call
>> org.hibernate.SessionFactory#getClassMetadata(Class),
>> #getClassMetadata(String), #getAllClassMetadata, #getCollectionMetadata,
>> #getAllCollectionMetadata will need to be updated to use descripters from
>> javax.persistence.EntityManagerFactory#getMetamodel.
>>
>> org.hibernate.stat.NaturalIdCacheStatistics
>>
>> In 5.2/5.3:
>> * Statistics#getNaturalIdCacheStatistics returns
>> NaturalIdCacheStatistics;
>>
>> In 6.0:
>> * NaturalIdCacheStatistics is renamed to NaturalIdQueryStatistics;
>> * NaturalIdQueryStatistics excludes #getHitCount, #getMissCount,
>> #getPutCount, #getElementCountInMemory, #getElementCountOnDisk,
>> #getSizeInMemory, and #getEntries which were originally in
>> NaturalIdCacheStatistics; instead org.hibernate.stat.
>> SecondLevelCacheStatistics#getHitCount, #getMissCount, #getPutCount,
>>
>> #getElementCountInMemory, #getElementCountOnDisk, #getSizeInMemory should
>> be used.
>> (SecondLevelCacheStatistics#getEntries was removed due to HHH-11356, so
>> there is no substitute for org.hibernate.stat.NaturalIdCacheStatistics#
>> getEntries;
>> * Statistics#getNaturalIdCacheStatistics is renamed to
>> #getNaturalIdStatistics.
>>
>> Incompatibilities migrating from 5.3 -> 6.0:
>> 1) Existing applications that explicitly use NaturalIdCacheStatistics will
>> need to be updated to use NaturalIdCacheStatistics.
>> 2) Existing applications that call Statistics#getNaturalIdCacheStatistics
>> will need to be updated to use Statistics#getNaturalIdCacheStatistics.
>> 3) Existing applications that call org.hibernate.stat.
>> NaturalIdCacheStatistics#getHitCount, #getMissCount, #getPutCount,
>> #getElementCountInMemory, #getElementCountOnDisk, #getSizeInMemory, or
>> #getEntries will need to be updated to obtain the
>> SecondLevelCacheStatistics object for the particular natural ID using
>> Statistics#getSecondLevelCacheStatistics( naturalIdRegionName??? ) (How
>> is
>> naturalIdRegionName determined???). The application will need to be
>> changed
>> to used SecondLevelCacheStatistics#getHitCount, #getMissCount,
>> #getPutCount, #getElementCountInMemory, #getElementCountOnDisk, and
>> #getSizeInMemory instead.
>> 4) Existing applications that call NaturalIdCacheStatistics#getEntries
>> will
>> need to be updated to no longer call that method.
>>
>> org.hibernate.stat.SecondLevelCacheStatistics
>>
>> In 5.3:
>> * SecondLevelCacheStatistics#getEntries is not deprecated;
>>
>> In 6.0:
>> * SecondLevelCacheStatistics#getEntries is removed due to HHH-11356.
>> * SecondLevelCacheStatistics no longer implements Serializable;
>>
>> Incompatibilities migrating from 5.3 -> 6.0:
>> 1) Existing applications that call SecondLevelCacheStatistics#getEntries
>> will need to be updated to no longer call that method.
>> 2) Existing applications that implement SecondLevelCacheStatistics (SPI)
>> will need to explicitly implement Serializable.
>>
>> QueryStatistics#getCacheHitCount, #getCacheMissCount, and
>> #getCachePutCount
>>
>> In 5.3:
>> * QueryStatistics#getCacheHitCount, #getCacheMissCount, and
>> #getCachePutCount are not deprecated;
>>
>> In 6.0:
>> * QueryStatistics#getCacheHitCount, #getCacheMissCount, and
>> #getCachePutCount were removed;
>> * ConcurrentQueryStatisticsImpl implements QueryStatistics and still
>> contains public methods, #getCacheHitCount, #getCacheMissCount, and
>> #getCachePutCount (why???).
>>
>> Incompatibilities migrating from 5.3 -> 6.0:
>> 1) Existing applications that use
>> org.hibernate.stat.QueryStatistics#getCacheHitCount,
>> #getCacheMissCount, and #getCachePutCount will need to be changed (to use
>> SecondLevelCacheStatistics???).
>>
>> org.hibernate.jpa.HibernateEntityManager
>>
>> In 5.2/5.3:
>> * HibernateEntityManager is deprecated; Session (or SessionImplementor
>> (SPI)) should be used instead;
>> * Session extends HibernateEntityManager;
>>
>> In 6.0:
>> * HibernateEntityManager is removed.
>>
>> Incompatibilities migrating from 5.3 -> 6.0:
>> 1) In 6.0, existing applications that  explicitly use
>> org.hibernate.jpa.HibernateEntityManager
>> (including javax.persistence.EntityManager.unwrap(
>> HibernateEntityManager.class )) will have to be changed to use Session (or
>> SessionImplementor (SPI)).
>>
>> org.hibernate.jpa.HibernateEntityManagerFactory
>>
>> In 5.2/5.3:
>> * HibernateEntityManagerFactory is deprecated; SessionFactory (or
>> SessionFactoryImplementor (SPI)) should be used instead;
>> * SessionFactory extends HibernateEntityManagerFactory;
>>
>> In 6.0:
>> * HibernateEntityManagerFactory is removed.
>>
>> Incompatibilities migrating from 5.3 -> 6.0:
>> 1) In 6.0, existing applications that explicitly use
>> org.hibernate.jpa.HibernateEntityManagerFactory
>> (including javax.persistence.EntityManagerFactory.unwrap(
>> HibernateEntityManagerFactory.class )) will have to be changed to use
>> Session (or SessionImplementor (SPI)).
>>
>> org.hibernate.Hibernate#unproxy
>>
>> In 5.2/5.3:
>> * Hibernate#unproxy was introduced by HHH-10831 in 5.2.10
>>
>> In 6.0:
>> * the fix for HHH-10831 has not been incorporated into 6.0, so it is not
>> present. Will it be??
>>
>> Incompatibilities migrating from 5.3 -> 6.0:
>> 1) Existing applications that use Hibernate#unproxy will have to be be
>> changed to explicitly initialize and unproxy.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Thu Feb 15 23:05:44 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 16 Feb 2018 04:05:44 +0000
Subject: [hibernate-dev] API incompatibilities between Hibernate ORM 5.3
 and 6.0
In-Reply-To: <CAFDzhiQHvLSr+DLPU_ZQKhA17FiHZfSXVkZCxy+amsgPjJsbWw@mail.gmail.com>
References: <CAFDzhiTD0td4La8zSaddsKBvxDO_hsBjNQK3vHxNhT7U+TxN9g@mail.gmail.com>
	<CAFdSV9seErrZbtQMbmUM5Ob16ga_8k0=9PxB2ur9xRPtN2JLOw@mail.gmail.com>
	<CAFDzhiQHvLSr+DLPU_ZQKhA17FiHZfSXVkZCxy+amsgPjJsbWw@mail.gmail.com>
Message-ID: <CAFdSV9uX6_yk4Zc8cN4c=41y0AnjYCzzB8xE=n4CkvfW9H7yHw@mail.gmail.com>

I'm not sure what else to tell you.  Sure some things have been removed.

I'm not going to go through all of these right now.  If there are some in
particular you are interested please bring those of specifically.


On Thu, Feb 15, 2018 at 6:48 PM Gail Badner <gbadner at redhat.com> wrote:

> Hi Steve,
>
> The list I provided contains removals from your fork in wip/6.0 branch.
>
> IIUC, integrating changes from master will not restore what was deleted
> or moved to a different package.  After integrating from master and
> resolving conflicts, we'll have the same incompatibilities.
>
> Am I missing something? Is there some other branch I should be comparing?
>
> Regards,
> Gail
>
> On Thu, Feb 15, 2018 at 9:13 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> We have not integrated changes from master into 6.0 for a long time.  And
>> we probably won't for some time yet either.  So comparisons between 5.2 or
>> 5.3 and 6.0 right now are pointless
>>
>> On Wed, Feb 14, 2018 at 12:09 PM Gail Badner <gbadner at redhat.com> wrote:
>>
>>> I sent this last night with a huge report file, and it seems that it
>>> didn't
>>> get out.
>>>
>>> I'm re-sending without the report file...
>>>
>>> I ran japi-compliance-checker to compare differences in APIs
>>> between hibernate-core-5.3.0-SNAPSHOT.jar and hibernate-core-6.0.0-
>>> SNAPSHOT.jar.
>>>
>>> I ran it last week, so it may not include updates made since that time.
>>>
>>> Differences in Envers shown in the report should be disregarded because
>>> it
>>> only reflects that hibernate-envers was merged into hibernate-core. A
>>> separate comparison between hibernate-envers-5.3.0-SNAPSHOT.jar and
>>> hibernate-core-6.0.0-SNAPSHOT.jar needs to be done to see Envers changes.
>>>
>>> Chris will provide details about Envers differences in a separate email.
>>>
>>> The report is huge; it took me 3 to 4 hours to scan it. AFAICT, what I've
>>> documented are the only non-Envers API changes that could affect
>>> applications. They all involve removed classes/methods.
>>>
>>> My intention here is just to get this information out, so we have some
>>> solid examples to discuss.
>>>
>>> Regards,
>>> Gail
>>>
>>> ------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>>
>>> Custom types: I am not familiar with how this will work in 6.0. Steve,
>>> please fill in details about any incompatibilities.
>>>
>>> org.hibernate.Criteria and org.hibernate.criterion.DetachedCriteria:
>>>
>>> In 5.0/5.1/5.2:
>>> * user guides say, "This appendix covers the legacy Hibernate
>>> org.hibernate.Criteria API, which should be considered deprecated. New
>>> development should focus on the JPA
>>> javax.persistence.criteria.CriteriaQuery
>>> API. Eventually, Hibernate-specific criteria features will be ported as
>>> extensions to the JPA javax.persistence.criteria.CriteriaQuery. For
>>> details
>>> on the JPA APIs, see Criteria."
>>>
>>> In 5.2/5.3:
>>> * Criteria and DetachedCriteria are not deprecated;
>>> * all SharedSessionContract#createCriteria methods are deprecated;
>>> * public static methods in DetachedCriteria are not deprecated;
>>>
>>> In 6.0:
>>> * Criteria and DetachedCriteria are removed along with other classes in
>>> org.hibernate.criterion.
>>>
>>> Incompatibilities migrating from 5.3 -> 6.0:
>>> 1) Existing applications using legacy org.hibernate.Criteria will need to
>>> be updated to use javax.persistence.criteria.CriteriaQuery;
>>> 2) If Hibernate's implementation of
>>> javax.persistence.criteria.CriteriaQuery
>>> does not include the Hibernate-specific extensions that were available
>>> using org.hibernate.Criteria, applications may not have a straightforward
>>> way to change their applications to work.
>>>
>>> org.hibernate.Query
>>>
>>> In 5.1:
>>> * SharedSessionContract#createQuery returns org.hibernate.Query
>>> (org.hibernate.Session extends SharedSessionContract);
>>>
>>> In 5.2/5.3:
>>> * org.hibernate.Query was deprecated; org.hibernate.query.Query should be
>>> used instead; org.hibernate.query.Query extends org.hibernate.Query;
>>> * SharedSessionContract#createQuery moved to
>>> org.hibernate.query.QueryProducer#createQuery,
>>> returning  org.hibernate.query.Query (which extends org.hibernate.Query);
>>> (org.hibernate.Session extends QueryProducer);
>>>
>>> In 6.0:
>>> * org.hibernate.Query was removed.
>>>
>>> Incompatibilities migrating from 5.3 -> 6.0:
>>> 1) Existing applications that explicitly use org.hibernate.Query
>>> (including
>>> javax.persistence.Query.unwrap( org.hibernate.Query.class )) will have to
>>> be changed to use org.hibernate.query.Query.
>>>
>>> org.hibernate.SQLQuery:
>>>
>>> In 5.1:
>>> * SharedSessionContract#createSQLQuery returns org.hibernate.SQLQuery
>>> (org.hibernate.Session extends SharedSessionContract);
>>>
>>> In 5.2/5.3:
>>> * SQLQuery was deprecated; NativeQuery should be used instead;
>>> NativeQuery
>>> extends SQLQuery;
>>> * SharedSessionContract#createSQLQuery moved to
>>> QueryProducer#createSQLQuery, returning  NativeQuery (which extends
>>> SQLQuery); Session extends QueryProducer;
>>> * QueryProducer#createSQLQuery is deprecated;
>>> QueryProducer#createNativeQuery
>>> should be used instead
>>>
>>> In 6.0:
>>> * SQLQuery and org.hibernate.query.QueryProducer#createSQLQuery are
>>> removed.
>>>
>>> Incompatibilities migrating from 5.3 -> 6.0:
>>> 1) Existing applications using Session#createSQLQuery will need to be
>>> updated to use Session#createNativeQuery.
>>> 2) Existing applications that explicitly use org.hibernate.SQLQuery
>>> (including javax.persistence.Query.unwrap( SQLQuery.class )) will have to
>>> be changed to use NativeQuery.
>>>
>>> org.hibernate.SynchronizeableQuery
>>>
>>> In 5.2/5.3:
>>> * org.hibernate.SynchronizeableQuery is not deprecated;
>>> * SQLQuery, NativeQuery and ProcedureCall extend org.hibernate.
>>> SynchronizeableQuery
>>>
>>> In 6.0:
>>> * org.hibernate.SynchronizeableQuery is moved to org.hibernate.query.
>>> SynchronizeableQuery;
>>> * NativeQuery and ProcedureCall extend
>>> org.hibernate.query.SynchronizeableQuery;
>>> (SQLQuery was removed as mentioned above)
>>>
>>> Incompatibilities migrating from 5.3 -> 6.0:
>>> 1) In 6.0, existing applications that use
>>> org.hibernate.SynchronizeableQuery
>>> (including javax.persistence.Query.unwrap(
>>> org.hibernate.SynchronizeableQuery.class
>>> )) will need to be updated to use
>>> org.hibernate.query.SynchronizeableQuery
>>>
>>> org.hibernate.Session#createFilter
>>>
>>> In 5.1:
>>> * Session#createFilter returns org.hibernate.Query;
>>>
>>> In 5.2/5.3:
>>> * Session#createFilter returns org.hibernate.query.Query (which extends
>>> org.hibernate.Query);
>>> * org.hibernate.Session#createFilter is not deprecated;
>>>
>>> In 6.0:
>>> * org.hibernate.Session#createFilter is removed.
>>>
>>> Incompatibilities migrating from 5.3 -> 6.0:
>>> 1) Existing applications that call Session#createFilter will need to be
>>> updated (to what???); does collection filter functionality exist in
>>> 6.0???
>>>
>>> org.hibernate.Session.#getTypeHelper
>>>
>>> In 5.1/5.2/5.3:
>>> * org.hibernate.Session.#getTypeHelper returns org.hibernate.TypeHelper;
>>> * Session#getTypeHelper is not deprecated;
>>>
>>> In 6.0: org.hibernate.Session.#getTypeHelper is removed;
>>>
>>> Incompatibilities migrating from 5.3 -> 6.0:
>>> 1) In 6.0, existing applications that call Session.#getTypeHelper will
>>> need
>>> to be updated (to what???).
>>>
>>> org.hibernate.metadata.ClassMetadata, org.hibernate.metadata.
>>> CollectionMetadata
>>>
>>> In 5.2/5.3:
>>> * SessionFactory#getClassMetadata(Class), #getClassMetadata(String),
>>> #getAllClassMetadata, #getCollectionMetadata, #getAllCollectionMetadata
>>> were deprecated; descriptors from
>>> javax.persistence.EntityManagerFactory#getMetamodel
>>> should be used instead; org.hibernate.SessionFactory extends
>>> javax.persistence.EntityManagerFactory;
>>>
>>> In 6.0:
>>> * ClassMetadata and CollectionMetadata removed.
>>>
>>> Incompatibilities migrating from 5.3 -> 6.0:
>>> 1) In 6.0, existing applications that call
>>> org.hibernate.SessionFactory#getClassMetadata(Class),
>>> #getClassMetadata(String), #getAllClassMetadata, #getCollectionMetadata,
>>> #getAllCollectionMetadata will need to be updated to use descripters from
>>> javax.persistence.EntityManagerFactory#getMetamodel.
>>>
>>> org.hibernate.stat.NaturalIdCacheStatistics
>>>
>>> In 5.2/5.3:
>>> * Statistics#getNaturalIdCacheStatistics returns
>>> NaturalIdCacheStatistics;
>>>
>>> In 6.0:
>>> * NaturalIdCacheStatistics is renamed to NaturalIdQueryStatistics;
>>> * NaturalIdQueryStatistics excludes #getHitCount, #getMissCount,
>>> #getPutCount, #getElementCountInMemory, #getElementCountOnDisk,
>>> #getSizeInMemory, and #getEntries which were originally in
>>> NaturalIdCacheStatistics; instead org.hibernate.stat.
>>> SecondLevelCacheStatistics#getHitCount, #getMissCount, #getPutCount,
>>>
>>> #getElementCountInMemory, #getElementCountOnDisk, #getSizeInMemory should
>>> be used.
>>> (SecondLevelCacheStatistics#getEntries was removed due to HHH-11356, so
>>> there is no substitute for org.hibernate.stat.NaturalIdCacheStatistics#
>>> getEntries;
>>> * Statistics#getNaturalIdCacheStatistics is renamed to
>>> #getNaturalIdStatistics.
>>>
>>> Incompatibilities migrating from 5.3 -> 6.0:
>>> 1) Existing applications that explicitly use NaturalIdCacheStatistics
>>> will
>>> need to be updated to use NaturalIdCacheStatistics.
>>> 2) Existing applications that call Statistics#getNaturalIdCacheStatistics
>>> will need to be updated to use Statistics#getNaturalIdCacheStatistics.
>>> 3) Existing applications that call org.hibernate.stat.
>>> NaturalIdCacheStatistics#getHitCount, #getMissCount, #getPutCount,
>>> #getElementCountInMemory, #getElementCountOnDisk, #getSizeInMemory, or
>>> #getEntries will need to be updated to obtain the
>>> SecondLevelCacheStatistics object for the particular natural ID using
>>> Statistics#getSecondLevelCacheStatistics( naturalIdRegionName??? ) (How
>>> is
>>> naturalIdRegionName determined???). The application will need to be
>>> changed
>>> to used SecondLevelCacheStatistics#getHitCount, #getMissCount,
>>> #getPutCount, #getElementCountInMemory, #getElementCountOnDisk, and
>>> #getSizeInMemory instead.
>>> 4) Existing applications that call NaturalIdCacheStatistics#getEntries
>>> will
>>> need to be updated to no longer call that method.
>>>
>>> org.hibernate.stat.SecondLevelCacheStatistics
>>>
>>> In 5.3:
>>> * SecondLevelCacheStatistics#getEntries is not deprecated;
>>>
>>> In 6.0:
>>> * SecondLevelCacheStatistics#getEntries is removed due to HHH-11356.
>>> * SecondLevelCacheStatistics no longer implements Serializable;
>>>
>>> Incompatibilities migrating from 5.3 -> 6.0:
>>> 1) Existing applications that call SecondLevelCacheStatistics#getEntries
>>> will need to be updated to no longer call that method.
>>> 2) Existing applications that implement SecondLevelCacheStatistics (SPI)
>>> will need to explicitly implement Serializable.
>>>
>>> QueryStatistics#getCacheHitCount, #getCacheMissCount, and
>>> #getCachePutCount
>>>
>>> In 5.3:
>>> * QueryStatistics#getCacheHitCount, #getCacheMissCount, and
>>> #getCachePutCount are not deprecated;
>>>
>>> In 6.0:
>>> * QueryStatistics#getCacheHitCount, #getCacheMissCount, and
>>> #getCachePutCount were removed;
>>> * ConcurrentQueryStatisticsImpl implements QueryStatistics and still
>>> contains public methods, #getCacheHitCount, #getCacheMissCount, and
>>> #getCachePutCount (why???).
>>>
>>> Incompatibilities migrating from 5.3 -> 6.0:
>>> 1) Existing applications that use
>>> org.hibernate.stat.QueryStatistics#getCacheHitCount,
>>> #getCacheMissCount, and #getCachePutCount will need to be changed (to use
>>> SecondLevelCacheStatistics???).
>>>
>>> org.hibernate.jpa.HibernateEntityManager
>>>
>>> In 5.2/5.3:
>>> * HibernateEntityManager is deprecated; Session (or SessionImplementor
>>> (SPI)) should be used instead;
>>> * Session extends HibernateEntityManager;
>>>
>>> In 6.0:
>>> * HibernateEntityManager is removed.
>>>
>>> Incompatibilities migrating from 5.3 -> 6.0:
>>> 1) In 6.0, existing applications that  explicitly use
>>> org.hibernate.jpa.HibernateEntityManager
>>> (including javax.persistence.EntityManager.unwrap(
>>> HibernateEntityManager.class )) will have to be changed to use Session
>>> (or
>>> SessionImplementor (SPI)).
>>>
>>> org.hibernate.jpa.HibernateEntityManagerFactory
>>>
>>> In 5.2/5.3:
>>> * HibernateEntityManagerFactory is deprecated; SessionFactory (or
>>> SessionFactoryImplementor (SPI)) should be used instead;
>>> * SessionFactory extends HibernateEntityManagerFactory;
>>>
>>> In 6.0:
>>> * HibernateEntityManagerFactory is removed.
>>>
>>> Incompatibilities migrating from 5.3 -> 6.0:
>>> 1) In 6.0, existing applications that explicitly use
>>> org.hibernate.jpa.HibernateEntityManagerFactory
>>> (including javax.persistence.EntityManagerFactory.unwrap(
>>> HibernateEntityManagerFactory.class )) will have to be changed to use
>>> Session (or SessionImplementor (SPI)).
>>>
>>> org.hibernate.Hibernate#unproxy
>>>
>>> In 5.2/5.3:
>>> * Hibernate#unproxy was introduced by HHH-10831 in 5.2.10
>>>
>>> In 6.0:
>>> * the fix for HHH-10831 has not been incorporated into 6.0, so it is not
>>> present. Will it be??
>>>
>>> Incompatibilities migrating from 5.3 -> 6.0:
>>> 1) Existing applications that use Hibernate#unproxy will have to be be
>>> changed to explicitly initialize and unproxy.
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>

From jonathan.bregler at sap.com  Fri Feb 16 04:21:36 2018
From: jonathan.bregler at sap.com (Bregler, Jonathan)
Date: Fri, 16 Feb 2018 09:21:36 +0000
Subject: [hibernate-dev] Empty IN list support
Message-ID: <461af5db78014faa8cc3dd761b751c52@sap.com>

Hi,

HANA doesn't support empty IN lists, so executing an HQL query that gets transformed into a SQL query with an empty IN list results in a SQL parser error on the database side. I noticed that the Dialect class already defines a method called "supportsEmptyInList()" which according to the Javadoc returns "True if empty in lists are supported; false otherwise". However, this method doesn't seem to be used anywhere in the Hibernate code. Is there a reason for that?

Thanks,
Jonathan

From mihalcea.vlad at gmail.com  Fri Feb 16 05:23:40 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 16 Feb 2018 12:23:40 +0200
Subject: [hibernate-dev] Empty IN list support
In-Reply-To: <461af5db78014faa8cc3dd761b751c52@sap.com>
References: <461af5db78014faa8cc3dd761b751c52@sap.com>
Message-ID: <CA+gWKMAriVw8qowwRA0UU7urno6ANpiCBRy9zKUKj=BV++XKTg@mail.gmail.com>

I see that we are only using it for testing so that we can skip the:

testEmptyInListQuery

query on certain Dialects.

We could use this info when rendering the JPQL/HQL queries to throw an
exception before executing the query.
Nevertheless, an exception will be thrown anyway even if we don't do it.

Vlad

On Fri, Feb 16, 2018 at 11:21 AM, Bregler, Jonathan <
jonathan.bregler at sap.com> wrote:

> Hi,
>
> HANA doesn't support empty IN lists, so executing an HQL query that gets
> transformed into a SQL query with an empty IN list results in a SQL parser
> error on the database side. I noticed that the Dialect class already
> defines a method called "supportsEmptyInList()" which according to the
> Javadoc returns "True if empty in lists are supported; false otherwise".
> However, this method doesn't seem to be used anywhere in the Hibernate
> code. Is there a reason for that?
>
> Thanks,
> Jonathan
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From guillaume.smet at gmail.com  Fri Feb 16 05:38:38 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 16 Feb 2018 11:38:38 +0100
Subject: [hibernate-dev] Empty IN list support
In-Reply-To: <CA+gWKMAriVw8qowwRA0UU7urno6ANpiCBRy9zKUKj=BV++XKTg@mail.gmail.com>
References: <461af5db78014faa8cc3dd761b751c52@sap.com>
	<CA+gWKMAriVw8qowwRA0UU7urno6ANpiCBRy9zKUKj=BV++XKTg@mail.gmail.com>
Message-ID: <CALt0+o9wO6q3L59bq8BOAAG4WC=DvRVstiNYTxLwhmRvMcjqkQ@mail.gmail.com>

See this related issue: https://hibernate.atlassian.net/browse/HHH-8091

On Fri, Feb 16, 2018 at 11:23 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I see that we are only using it for testing so that we can skip the:
>
> testEmptyInListQuery
>
> query on certain Dialects.
>
> We could use this info when rendering the JPQL/HQL queries to throw an
> exception before executing the query.
> Nevertheless, an exception will be thrown anyway even if we don't do it.
>
> Vlad
>
> On Fri, Feb 16, 2018 at 11:21 AM, Bregler, Jonathan <
> jonathan.bregler at sap.com> wrote:
>
> > Hi,
> >
> > HANA doesn't support empty IN lists, so executing an HQL query that gets
> > transformed into a SQL query with an empty IN list results in a SQL
> parser
> > error on the database side. I noticed that the Dialect class already
> > defines a method called "supportsEmptyInList()" which according to the
> > Javadoc returns "True if empty in lists are supported; false otherwise".
> > However, this method doesn't seem to be used anywhere in the Hibernate
> > code. Is there a reason for that?
> >
> > Thanks,
> > Jonathan
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From jonathan.bregler at sap.com  Fri Feb 16 05:57:33 2018
From: jonathan.bregler at sap.com (Bregler, Jonathan)
Date: Fri, 16 Feb 2018 10:57:33 +0000
Subject: [hibernate-dev] Empty IN list support
In-Reply-To: <CALt0+o9wO6q3L59bq8BOAAG4WC=DvRVstiNYTxLwhmRvMcjqkQ@mail.gmail.com>
References: <461af5db78014faa8cc3dd761b751c52@sap.com>
	<CA+gWKMAriVw8qowwRA0UU7urno6ANpiCBRy9zKUKj=BV++XKTg@mail.gmail.com>
	<CALt0+o9wO6q3L59bq8BOAAG4WC=DvRVstiNYTxLwhmRvMcjqkQ@mail.gmail.com>
Message-ID: <9c158c39a7774384977fbd732903615c@sap.com>

Ok, thanks. For some reason I missed the Jira issue.

- Jonathan

From: Guillaume Smet [mailto:guillaume.smet at gmail.com]
Sent: Friday, February 16, 2018 11:39 AM
To: Vlad Mihalcea <mihalcea.vlad at gmail.com>
Cc: Bregler, Jonathan <jonathan.bregler at sap.com>; hibernate-dev at lists.jboss.org
Subject: Re: [hibernate-dev] Empty IN list support

See this related issue: https://hibernate.atlassian.net/browse/HHH-8091

On Fri, Feb 16, 2018 at 11:23 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com<mailto:mihalcea.vlad at gmail.com>> wrote:
I see that we are only using it for testing so that we can skip the:

testEmptyInListQuery

query on certain Dialects.

We could use this info when rendering the JPQL/HQL queries to throw an
exception before executing the query.
Nevertheless, an exception will be thrown anyway even if we don't do it.

Vlad

On Fri, Feb 16, 2018 at 11:21 AM, Bregler, Jonathan <
jonathan.bregler at sap.com<mailto:jonathan.bregler at sap.com>> wrote:

> Hi,
>
> HANA doesn't support empty IN lists, so executing an HQL query that gets
> transformed into a SQL query with an empty IN list results in a SQL parser
> error on the database side. I noticed that the Dialect class already
> defines a method called "supportsEmptyInList()" which according to the
> Javadoc returns "True if empty in lists are supported; false otherwise".
> However, this method doesn't seem to be used anywhere in the Hibernate
> code. Is there a reason for that?
>
> Thanks,
> Jonathan
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org<mailto:hibernate-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org<mailto:hibernate-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Fri Feb 16 06:22:00 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 16 Feb 2018 11:22:00 +0000
Subject: [hibernate-dev] Empty IN list support
In-Reply-To: <9c158c39a7774384977fbd732903615c@sap.com>
References: <461af5db78014faa8cc3dd761b751c52@sap.com>
	<CA+gWKMAriVw8qowwRA0UU7urno6ANpiCBRy9zKUKj=BV++XKTg@mail.gmail.com>
	<CALt0+o9wO6q3L59bq8BOAAG4WC=DvRVstiNYTxLwhmRvMcjqkQ@mail.gmail.com>
	<9c158c39a7774384977fbd732903615c@sap.com>
Message-ID: <CAFm4XO3Xj41jbkHCkDKhQ44fLRh7ajvqYSOUvKS_V_Da+iktAg@mail.gmail.com>

Thanks for reminding the JIRA, I see there's quite some people interested in it.

I've added a comment explaining our plans, I guess many are not aware
of our bigger picture.

On 16 February 2018 at 10:57, Bregler, Jonathan
<jonathan.bregler at sap.com> wrote:
> Ok, thanks. For some reason I missed the Jira issue.
>
> - Jonathan
>
> From: Guillaume Smet [mailto:guillaume.smet at gmail.com]
> Sent: Friday, February 16, 2018 11:39 AM
> To: Vlad Mihalcea <mihalcea.vlad at gmail.com>
> Cc: Bregler, Jonathan <jonathan.bregler at sap.com>; hibernate-dev at lists.jboss.org
> Subject: Re: [hibernate-dev] Empty IN list support
>
> See this related issue: https://hibernate.atlassian.net/browse/HHH-8091
>
> On Fri, Feb 16, 2018 at 11:23 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com<mailto:mihalcea.vlad at gmail.com>> wrote:
> I see that we are only using it for testing so that we can skip the:
>
> testEmptyInListQuery
>
> query on certain Dialects.
>
> We could use this info when rendering the JPQL/HQL queries to throw an
> exception before executing the query.
> Nevertheless, an exception will be thrown anyway even if we don't do it.
>
> Vlad
>
> On Fri, Feb 16, 2018 at 11:21 AM, Bregler, Jonathan <
> jonathan.bregler at sap.com<mailto:jonathan.bregler at sap.com>> wrote:
>
>> Hi,
>>
>> HANA doesn't support empty IN lists, so executing an HQL query that gets
>> transformed into a SQL query with an empty IN list results in a SQL parser
>> error on the database side. I noticed that the Dialect class already
>> defines a method called "supportsEmptyInList()" which according to the
>> Javadoc returns "True if empty in lists are supported; false otherwise".
>> However, this method doesn't seem to be used anywhere in the Hibernate
>> code. Is there a reason for that?
>>
>> Thanks,
>> Jonathan
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org<mailto:hibernate-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org<mailto:hibernate-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Fri Feb 16 11:00:05 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 16 Feb 2018 16:00:05 +0000
Subject: [hibernate-dev] API incompatibilities between Hibernate ORM 5.3
 and 6.0
In-Reply-To: <CAFdSV9uX6_yk4Zc8cN4c=41y0AnjYCzzB8xE=n4CkvfW9H7yHw@mail.gmail.com>
References: <CAFDzhiTD0td4La8zSaddsKBvxDO_hsBjNQK3vHxNhT7U+TxN9g@mail.gmail.com>
	<CAFdSV9seErrZbtQMbmUM5Ob16ga_8k0=9PxB2ur9xRPtN2JLOw@mail.gmail.com>
	<CAFDzhiQHvLSr+DLPU_ZQKhA17FiHZfSXVkZCxy+amsgPjJsbWw@mail.gmail.com>
	<CAFdSV9uX6_yk4Zc8cN4c=41y0AnjYCzzB8xE=n4CkvfW9H7yHw@mail.gmail.com>
Message-ID: <CAFdSV9vd_Pdcg-fTSLA85r+CPsyxajAiTAEM0_rkhdw1zitexA@mail.gmail.com>

I talked with Andrea and we both think this is getting important to do.  So
Monday we will start the process of integrating master (5.3) on to 6.0.
Then you'll be able to have a better idea.

This figures to be a huge undertaking, so not sure when it will be done.

On Thu, Feb 15, 2018 at 10:05 PM Steve Ebersole <steve at hibernate.org> wrote:

> I'm not sure what else to tell you.  Sure some things have been removed.
>
> I'm not going to go through all of these right now.  If there are some in
> particular you are interested please bring those of specifically.
>
>
> On Thu, Feb 15, 2018 at 6:48 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> Hi Steve,
>>
>> The list I provided contains removals from your fork in wip/6.0 branch.
>>
>> IIUC, integrating changes from master will not restore what was deleted
>> or moved to a different package.  After integrating from master and
>> resolving conflicts, we'll have the same incompatibilities.
>>
>> Am I missing something? Is there some other branch I should be comparing?
>>
>> Regards,
>> Gail
>>
>> On Thu, Feb 15, 2018 at 9:13 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> We have not integrated changes from master into 6.0 for a long time.
>>> And we probably won't for some time yet either.  So comparisons between 5.2
>>> or 5.3 and 6.0 right now are pointless
>>>
>>> On Wed, Feb 14, 2018 at 12:09 PM Gail Badner <gbadner at redhat.com> wrote:
>>>
>>>> I sent this last night with a huge report file, and it seems that it
>>>> didn't
>>>> get out.
>>>>
>>>> I'm re-sending without the report file...
>>>>
>>>> I ran japi-compliance-checker to compare differences in APIs
>>>> between hibernate-core-5.3.0-SNAPSHOT.jar and hibernate-core-6.0.0-
>>>> SNAPSHOT.jar.
>>>>
>>>> I ran it last week, so it may not include updates made since that time.
>>>>
>>>> Differences in Envers shown in the report should be disregarded because
>>>> it
>>>> only reflects that hibernate-envers was merged into hibernate-core. A
>>>> separate comparison between hibernate-envers-5.3.0-SNAPSHOT.jar and
>>>> hibernate-core-6.0.0-SNAPSHOT.jar needs to be done to see Envers
>>>> changes.
>>>>
>>>> Chris will provide details about Envers differences in a separate email.
>>>>
>>>> The report is huge; it took me 3 to 4 hours to scan it. AFAICT, what
>>>> I've
>>>> documented are the only non-Envers API changes that could affect
>>>> applications. They all involve removed classes/methods.
>>>>
>>>> My intention here is just to get this information out, so we have some
>>>> solid examples to discuss.
>>>>
>>>> Regards,
>>>> Gail
>>>>
>>>> ------------------------------------------------------------
>>>> ----------------------------------------------------------------------
>>>>
>>>> Custom types: I am not familiar with how this will work in 6.0. Steve,
>>>> please fill in details about any incompatibilities.
>>>>
>>>> org.hibernate.Criteria and org.hibernate.criterion.DetachedCriteria:
>>>>
>>>> In 5.0/5.1/5.2:
>>>> * user guides say, "This appendix covers the legacy Hibernate
>>>> org.hibernate.Criteria API, which should be considered deprecated. New
>>>> development should focus on the JPA
>>>> javax.persistence.criteria.CriteriaQuery
>>>> API. Eventually, Hibernate-specific criteria features will be ported as
>>>> extensions to the JPA javax.persistence.criteria.CriteriaQuery. For
>>>> details
>>>> on the JPA APIs, see Criteria."
>>>>
>>>> In 5.2/5.3:
>>>> * Criteria and DetachedCriteria are not deprecated;
>>>> * all SharedSessionContract#createCriteria methods are deprecated;
>>>> * public static methods in DetachedCriteria are not deprecated;
>>>>
>>>> In 6.0:
>>>> * Criteria and DetachedCriteria are removed along with other classes in
>>>> org.hibernate.criterion.
>>>>
>>>> Incompatibilities migrating from 5.3 -> 6.0:
>>>> 1) Existing applications using legacy org.hibernate.Criteria will need
>>>> to
>>>> be updated to use javax.persistence.criteria.CriteriaQuery;
>>>> 2) If Hibernate's implementation of
>>>> javax.persistence.criteria.CriteriaQuery
>>>> does not include the Hibernate-specific extensions that were available
>>>> using org.hibernate.Criteria, applications may not have a
>>>> straightforward
>>>> way to change their applications to work.
>>>>
>>>> org.hibernate.Query
>>>>
>>>> In 5.1:
>>>> * SharedSessionContract#createQuery returns org.hibernate.Query
>>>> (org.hibernate.Session extends SharedSessionContract);
>>>>
>>>> In 5.2/5.3:
>>>> * org.hibernate.Query was deprecated; org.hibernate.query.Query should
>>>> be
>>>> used instead; org.hibernate.query.Query extends org.hibernate.Query;
>>>> * SharedSessionContract#createQuery moved to
>>>> org.hibernate.query.QueryProducer#createQuery,
>>>> returning  org.hibernate.query.Query (which extends
>>>> org.hibernate.Query);
>>>> (org.hibernate.Session extends QueryProducer);
>>>>
>>>> In 6.0:
>>>> * org.hibernate.Query was removed.
>>>>
>>>> Incompatibilities migrating from 5.3 -> 6.0:
>>>> 1) Existing applications that explicitly use org.hibernate.Query
>>>> (including
>>>> javax.persistence.Query.unwrap( org.hibernate.Query.class )) will have
>>>> to
>>>> be changed to use org.hibernate.query.Query.
>>>>
>>>> org.hibernate.SQLQuery:
>>>>
>>>> In 5.1:
>>>> * SharedSessionContract#createSQLQuery returns org.hibernate.SQLQuery
>>>> (org.hibernate.Session extends SharedSessionContract);
>>>>
>>>> In 5.2/5.3:
>>>> * SQLQuery was deprecated; NativeQuery should be used instead;
>>>> NativeQuery
>>>> extends SQLQuery;
>>>> * SharedSessionContract#createSQLQuery moved to
>>>> QueryProducer#createSQLQuery, returning  NativeQuery (which extends
>>>> SQLQuery); Session extends QueryProducer;
>>>> * QueryProducer#createSQLQuery is deprecated;
>>>> QueryProducer#createNativeQuery
>>>> should be used instead
>>>>
>>>> In 6.0:
>>>> * SQLQuery and org.hibernate.query.QueryProducer#createSQLQuery are
>>>> removed.
>>>>
>>>> Incompatibilities migrating from 5.3 -> 6.0:
>>>> 1) Existing applications using Session#createSQLQuery will need to be
>>>> updated to use Session#createNativeQuery.
>>>> 2) Existing applications that explicitly use org.hibernate.SQLQuery
>>>> (including javax.persistence.Query.unwrap( SQLQuery.class )) will have
>>>> to
>>>> be changed to use NativeQuery.
>>>>
>>>> org.hibernate.SynchronizeableQuery
>>>>
>>>> In 5.2/5.3:
>>>> * org.hibernate.SynchronizeableQuery is not deprecated;
>>>> * SQLQuery, NativeQuery and ProcedureCall extend org.hibernate.
>>>> SynchronizeableQuery
>>>>
>>>> In 6.0:
>>>> * org.hibernate.SynchronizeableQuery is moved to org.hibernate.query.
>>>> SynchronizeableQuery;
>>>> * NativeQuery and ProcedureCall extend
>>>> org.hibernate.query.SynchronizeableQuery;
>>>> (SQLQuery was removed as mentioned above)
>>>>
>>>> Incompatibilities migrating from 5.3 -> 6.0:
>>>> 1) In 6.0, existing applications that use
>>>> org.hibernate.SynchronizeableQuery
>>>> (including javax.persistence.Query.unwrap(
>>>> org.hibernate.SynchronizeableQuery.class
>>>> )) will need to be updated to use
>>>> org.hibernate.query.SynchronizeableQuery
>>>>
>>>> org.hibernate.Session#createFilter
>>>>
>>>> In 5.1:
>>>> * Session#createFilter returns org.hibernate.Query;
>>>>
>>>> In 5.2/5.3:
>>>> * Session#createFilter returns org.hibernate.query.Query (which extends
>>>> org.hibernate.Query);
>>>> * org.hibernate.Session#createFilter is not deprecated;
>>>>
>>>> In 6.0:
>>>> * org.hibernate.Session#createFilter is removed.
>>>>
>>>> Incompatibilities migrating from 5.3 -> 6.0:
>>>> 1) Existing applications that call Session#createFilter will need to be
>>>> updated (to what???); does collection filter functionality exist in
>>>> 6.0???
>>>>
>>>> org.hibernate.Session.#getTypeHelper
>>>>
>>>> In 5.1/5.2/5.3:
>>>> * org.hibernate.Session.#getTypeHelper returns org.hibernate.TypeHelper;
>>>> * Session#getTypeHelper is not deprecated;
>>>>
>>>> In 6.0: org.hibernate.Session.#getTypeHelper is removed;
>>>>
>>>> Incompatibilities migrating from 5.3 -> 6.0:
>>>> 1) In 6.0, existing applications that call Session.#getTypeHelper will
>>>> need
>>>> to be updated (to what???).
>>>>
>>>> org.hibernate.metadata.ClassMetadata, org.hibernate.metadata.
>>>> CollectionMetadata
>>>>
>>>> In 5.2/5.3:
>>>> * SessionFactory#getClassMetadata(Class), #getClassMetadata(String),
>>>> #getAllClassMetadata, #getCollectionMetadata, #getAllCollectionMetadata
>>>> were deprecated; descriptors from
>>>> javax.persistence.EntityManagerFactory#getMetamodel
>>>> should be used instead; org.hibernate.SessionFactory extends
>>>> javax.persistence.EntityManagerFactory;
>>>>
>>>> In 6.0:
>>>> * ClassMetadata and CollectionMetadata removed.
>>>>
>>>> Incompatibilities migrating from 5.3 -> 6.0:
>>>> 1) In 6.0, existing applications that call
>>>> org.hibernate.SessionFactory#getClassMetadata(Class),
>>>> #getClassMetadata(String), #getAllClassMetadata, #getCollectionMetadata,
>>>> #getAllCollectionMetadata will need to be updated to use descripters
>>>> from
>>>> javax.persistence.EntityManagerFactory#getMetamodel.
>>>>
>>>> org.hibernate.stat.NaturalIdCacheStatistics
>>>>
>>>> In 5.2/5.3:
>>>> * Statistics#getNaturalIdCacheStatistics returns
>>>> NaturalIdCacheStatistics;
>>>>
>>>> In 6.0:
>>>> * NaturalIdCacheStatistics is renamed to NaturalIdQueryStatistics;
>>>> * NaturalIdQueryStatistics excludes #getHitCount, #getMissCount,
>>>> #getPutCount, #getElementCountInMemory, #getElementCountOnDisk,
>>>> #getSizeInMemory, and #getEntries which were originally in
>>>> NaturalIdCacheStatistics; instead org.hibernate.stat.
>>>> SecondLevelCacheStatistics#getHitCount, #getMissCount, #getPutCount,
>>>>
>>>> #getElementCountInMemory, #getElementCountOnDisk, #getSizeInMemory
>>>> should
>>>> be used.
>>>> (SecondLevelCacheStatistics#getEntries was removed due to HHH-11356, so
>>>> there is no substitute for org.hibernate.stat.NaturalIdCacheStatistics#
>>>> getEntries;
>>>> * Statistics#getNaturalIdCacheStatistics is renamed to
>>>> #getNaturalIdStatistics.
>>>>
>>>> Incompatibilities migrating from 5.3 -> 6.0:
>>>> 1) Existing applications that explicitly use NaturalIdCacheStatistics
>>>> will
>>>> need to be updated to use NaturalIdCacheStatistics.
>>>> 2) Existing applications that call
>>>> Statistics#getNaturalIdCacheStatistics
>>>> will need to be updated to use Statistics#getNaturalIdCacheStatistics.
>>>> 3) Existing applications that call org.hibernate.stat.
>>>> NaturalIdCacheStatistics#getHitCount, #getMissCount, #getPutCount,
>>>> #getElementCountInMemory, #getElementCountOnDisk, #getSizeInMemory, or
>>>> #getEntries will need to be updated to obtain the
>>>> SecondLevelCacheStatistics object for the particular natural ID using
>>>> Statistics#getSecondLevelCacheStatistics( naturalIdRegionName??? ) (How
>>>> is
>>>> naturalIdRegionName determined???). The application will need to be
>>>> changed
>>>> to used SecondLevelCacheStatistics#getHitCount, #getMissCount,
>>>> #getPutCount, #getElementCountInMemory, #getElementCountOnDisk, and
>>>> #getSizeInMemory instead.
>>>> 4) Existing applications that call NaturalIdCacheStatistics#getEntries
>>>> will
>>>> need to be updated to no longer call that method.
>>>>
>>>> org.hibernate.stat.SecondLevelCacheStatistics
>>>>
>>>> In 5.3:
>>>> * SecondLevelCacheStatistics#getEntries is not deprecated;
>>>>
>>>> In 6.0:
>>>> * SecondLevelCacheStatistics#getEntries is removed due to HHH-11356.
>>>> * SecondLevelCacheStatistics no longer implements Serializable;
>>>>
>>>> Incompatibilities migrating from 5.3 -> 6.0:
>>>> 1) Existing applications that call SecondLevelCacheStatistics#getEntries
>>>> will need to be updated to no longer call that method.
>>>> 2) Existing applications that implement SecondLevelCacheStatistics (SPI)
>>>> will need to explicitly implement Serializable.
>>>>
>>>> QueryStatistics#getCacheHitCount, #getCacheMissCount, and
>>>> #getCachePutCount
>>>>
>>>> In 5.3:
>>>> * QueryStatistics#getCacheHitCount, #getCacheMissCount, and
>>>> #getCachePutCount are not deprecated;
>>>>
>>>> In 6.0:
>>>> * QueryStatistics#getCacheHitCount, #getCacheMissCount, and
>>>> #getCachePutCount were removed;
>>>> * ConcurrentQueryStatisticsImpl implements QueryStatistics and still
>>>> contains public methods, #getCacheHitCount, #getCacheMissCount, and
>>>> #getCachePutCount (why???).
>>>>
>>>> Incompatibilities migrating from 5.3 -> 6.0:
>>>> 1) Existing applications that use
>>>> org.hibernate.stat.QueryStatistics#getCacheHitCount,
>>>> #getCacheMissCount, and #getCachePutCount will need to be changed (to
>>>> use
>>>> SecondLevelCacheStatistics???).
>>>>
>>>> org.hibernate.jpa.HibernateEntityManager
>>>>
>>>> In 5.2/5.3:
>>>> * HibernateEntityManager is deprecated; Session (or SessionImplementor
>>>> (SPI)) should be used instead;
>>>> * Session extends HibernateEntityManager;
>>>>
>>>> In 6.0:
>>>> * HibernateEntityManager is removed.
>>>>
>>>> Incompatibilities migrating from 5.3 -> 6.0:
>>>> 1) In 6.0, existing applications that  explicitly use
>>>> org.hibernate.jpa.HibernateEntityManager
>>>> (including javax.persistence.EntityManager.unwrap(
>>>> HibernateEntityManager.class )) will have to be changed to use Session
>>>> (or
>>>> SessionImplementor (SPI)).
>>>>
>>>> org.hibernate.jpa.HibernateEntityManagerFactory
>>>>
>>>> In 5.2/5.3:
>>>> * HibernateEntityManagerFactory is deprecated; SessionFactory (or
>>>> SessionFactoryImplementor (SPI)) should be used instead;
>>>> * SessionFactory extends HibernateEntityManagerFactory;
>>>>
>>>> In 6.0:
>>>> * HibernateEntityManagerFactory is removed.
>>>>
>>>> Incompatibilities migrating from 5.3 -> 6.0:
>>>> 1) In 6.0, existing applications that explicitly use
>>>> org.hibernate.jpa.HibernateEntityManagerFactory
>>>> (including javax.persistence.EntityManagerFactory.unwrap(
>>>> HibernateEntityManagerFactory.class )) will have to be changed to use
>>>> Session (or SessionImplementor (SPI)).
>>>>
>>>> org.hibernate.Hibernate#unproxy
>>>>
>>>> In 5.2/5.3:
>>>> * Hibernate#unproxy was introduced by HHH-10831 in 5.2.10
>>>>
>>>> In 6.0:
>>>> * the fix for HHH-10831 has not been incorporated into 6.0, so it is not
>>>> present. Will it be??
>>>>
>>>> Incompatibilities migrating from 5.3 -> 6.0:
>>>> 1) Existing applications that use Hibernate#unproxy will have to be be
>>>> changed to explicitly initialize and unproxy.
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>

From coladict at gmail.com  Fri Feb 16 16:11:34 2018
From: coladict at gmail.com (Jordan Gigov)
Date: Fri, 16 Feb 2018 23:11:34 +0200
Subject: [hibernate-dev] Removing dom4j?
Message-ID: <CA+nBocC9qzvM2RQUbDVu9QrApjx=88gFEcB421M2rF_OASeA8w@mail.gmail.com>

So, the library has not seen a bugfix in over 10 years, and it lists the
wrong version for it's xml-apis dependency.
There are some notes in comments about eventually removing it, and I
thought I'd give it a try on the 5.2 branch.
I had to remove two shiv-libraries you had added to work around problems
you probably encountered prior to JDK6.

I've narrowed it down to 11 failing tests (5 distinct exceptions) when
using the default XML APIs provided with JDK8.

Is there any interest in this?

From sanne at hibernate.org  Fri Feb 16 16:33:53 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 16 Feb 2018 21:33:53 +0000
Subject: [hibernate-dev] Removing dom4j?
In-Reply-To: <CA+nBocC9qzvM2RQUbDVu9QrApjx=88gFEcB421M2rF_OASeA8w@mail.gmail.com>
References: <CA+nBocC9qzvM2RQUbDVu9QrApjx=88gFEcB421M2rF_OASeA8w@mail.gmail.com>
Message-ID: <CAFm4XO18ixJzZ87P4PNtzKb+2oi-qAmj4+zBCaFLD3oE_tYc1A@mail.gmail.com>

Hi Jordan,

I think it would be great to remove it. Especially recently we've
started exploring what it would take to convert all jars into proper
Jigsaw modules, and a requirement is that all dependencies need to be
converted as well; this is obviously more problematic for such old
libraries so it would be best to remove it or find a good replacement.

I'd suggest to work on the master branch though, we wouldn't want to
apply this on the 5.2 branch which is now in maintenance mode.

What do you mean with "shiv-libraries" ?

Thanks,
Sanne


On 16 February 2018 at 21:11, Jordan Gigov <coladict at gmail.com> wrote:
> So, the library has not seen a bugfix in over 10 years, and it lists the
> wrong version for it's xml-apis dependency.
> There are some notes in comments about eventually removing it, and I
> thought I'd give it a try on the 5.2 branch.
> I had to remove two shiv-libraries you had added to work around problems
> you probably encountered prior to JDK6.
>
> I've narrowed it down to 11 failing tests (5 distinct exceptions) when
> using the default XML APIs provided with JDK8.
>
> Is there any interest in this?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From coladict at gmail.com  Fri Feb 16 17:29:06 2018
From: coladict at gmail.com (Jordan Gigov)
Date: Sat, 17 Feb 2018 00:29:06 +0200
Subject: [hibernate-dev] Removing dom4j?
In-Reply-To: <CAFm4XO18ixJzZ87P4PNtzKb+2oi-qAmj4+zBCaFLD3oE_tYc1A@mail.gmail.com>
References: <CA+nBocC9qzvM2RQUbDVu9QrApjx=88gFEcB421M2rF_OASeA8w@mail.gmail.com>
	<CAFm4XO18ixJzZ87P4PNtzKb+2oi-qAmj4+zBCaFLD3oE_tYc1A@mail.gmail.com>
Message-ID: <CA+nBocDQpYSa9sO2VAsF8Sm=o4m0oiN9ETzzQdHtuxuFtfjdSA@mail.gmail.com>

The woodstox dependency is incompatible with the rest of the XML API due to
a bug in the JDK that is otherwise hidden in all cases in the default
implementation.

Specifically it's implementation of EndElement brings that bug to the
forefront, when
com.sun.org.apache.xalan.internal.xsltc.trax.StAXEvent2SAX.handleElementEnd
tries to typecast a Namespace to String.

In the default implementation, that Namespace iterator is always empty, so
it never reaches that line.

Though that does make me wonder why the Document after being read is
scanned again as a DOMSource and then converted back to a Document object.
Might be a better way to pass it on altogether. Makes me wish I had noticed
the deprecation note on org.hibernate.boot.MetadataSources.addDocument(
Document)

On 16 February 2018 at 23:33, Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Jordan,
>
> I think it would be great to remove it. Especially recently we've
> started exploring what it would take to convert all jars into proper
> Jigsaw modules, and a requirement is that all dependencies need to be
> converted as well; this is obviously more problematic for such old
> libraries so it would be best to remove it or find a good replacement.
>
> I'd suggest to work on the master branch though, we wouldn't want to
> apply this on the 5.2 branch which is now in maintenance mode.
>
> What do you mean with "shiv-libraries" ?
>
> Thanks,
> Sanne
>
>
> On 16 February 2018 at 21:11, Jordan Gigov <coladict at gmail.com> wrote:
> > So, the library has not seen a bugfix in over 10 years, and it lists the
> > wrong version for it's xml-apis dependency.
> > There are some notes in comments about eventually removing it, and I
> > thought I'd give it a try on the 5.2 branch.
> > I had to remove two shiv-libraries you had added to work around problems
> > you probably encountered prior to JDK6.
> >
> > I've narrowed it down to 11 failing tests (5 distinct exceptions) when
> > using the default XML APIs provided with JDK8.
> >
> > Is there any interest in this?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Sat Feb 17 10:14:46 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 17 Feb 2018 15:14:46 +0000
Subject: [hibernate-dev] Removing dom4j?
In-Reply-To: <CA+nBocDQpYSa9sO2VAsF8Sm=o4m0oiN9ETzzQdHtuxuFtfjdSA@mail.gmail.com>
References: <CA+nBocC9qzvM2RQUbDVu9QrApjx=88gFEcB421M2rF_OASeA8w@mail.gmail.com>
	<CAFm4XO18ixJzZ87P4PNtzKb+2oi-qAmj4+zBCaFLD3oE_tYc1A@mail.gmail.com>
	<CA+nBocDQpYSa9sO2VAsF8Sm=o4m0oiN9ETzzQdHtuxuFtfjdSA@mail.gmail.com>
Message-ID: <CAFdSV9tvfhOrX8FGeRJG3RErW_5Y60quLMngsFOgCAWGKZgQPQ@mail.gmail.com>

Would we be interested?  Heck yeah.  We have just not put in the effort
because it is used for such a small subset of features *and* we plan to not
use DOM/SAX directly moving forward (we are transitioning to JAXB).

All that said though, I am surprised you ran into so few problems.  Envers
e.g. makes extensive use of DOM4J.

On Fri, Feb 16, 2018 at 4:29 PM Jordan Gigov <coladict at gmail.com> wrote:

> The woodstox dependency is incompatible with the rest of the XML API due to
> a bug in the JDK that is otherwise hidden in all cases in the default
> implementation.
>
> Specifically it's implementation of EndElement brings that bug to the
> forefront, when
> com.sun.org.apache.xalan.internal.xsltc.trax.StAXEvent2SAX.handleElementEnd
> tries to typecast a Namespace to String.
>
> In the default implementation, that Namespace iterator is always empty, so
> it never reaches that line.
>
> Though that does make me wonder why the Document after being read is
> scanned again as a DOMSource and then converted back to a Document object.
> Might be a better way to pass it on altogether. Makes me wish I had noticed
> the deprecation note on org.hibernate.boot.MetadataSources.addDocument(
> Document)
>
> On 16 February 2018 at 23:33, Sanne Grinovero <sanne at hibernate.org> wrote:
>
> > Hi Jordan,
> >
> > I think it would be great to remove it. Especially recently we've
> > started exploring what it would take to convert all jars into proper
> > Jigsaw modules, and a requirement is that all dependencies need to be
> > converted as well; this is obviously more problematic for such old
> > libraries so it would be best to remove it or find a good replacement.
> >
> > I'd suggest to work on the master branch though, we wouldn't want to
> > apply this on the 5.2 branch which is now in maintenance mode.
> >
> > What do you mean with "shiv-libraries" ?
> >
> > Thanks,
> > Sanne
> >
> >
> > On 16 February 2018 at 21:11, Jordan Gigov <coladict at gmail.com> wrote:
> > > So, the library has not seen a bugfix in over 10 years, and it lists
> the
> > > wrong version for it's xml-apis dependency.
> > > There are some notes in comments about eventually removing it, and I
> > > thought I'd give it a try on the 5.2 branch.
> > > I had to remove two shiv-libraries you had added to work around
> problems
> > > you probably encountered prior to JDK6.
> > >
> > > I've narrowed it down to 11 failing tests (5 distinct exceptions) when
> > > using the default XML APIs provided with JDK8.
> > >
> > > Is there any interest in this?
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From coladict at gmail.com  Sun Feb 18 05:52:13 2018
From: coladict at gmail.com (Jordan Gigov)
Date: Sun, 18 Feb 2018 12:52:13 +0200
Subject: [hibernate-dev] Removing dom4j?
In-Reply-To: <CAFdSV9tvfhOrX8FGeRJG3RErW_5Y60quLMngsFOgCAWGKZgQPQ@mail.gmail.com>
References: <CA+nBocC9qzvM2RQUbDVu9QrApjx=88gFEcB421M2rF_OASeA8w@mail.gmail.com>
	<CAFm4XO18ixJzZ87P4PNtzKb+2oi-qAmj4+zBCaFLD3oE_tYc1A@mail.gmail.com>
	<CA+nBocDQpYSa9sO2VAsF8Sm=o4m0oiN9ETzzQdHtuxuFtfjdSA@mail.gmail.com>
	<CAFdSV9tvfhOrX8FGeRJG3RErW_5Y60quLMngsFOgCAWGKZgQPQ@mail.gmail.com>
Message-ID: <CA+nBocD9Qh6JNgy_UqiUD-XDf_Nh+QcjmK0p1R9eGHC+qb9bLg@mail.gmail.com>

I think transitioning to automatic bindings via JAXB will result in error
messages on wrong configurations becoming far too vague to be useful to the
users.
That's just an opinion, though.

I tried building from a clean master branch at home on Windows 10 before
moving the changes, but the multiline tests fail. Time to re-open HHH-8397.

On 17 February 2018 at 17:14, Steve Ebersole <steve at hibernate.org> wrote:

> Would we be interested?  Heck yeah.  We have just not put in the effort
> because it is used for such a small subset of features *and* we plan to not
> use DOM/SAX directly moving forward (we are transitioning to JAXB).
>
> All that said though, I am surprised you ran into so few problems.  Envers
> e.g. makes extensive use of DOM4J.
>
> On Fri, Feb 16, 2018 at 4:29 PM Jordan Gigov <coladict at gmail.com> wrote:
>
>> The woodstox dependency is incompatible with the rest of the XML API due
>> to
>> a bug in the JDK that is otherwise hidden in all cases in the default
>> implementation.
>>
>> Specifically it's implementation of EndElement brings that bug to the
>> forefront, when
>> com.sun.org.apache.xalan.internal.xsltc.trax.
>> StAXEvent2SAX.handleElementEnd
>> tries to typecast a Namespace to String.
>>
>> In the default implementation, that Namespace iterator is always empty, so
>> it never reaches that line.
>>
>> Though that does make me wonder why the Document after being read is
>> scanned again as a DOMSource and then converted back to a Document object.
>> Might be a better way to pass it on altogether. Makes me wish I had
>> noticed
>> the deprecation note on org.hibernate.boot.MetadataSources.addDocument(
>> Document)
>>
>> On 16 February 2018 at 23:33, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>> > Hi Jordan,
>> >
>> > I think it would be great to remove it. Especially recently we've
>> > started exploring what it would take to convert all jars into proper
>> > Jigsaw modules, and a requirement is that all dependencies need to be
>> > converted as well; this is obviously more problematic for such old
>> > libraries so it would be best to remove it or find a good replacement.
>> >
>> > I'd suggest to work on the master branch though, we wouldn't want to
>> > apply this on the 5.2 branch which is now in maintenance mode.
>> >
>> > What do you mean with "shiv-libraries" ?
>> >
>> > Thanks,
>> > Sanne
>> >
>> >
>> > On 16 February 2018 at 21:11, Jordan Gigov <coladict at gmail.com> wrote:
>> > > So, the library has not seen a bugfix in over 10 years, and it lists
>> the
>> > > wrong version for it's xml-apis dependency.
>> > > There are some notes in comments about eventually removing it, and I
>> > > thought I'd give it a try on the 5.2 branch.
>> > > I had to remove two shiv-libraries you had added to work around
>> problems
>> > > you probably encountered prior to JDK6.
>> > >
>> > > I've narrowed it down to 11 failing tests (5 distinct exceptions) when
>> > > using the default XML APIs provided with JDK8.
>> > >
>> > > Is there any interest in this?
>> > > _______________________________________________
>> > > hibernate-dev mailing list
>> > > hibernate-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Sun Feb 18 11:38:26 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 18 Feb 2018 16:38:26 +0000
Subject: [hibernate-dev] Removing dom4j?
In-Reply-To: <CA+nBocD9Qh6JNgy_UqiUD-XDf_Nh+QcjmK0p1R9eGHC+qb9bLg@mail.gmail.com>
References: <CA+nBocC9qzvM2RQUbDVu9QrApjx=88gFEcB421M2rF_OASeA8w@mail.gmail.com>
	<CAFm4XO18ixJzZ87P4PNtzKb+2oi-qAmj4+zBCaFLD3oE_tYc1A@mail.gmail.com>
	<CA+nBocDQpYSa9sO2VAsF8Sm=o4m0oiN9ETzzQdHtuxuFtfjdSA@mail.gmail.com>
	<CAFdSV9tvfhOrX8FGeRJG3RErW_5Y60quLMngsFOgCAWGKZgQPQ@mail.gmail.com>
	<CA+nBocD9Qh6JNgy_UqiUD-XDf_Nh+QcjmK0p1R9eGHC+qb9bLg@mail.gmail.com>
Message-ID: <CAFdSV9sSMh4Hu_9dZYmGMgQj_Ejbu_Trb3jPcf8Trywe4BmC0A@mail.gmail.com>

On Sun, Feb 18, 2018 at 4:52 AM Jordan Gigov <coladict at gmail.com> wrote:

> I think transitioning to automatic bindings via JAXB will result in error
> messages on wrong configurations becoming far too vague to be useful to the
> users.
>

I'm not understanding... we've used jaxb since 4.0

I am just talking about envers and how it integrates with hibernate-core.
At the moment it directly uses dom4j - we'd like to eventualy have it use
the jaxb model instead

From davide at hibernate.org  Mon Feb 19 06:36:49 2018
From: davide at hibernate.org (Davide D'Alto)
Date: Mon, 19 Feb 2018 11:36:49 +0000
Subject: [hibernate-dev] Favicon on CI
Message-ID: <CANoTJYOwCBLtxX=GTi2+UsjKHAX+1V-=S5iE_Ae8a+QY9u45xQ@mail.gmail.com>

hi,
not critical, but I've upgraded the plugin for the Theme on Jenkins
and it is now possible to add a favicon from Jenkins settings page.

Just thought of mentioning it here in case we want to change the default one.

Cheers,
Davide

From chris at hibernate.org  Mon Feb 19 10:03:06 2018
From: chris at hibernate.org (Chris Cranford)
Date: Mon, 19 Feb 2018 10:03:06 -0500
Subject: [hibernate-dev] Removing dom4j?
In-Reply-To: <CAFdSV9sSMh4Hu_9dZYmGMgQj_Ejbu_Trb3jPcf8Trywe4BmC0A@mail.gmail.com>
References: <CA+nBocC9qzvM2RQUbDVu9QrApjx=88gFEcB421M2rF_OASeA8w@mail.gmail.com>
	<CAFm4XO18ixJzZ87P4PNtzKb+2oi-qAmj4+zBCaFLD3oE_tYc1A@mail.gmail.com>
	<CA+nBocDQpYSa9sO2VAsF8Sm=o4m0oiN9ETzzQdHtuxuFtfjdSA@mail.gmail.com>
	<CAFdSV9tvfhOrX8FGeRJG3RErW_5Y60quLMngsFOgCAWGKZgQPQ@mail.gmail.com>
	<CA+nBocD9Qh6JNgy_UqiUD-XDf_Nh+QcjmK0p1R9eGHC+qb9bLg@mail.gmail.com>
	<CAFdSV9sSMh4Hu_9dZYmGMgQj_Ejbu_Trb3jPcf8Trywe4BmC0A@mail.gmail.com>
Message-ID: <4cb261df-4a6f-5893-9fdd-aff2d37fdf9b@hibernate.org>

See below

On 02/18/2018 11:38 AM, Steve Ebersole wrote:
> On Sun, Feb 18, 2018 at 4:52 AM Jordan Gigov <coladict at gmail.com> wrote:
>
>> I think transitioning to automatic bindings via JAXB will result in error
>> messages on wrong configurations becoming far too vague to be useful to the
>> users.
>>
> I'm not understanding... we've used jaxb since 4.0
>
> I am just talking about envers and how it integrates with hibernate-core.
> At the moment it directly uses dom4j - we'd like to eventualy have it use
> the jaxb model instead

There is a JIRA [1] that specifically targets this work from an Envers
perspective.?

I have a working implementation based on Hibernate 5.x but this is
planned to be integrated in Hibernate 6.? I'd expect to see this get
integrated once we get a bit more development finalized around Hibernate
Core in 6.

[1]: https://hibernate.atlassian.net/browse/HHH-11483

Thanks,
Chris

From coladict at gmail.com  Tue Feb 20 10:52:37 2018
From: coladict at gmail.com (Jordan Gigov)
Date: Tue, 20 Feb 2018 17:52:37 +0200
Subject: [hibernate-dev] Removing dom4j?
In-Reply-To: <4cb261df-4a6f-5893-9fdd-aff2d37fdf9b@hibernate.org>
References: <CA+nBocC9qzvM2RQUbDVu9QrApjx=88gFEcB421M2rF_OASeA8w@mail.gmail.com>
	<CAFm4XO18ixJzZ87P4PNtzKb+2oi-qAmj4+zBCaFLD3oE_tYc1A@mail.gmail.com>
	<CA+nBocDQpYSa9sO2VAsF8Sm=o4m0oiN9ETzzQdHtuxuFtfjdSA@mail.gmail.com>
	<CAFdSV9tvfhOrX8FGeRJG3RErW_5Y60quLMngsFOgCAWGKZgQPQ@mail.gmail.com>
	<CA+nBocD9Qh6JNgy_UqiUD-XDf_Nh+QcjmK0p1R9eGHC+qb9bLg@mail.gmail.com>
	<CAFdSV9sSMh4Hu_9dZYmGMgQj_Ejbu_Trb3jPcf8Trywe4BmC0A@mail.gmail.com>
	<4cb261df-4a6f-5893-9fdd-aff2d37fdf9b@hibernate.org>
Message-ID: <CA+nBocCUbciWkkH4X+nMGu6Zp=pNBx6mtcDzoqLT9P50eE-hkA@mail.gmail.com>

Well, it took longer than expected as the source of the failures became
more obscure, but here it is, done on the master (5.3) branch.

https://github.com/coladict/hibernate-orm/tree/dom4j-removal
It's in the dom4j-removal branch.

The tests for entity-mode dom4j have been removed, but it might be a better
idea to write new ones that expect an error.
Also the hibernate-mapping-4.0.xsd schema hasn't been valid since dom4j
entity-mode was removed in 2011 (4a4f636caf9ecc62fe0d230f422ad3eab2517db0)
but I haven't touched it.

You could wait for 6.0, but there is time to review this for 5.3.

I have only passed a `clean build` using JDK8 and the default H2 database.
Maybe other databases could expose errors, but it's highly unlikely.
JDK9 is a bit more likely to expose an incompatibility.

On 19 February 2018 at 17:03, Chris Cranford <chris at hibernate.org> wrote:

> See below
>
> On 02/18/2018 11:38 AM, Steve Ebersole wrote:
> > On Sun, Feb 18, 2018 at 4:52 AM Jordan Gigov <coladict at gmail.com> wrote:
> >
> >> I think transitioning to automatic bindings via JAXB will result in
> error
> >> messages on wrong configurations becoming far too vague to be useful to
> the
> >> users.
> >>
> > I'm not understanding... we've used jaxb since 4.0
> >
> > I am just talking about envers and how it integrates with hibernate-core.
> > At the moment it directly uses dom4j - we'd like to eventualy have it use
> > the jaxb model instead
>
> There is a JIRA [1] that specifically targets this work from an Envers
> perspective.
>
> I have a working implementation based on Hibernate 5.x but this is
> planned to be integrated in Hibernate 6.  I'd expect to see this get
> integrated once we get a bit more development finalized around Hibernate
> Core in 6.
>
> [1]: https://hibernate.atlassian.net/browse/HHH-11483
>
> Thanks,
> Chris
>

From fercoli at redhat.com  Tue Feb 20 12:46:36 2018
From: fercoli at redhat.com (Fabio Massimo Ercoli)
Date: Tue, 20 Feb 2018 18:46:36 +0100
Subject: [hibernate-dev] Hibernate OGM 5.3.0.Final released
Message-ID: <CAFiQRE94DJFkFDfJYKB7agu1L-UBw5nzvjB-x+29sk5_nwLqwQ@mail.gmail.com>

Hibernate OGM 5.3.0.Final is ready!

We worked to make it compatible with Hibernate ORM 5.2.13.Final.

All the details in the blog post:
http://in.relation.to/2018/02/20/hibernate-ogm-5-3-Final-released/

Thanks, ?Fabio

From chris at hibernate.org  Wed Feb 21 10:52:57 2018
From: chris at hibernate.org (Chris Cranford)
Date: Wed, 21 Feb 2018 10:52:57 -0500
Subject: [hibernate-dev] Removing dom4j?
In-Reply-To: <CA+nBocCUbciWkkH4X+nMGu6Zp=pNBx6mtcDzoqLT9P50eE-hkA@mail.gmail.com>
References: <CA+nBocC9qzvM2RQUbDVu9QrApjx=88gFEcB421M2rF_OASeA8w@mail.gmail.com>
	<CAFm4XO18ixJzZ87P4PNtzKb+2oi-qAmj4+zBCaFLD3oE_tYc1A@mail.gmail.com>
	<CA+nBocDQpYSa9sO2VAsF8Sm=o4m0oiN9ETzzQdHtuxuFtfjdSA@mail.gmail.com>
	<CAFdSV9tvfhOrX8FGeRJG3RErW_5Y60quLMngsFOgCAWGKZgQPQ@mail.gmail.com>
	<CA+nBocD9Qh6JNgy_UqiUD-XDf_Nh+QcjmK0p1R9eGHC+qb9bLg@mail.gmail.com>
	<CAFdSV9sSMh4Hu_9dZYmGMgQj_Ejbu_Trb3jPcf8Trywe4BmC0A@mail.gmail.com>
	<4cb261df-4a6f-5893-9fdd-aff2d37fdf9b@hibernate.org>
	<CA+nBocCUbciWkkH4X+nMGu6Zp=pNBx6mtcDzoqLT9P50eE-hkA@mail.gmail.com>
Message-ID: <94be3747-051b-53ce-b4dc-6aa84e2af6e1@hibernate.org>

See inline

On 02/20/2018 10:52 AM, Jordan Gigov wrote:
> Well, it took longer than expected as the source of the failures
> became more obscure, but here it is, done on the master (5.3) branch.
>
> https://github.com/coladict/hibernate-orm/tree/dom4j-removal
> It's in the dom4j-removal branch.
>
> The tests for entity-mode dom4j have been removed, but it might be a
> better idea to write new ones that expect an error.
> Also the hibernate-mapping-4.0.xsd schema hasn't been valid since
> dom4j entity-mode was removed in 2011
> (4a4f636caf9ecc62fe0d230f422ad3eab2517db0) but I haven't touched it.
>
> You could wait for 6.0, but there is time to review this for 5.3.
>
The biggest difference between what you did and my own for Envers is
that I decided to use the JAXB binding classes directly rather than
replace dom4j with another XML abstraction.? Using JAXB binding classes
directly gives several noticeable benefits:

?* Better maintainability - cleaner and easier to read code
?* Better performance - less in-memory string manipulation and cloning
?* Most important - compile-time schema compliance.

The replacement of dom4j with the w3c equivalents is likely fine for
5.3; however, the long-term goal is to do away with the XML manipulation
all together in Envers.

> I have only passed a `clean build` using JDK8 and the default H2
> database. Maybe other databases could expose errors, but it's highly
> unlikely.
> JDK9 is a bit more likely to expose an incompatibility.
>
> On 19 February 2018 at 17:03, Chris Cranford <chris at hibernate.org
> <mailto:chris at hibernate.org>> wrote:
>
>     See below
>
>     On 02/18/2018 11:38 AM, Steve Ebersole wrote:
>     > On Sun, Feb 18, 2018 at 4:52 AM Jordan Gigov <coladict at gmail.com
>     <mailto:coladict at gmail.com>> wrote:
>     >
>     >> I think transitioning to automatic bindings via JAXB will
>     result in error
>     >> messages on wrong configurations becoming far too vague to be
>     useful to the
>     >> users.
>     >>
>     > I'm not understanding... we've used jaxb since 4.0
>     >
>     > I am just talking about envers and how it integrates with
>     hibernate-core.
>     > At the moment it directly uses dom4j - we'd like to eventualy
>     have it use
>     > the jaxb model instead
>
>     There is a JIRA [1] that specifically targets this work from an Envers
>     perspective.?
>
>     I have a working implementation based on Hibernate 5.x but this is
>     planned to be integrated in Hibernate 6.? I'd expect to see this get
>     integrated once we get a bit more development finalized around
>     Hibernate
>     Core in 6.
>
>     [1]: https://hibernate.atlassian.net/browse/HHH-11483
>     <https://hibernate.atlassian.net/browse/HHH-11483>
>
>     Thanks,
>     Chris
>
>


From chris at hibernate.org  Wed Feb 21 12:38:17 2018
From: chris at hibernate.org (Chris Cranford)
Date: Wed, 21 Feb 2018 12:38:17 -0500
Subject: [hibernate-dev] Removing dom4j?
In-Reply-To: <94be3747-051b-53ce-b4dc-6aa84e2af6e1@hibernate.org>
References: <CA+nBocC9qzvM2RQUbDVu9QrApjx=88gFEcB421M2rF_OASeA8w@mail.gmail.com>
	<CAFm4XO18ixJzZ87P4PNtzKb+2oi-qAmj4+zBCaFLD3oE_tYc1A@mail.gmail.com>
	<CA+nBocDQpYSa9sO2VAsF8Sm=o4m0oiN9ETzzQdHtuxuFtfjdSA@mail.gmail.com>
	<CAFdSV9tvfhOrX8FGeRJG3RErW_5Y60quLMngsFOgCAWGKZgQPQ@mail.gmail.com>
	<CA+nBocD9Qh6JNgy_UqiUD-XDf_Nh+QcjmK0p1R9eGHC+qb9bLg@mail.gmail.com>
	<CAFdSV9sSMh4Hu_9dZYmGMgQj_Ejbu_Trb3jPcf8Trywe4BmC0A@mail.gmail.com>
	<4cb261df-4a6f-5893-9fdd-aff2d37fdf9b@hibernate.org>
	<CA+nBocCUbciWkkH4X+nMGu6Zp=pNBx6mtcDzoqLT9P50eE-hkA@mail.gmail.com>
	<94be3747-051b-53ce-b4dc-6aa84e2af6e1@hibernate.org>
Message-ID: <2ba759d3-3ac6-a45a-5218-35f3281b6a45@hibernate.org>

Another alternative (at least for Envers) might be to incorporate the
JAXB work I did into 5.3 rather than wait for 6.0.

Steve/Andrea, either of you have a preference one way or another?

On 02/21/2018 10:52 AM, Chris Cranford wrote:
> See inline
>
> On 02/20/2018 10:52 AM, Jordan Gigov wrote:
>> Well, it took longer than expected as the source of the failures
>> became more obscure, but here it is, done on the master (5.3) branch.
>>
>> https://github.com/coladict/hibernate-orm/tree/dom4j-removal
>> It's in the dom4j-removal branch.
>>
>> The tests for entity-mode dom4j have been removed, but it might be a
>> better idea to write new ones that expect an error.
>> Also the hibernate-mapping-4.0.xsd schema hasn't been valid since
>> dom4j entity-mode was removed in 2011
>> (4a4f636caf9ecc62fe0d230f422ad3eab2517db0) but I haven't touched it.
>>
>> You could wait for 6.0, but there is time to review this for 5.3.
>>
> The biggest difference between what you did and my own for Envers is
> that I decided to use the JAXB binding classes directly rather than
> replace dom4j with another XML abstraction.? Using JAXB binding
> classes directly gives several noticeable benefits:
>
> ?* Better maintainability - cleaner and easier to read code
> ?* Better performance - less in-memory string manipulation and cloning
> ?* Most important - compile-time schema compliance.
>
> The replacement of dom4j with the w3c equivalents is likely fine for
> 5.3; however, the long-term goal is to do away with the XML
> manipulation all together in Envers.
>
>> I have only passed a `clean build` using JDK8 and the default H2
>> database. Maybe other databases could expose errors, but it's highly
>> unlikely.
>> JDK9 is a bit more likely to expose an incompatibility.
>>
>> On 19 February 2018 at 17:03, Chris Cranford <chris at hibernate.org
>> <mailto:chris at hibernate.org>> wrote:
>>
>>     See below
>>
>>     On 02/18/2018 11:38 AM, Steve Ebersole wrote:
>>     > On Sun, Feb 18, 2018 at 4:52 AM Jordan Gigov
>>     <coladict at gmail.com <mailto:coladict at gmail.com>> wrote:
>>     >
>>     >> I think transitioning to automatic bindings via JAXB will
>>     result in error
>>     >> messages on wrong configurations becoming far too vague to be
>>     useful to the
>>     >> users.
>>     >>
>>     > I'm not understanding... we've used jaxb since 4.0
>>     >
>>     > I am just talking about envers and how it integrates with
>>     hibernate-core.
>>     > At the moment it directly uses dom4j - we'd like to eventualy
>>     have it use
>>     > the jaxb model instead
>>
>>     There is a JIRA [1] that specifically targets this work from an
>>     Envers
>>     perspective.?
>>
>>     I have a working implementation based on Hibernate 5.x but this is
>>     planned to be integrated in Hibernate 6.? I'd expect to see this get
>>     integrated once we get a bit more development finalized around
>>     Hibernate
>>     Core in 6.
>>
>>     [1]: https://hibernate.atlassian.net/browse/HHH-11483
>>     <https://hibernate.atlassian.net/browse/HHH-11483>
>>
>>     Thanks,
>>     Chris
>>
>>
>


From lukas.eder at gmail.com  Thu Feb 22 03:09:49 2018
From: lukas.eder at gmail.com (Lukas Eder)
Date: Thu, 22 Feb 2018 09:09:49 +0100
Subject: [hibernate-dev] Why does implicit join translate to inner join?
Message-ID: <CAB4ELO6Q5VAXMPe-GpYKr4-hV7+nONViSV9vSoF7VrhbuuJjiw@mail.gmail.com>

 Hello,

Vlad Mihalcea [1] was so kind to point me to this mailing list with my
question about implicit joins. The user guide [2] states that:

  "Implicit joins are always treated as inner joins."

To me, this seems wrong, semantically, if implicit joins follow optional
(nullable) foreign key relationships. Let's assume that customers have
optional addresses. When we write

  SELECT c.firstName, c.lastName, c.address.city.country.code
  FROM customer c

The resulting query will INNER JOIN the customer / address / city / country
tables, filtering out customers with no address, or addresses with no
cities, or cities with no countries (let's ignore the modelling aspect). In
fact, I got a CROSS JOIN with join predicate in the WHERE clause, but that
doesn't really change anything. Hence the SELECT clause applies a filter,
which is rather surprising. To me, this seems simply wrong just like it
would be wrong for Stream.map() to apply any filters.

However, I'm sure there must have been good reasons to default to this
behaviour, even in the presence of optional foreign keys.

Does anyone know what those reasons are?
Cheers,
Lukas

[1]: https://twitter.com/vlad_mihalcea/status/965927462684196864
[2]: http://docs.jboss.org/hibernate/orm/5.2/userguide/
html_single/Hibernate_User_Guide.html#hql-implicit-join

From andrea at hibernate.org  Thu Feb 22 04:59:45 2018
From: andrea at hibernate.org (andrea boriero)
Date: Thu, 22 Feb 2018 09:59:45 +0000
Subject: [hibernate-dev] Why does implicit join translate to inner join?
In-Reply-To: <CAB4ELO6Q5VAXMPe-GpYKr4-hV7+nONViSV9vSoF7VrhbuuJjiw@mail.gmail.com>
References: <CAB4ELO6Q5VAXMPe-GpYKr4-hV7+nONViSV9vSoF7VrhbuuJjiw@mail.gmail.com>
Message-ID: <CAL00eST_WAfuhsFUppK5YvWu+p-ExwzExajfON=2iD4wtvf0yw@mail.gmail.com>

Hi Lukas,

I think it is based on JPA 2.1 spec, 4.4.4 Path Expressions , "Path
expression navigability is composed using ?inner join? semantics."

On 22 February 2018 at 08:09, Lukas Eder <lukas.eder at gmail.com> wrote:

>  Hello,
>
> Vlad Mihalcea [1] was so kind to point me to this mailing list with my
> question about implicit joins. The user guide [2] states that:
>
>   "Implicit joins are always treated as inner joins."
>
> To me, this seems wrong, semantically, if implicit joins follow optional
> (nullable) foreign key relationships. Let's assume that customers have
> optional addresses. When we write
>
>   SELECT c.firstName, c.lastName, c.address.city.country.code
>   FROM customer c
>
> The resulting query will INNER JOIN the customer / address / city / country
> tables, filtering out customers with no address, or addresses with no
> cities, or cities with no countries (let's ignore the modelling aspect). In
> fact, I got a CROSS JOIN with join predicate in the WHERE clause, but that
> doesn't really change anything. Hence the SELECT clause applies a filter,
> which is rather surprising. To me, this seems simply wrong just like it
> would be wrong for Stream.map() to apply any filters.
>
> However, I'm sure there must have been good reasons to default to this
> behaviour, even in the presence of optional foreign keys.
>
> Does anyone know what those reasons are?
> Cheers,
> Lukas
>
> [1]: https://twitter.com/vlad_mihalcea/status/965927462684196864
> [2]: http://docs.jboss.org/hibernate/orm/5.2/userguide/
> html_single/Hibernate_User_Guide.html#hql-implicit-join
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From lukas.eder at gmail.com  Thu Feb 22 05:05:33 2018
From: lukas.eder at gmail.com (Lukas Eder)
Date: Thu, 22 Feb 2018 11:05:33 +0100
Subject: [hibernate-dev] Why does implicit join translate to inner join?
In-Reply-To: <CAL00eST_WAfuhsFUppK5YvWu+p-ExwzExajfON=2iD4wtvf0yw@mail.gmail.com>
References: <CAB4ELO6Q5VAXMPe-GpYKr4-hV7+nONViSV9vSoF7VrhbuuJjiw@mail.gmail.com>
	<CAL00eST_WAfuhsFUppK5YvWu+p-ExwzExajfON=2iD4wtvf0yw@mail.gmail.com>
Message-ID: <CAB4ELO6UCYb2Q+L+ff3nsJdXUEksM_oxQdvbwJ3v88w9GtTApw@mail.gmail.com>

Sure, there may be a chicken and egg situation between Hibernate and JPA,
but I'm trying to understand why this was specified the way it is, as I
find this quite surprising.

2018-02-22 10:59 GMT+01:00 andrea boriero <andrea at hibernate.org>:

> Hi Lukas,
>
> I think it is based on JPA 2.1 spec, 4.4.4 Path Expressions , "Path
> expression navigability is composed using ?inner join? semantics."
>
> On 22 February 2018 at 08:09, Lukas Eder <lukas.eder at gmail.com> wrote:
>
>>  Hello,
>>
>> Vlad Mihalcea [1] was so kind to point me to this mailing list with my
>> question about implicit joins. The user guide [2] states that:
>>
>>   "Implicit joins are always treated as inner joins."
>>
>> To me, this seems wrong, semantically, if implicit joins follow optional
>> (nullable) foreign key relationships. Let's assume that customers have
>> optional addresses. When we write
>>
>>   SELECT c.firstName, c.lastName, c.address.city.country.code
>>   FROM customer c
>>
>> The resulting query will INNER JOIN the customer / address / city /
>> country
>> tables, filtering out customers with no address, or addresses with no
>> cities, or cities with no countries (let's ignore the modelling aspect).
>> In
>> fact, I got a CROSS JOIN with join predicate in the WHERE clause, but that
>> doesn't really change anything. Hence the SELECT clause applies a filter,
>> which is rather surprising. To me, this seems simply wrong just like it
>> would be wrong for Stream.map() to apply any filters.
>>
>> However, I'm sure there must have been good reasons to default to this
>> behaviour, even in the presence of optional foreign keys.
>>
>> Does anyone know what those reasons are?
>> Cheers,
>> Lukas
>>
>> [1]: https://twitter.com/vlad_mihalcea/status/965927462684196864
>> [2]: http://docs.jboss.org/hibernate/orm/5.2/userguide/
>> html_single/Hibernate_User_Guide.html#hql-implicit-join
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From yoann at hibernate.org  Thu Feb 22 06:07:48 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Thu, 22 Feb 2018 11:07:48 +0000
Subject: [hibernate-dev] [OGM] Validating our artifacts don't rely on
	JBoss-only dependencies
Message-ID: <CAEqagpoxRoMx0tnaojG1pYBPW0F1QpUDQ-d3QeHrQURFDvya4w@mail.gmail.com>

Hello,

TL;DR: can I move hibernate-ogm-infinispan-remote tests to the
integrationtest module, since they are actually integration tests?

During one of our previous IRC meetings, I mentioned that we did some
changes in the Hibernate Search POMs to remove the need for custom settings
when building. The idea was to hard-code the JBoss repositories in the POMs
of modules that need them, so that other modules would be built using Maven
Central only. This way, we would make sure our modules only rely on
dependencies that are available in Maven Central, not some obscure
artifacts only available in the JBoss Maven repository.

I am trying to do the same in OGM, but there is one problem: for this to be
possible at all, integration tests that do require those exotic
dependencies need to be in a separate Maven module.
It turns out some tests implemented in the infinispan-remote module require
to spin up an Infinispan server, which does have exotic dependencies (it's
basically a WildFly server, if I understood correctly).

Thus, in order to remove the need for custom settings when building, I
would need to move those tests to the integrationtest module. They are
integration tests, after all, since they need a running Infinispan server
to work.

Would anyone object to that?


-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From mihalcea.vlad at gmail.com  Thu Feb 22 07:19:36 2018
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 22 Feb 2018 14:19:36 +0200
Subject: [hibernate-dev] Why does implicit join translate to inner join?
In-Reply-To: <CAB4ELO6UCYb2Q+L+ff3nsJdXUEksM_oxQdvbwJ3v88w9GtTApw@mail.gmail.com>
References: <CAB4ELO6Q5VAXMPe-GpYKr4-hV7+nONViSV9vSoF7VrhbuuJjiw@mail.gmail.com>
	<CAL00eST_WAfuhsFUppK5YvWu+p-ExwzExajfON=2iD4wtvf0yw@mail.gmail.com>
	<CAB4ELO6UCYb2Q+L+ff3nsJdXUEksM_oxQdvbwJ3v88w9GtTApw@mail.gmail.com>
Message-ID: <CA+gWKMAuNUcFLxToH9BXEbA=pk4Ejud_KF-DZ=ch+CknM0NvsQ@mail.gmail.com>

Hi,

Maybe Steve remembers the reason why INNER JOIN was chosen.

One possible reason was to have a single way of treating implicit joins.

In WHERE and ORDER BY clauses, implicit join makes sense to render an INNER
JOIN.

Only when used in the SELECT clause only, LEFT JOIN would work just fine.

So, I guess it was because we wanted to handle the implicit join in the
same fashion no matter where it is used.

But, I might be wrong, so I'm looking forward to Steve's answer too.

Vlad

On Thu, Feb 22, 2018 at 12:05 PM, Lukas Eder <lukas.eder at gmail.com> wrote:

> Sure, there may be a chicken and egg situation between Hibernate and JPA,
> but I'm trying to understand why this was specified the way it is, as I
> find this quite surprising.
>
> 2018-02-22 10:59 GMT+01:00 andrea boriero <andrea at hibernate.org>:
>
> > Hi Lukas,
> >
> > I think it is based on JPA 2.1 spec, 4.4.4 Path Expressions , "Path
> > expression navigability is composed using ?inner join? semantics."
> >
> > On 22 February 2018 at 08:09, Lukas Eder <lukas.eder at gmail.com> wrote:
> >
> >>  Hello,
> >>
> >> Vlad Mihalcea [1] was so kind to point me to this mailing list with my
> >> question about implicit joins. The user guide [2] states that:
> >>
> >>   "Implicit joins are always treated as inner joins."
> >>
> >> To me, this seems wrong, semantically, if implicit joins follow optional
> >> (nullable) foreign key relationships. Let's assume that customers have
> >> optional addresses. When we write
> >>
> >>   SELECT c.firstName, c.lastName, c.address.city.country.code
> >>   FROM customer c
> >>
> >> The resulting query will INNER JOIN the customer / address / city /
> >> country
> >> tables, filtering out customers with no address, or addresses with no
> >> cities, or cities with no countries (let's ignore the modelling aspect).
> >> In
> >> fact, I got a CROSS JOIN with join predicate in the WHERE clause, but
> that
> >> doesn't really change anything. Hence the SELECT clause applies a
> filter,
> >> which is rather surprising. To me, this seems simply wrong just like it
> >> would be wrong for Stream.map() to apply any filters.
> >>
> >> However, I'm sure there must have been good reasons to default to this
> >> behaviour, even in the presence of optional foreign keys.
> >>
> >> Does anyone know what those reasons are?
> >> Cheers,
> >> Lukas
> >>
> >> [1]: https://twitter.com/vlad_mihalcea/status/965927462684196864
> >> [2]: http://docs.jboss.org/hibernate/orm/5.2/userguide/
> >> html_single/Hibernate_User_Guide.html#hql-implicit-join
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From daltodavide at gmail.com  Thu Feb 22 07:29:45 2018
From: daltodavide at gmail.com (Davide D'Alto)
Date: Thu, 22 Feb 2018 12:29:45 +0000
Subject: [hibernate-dev] [OGM] Validating our artifacts don't rely on
 JBoss-only dependencies
In-Reply-To: <CAEqagpoxRoMx0tnaojG1pYBPW0F1QpUDQ-d3QeHrQURFDvya4w@mail.gmail.com>
References: <CAEqagpoxRoMx0tnaojG1pYBPW0F1QpUDQ-d3QeHrQURFDvya4w@mail.gmail.com>
Message-ID: <CANoTJYMUgzV1uKkftwZV3EGO7Q6mwP1MdAZtW0pt4JW9DDeOHw@mail.gmail.com>

Not sure about it, those are specific integration tests for infinispan remote.
The integrationtest folder is more to test the hibernate-ogm-modules
and have some
checks that the dialects work with WildFly really.

> after all, since they need a running Infinispan server
to work.

All the tests in Hibernat OGM are basically integration tests, except
for embedded databases
they need a remote db to work.

In fact, I think it was a mistake to put them in the maven test phase.
They should be in the integration-test one.

Can't we keep them in the same module but in a different profile
disabled by default?
Actually, it should already skip them with the option skipITs.

On Thu, Feb 22, 2018 at 11:07 AM, Yoann Rodiere <yoann at hibernate.org> wrote:
> Hello,
>
> TL;DR: can I move hibernate-ogm-infinispan-remote tests to the
> integrationtest module, since they are actually integration tests?
>
> During one of our previous IRC meetings, I mentioned that we did some
> changes in the Hibernate Search POMs to remove the need for custom settings
> when building. The idea was to hard-code the JBoss repositories in the POMs
> of modules that need them, so that other modules would be built using Maven
> Central only. This way, we would make sure our modules only rely on
> dependencies that are available in Maven Central, not some obscure
> artifacts only available in the JBoss Maven repository.
>
> I am trying to do the same in OGM, but there is one problem: for this to be
> possible at all, integration tests that do require those exotic
> dependencies need to be in a separate Maven module.
> It turns out some tests implemented in the infinispan-remote module require
> to spin up an Infinispan server, which does have exotic dependencies (it's
> basically a WildFly server, if I understood correctly).
>
> Thus, in order to remove the need for custom settings when building, I
> would need to move those tests to the integrationtest module. They are
> integration tests, after all, since they need a running Infinispan server
> to work.
>
> Would anyone object to that?
>
>
> --
> Yoann Rodiere
> yoann at hibernate.org / yrodiere at redhat.com
> Software Engineer
> Hibernate NoORM team
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From yoann at hibernate.org  Thu Feb 22 08:09:48 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Thu, 22 Feb 2018 13:09:48 +0000
Subject: [hibernate-dev] [OGM] Validating our artifacts don't rely on
 JBoss-only dependencies
In-Reply-To: <CANoTJYMUgzV1uKkftwZV3EGO7Q6mwP1MdAZtW0pt4JW9DDeOHw@mail.gmail.com>
References: <CAEqagpoxRoMx0tnaojG1pYBPW0F1QpUDQ-d3QeHrQURFDvya4w@mail.gmail.com>
	<CANoTJYMUgzV1uKkftwZV3EGO7Q6mwP1MdAZtW0pt4JW9DDeOHw@mail.gmail.com>
Message-ID: <CAEqagpq8dq12FogKKt+xFXS8DrwMifC_QSbfvgR4x7gYTRKupA@mail.gmail.com>

> The integrationtest folder is more to test the hibernate-ogm-modules
> and have some
> checks that the dialects work with WildFly really.

I could move the current integration tests to integrationtest/wildfly and
create a new integrationtest/infinispan-remote module? Then it would be
clear which test is about which integration.

> Can't we keep them in the same module but in a different profile
> disabled by default?
> Actually, it should already skip them with the option skipITs.

Maybe we could... But I'm a bit worried about having hard-coded
repositories in POMs that will be consumed by our users. From what I
understood it caused some problems in the past, because those hard-coded
repos have the nasty habit of contaminating every consuming POM. Even with
a profile, some users depending on infinispan-remote and activating an
"integrationtest" profile of their own would unknowingly enable the JBoss
repositories, I think.
All in all, if we really need to keep them in the same module, I think it
would be safer not to proceed with my changes. But of course my preference
would be to move them to another module :)



On Thu, 22 Feb 2018 at 13:30 Davide D'Alto <daltodavide at gmail.com> wrote:

> Not sure about it, those are specific integration tests for infinispan
> remote.
> The integrationtest folder is more to test the hibernate-ogm-modules
> and have some
> checks that the dialects work with WildFly really.
>
> > after all, since they need a running Infinispan server
> to work.
>
> All the tests in Hibernat OGM are basically integration tests, except
> for embedded databases
> they need a remote db to work.
>
> In fact, I think it was a mistake to put them in the maven test phase.
> They should be in the integration-test one.
>
> Can't we keep them in the same module but in a different profile
> disabled by default?
> Actually, it should already skip them with the option skipITs.
>
> On Thu, Feb 22, 2018 at 11:07 AM, Yoann Rodiere <yoann at hibernate.org>
> wrote:
> > Hello,
> >
> > TL;DR: can I move hibernate-ogm-infinispan-remote tests to the
> > integrationtest module, since they are actually integration tests?
> >
> > During one of our previous IRC meetings, I mentioned that we did some
> > changes in the Hibernate Search POMs to remove the need for custom
> settings
> > when building. The idea was to hard-code the JBoss repositories in the
> POMs
> > of modules that need them, so that other modules would be built using
> Maven
> > Central only. This way, we would make sure our modules only rely on
> > dependencies that are available in Maven Central, not some obscure
> > artifacts only available in the JBoss Maven repository.
> >
> > I am trying to do the same in OGM, but there is one problem: for this to
> be
> > possible at all, integration tests that do require those exotic
> > dependencies need to be in a separate Maven module.
> > It turns out some tests implemented in the infinispan-remote module
> require
> > to spin up an Infinispan server, which does have exotic dependencies
> (it's
> > basically a WildFly server, if I understood correctly).
> >
> > Thus, in order to remove the need for custom settings when building, I
> > would need to move those tests to the integrationtest module. They are
> > integration tests, after all, since they need a running Infinispan server
> > to work.
> >
> > Would anyone object to that?
> >
> >
> > --
> > Yoann Rodiere
> > yoann at hibernate.org / yrodiere at redhat.com
> > Software Engineer
> > Hibernate NoORM team
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From lukas.eder at gmail.com  Thu Feb 22 08:14:09 2018
From: lukas.eder at gmail.com (Lukas Eder)
Date: Thu, 22 Feb 2018 14:14:09 +0100
Subject: [hibernate-dev] Why does implicit join translate to inner join?
In-Reply-To: <CA+gWKMAuNUcFLxToH9BXEbA=pk4Ejud_KF-DZ=ch+CknM0NvsQ@mail.gmail.com>
References: <CAB4ELO6Q5VAXMPe-GpYKr4-hV7+nONViSV9vSoF7VrhbuuJjiw@mail.gmail.com>
	<CAL00eST_WAfuhsFUppK5YvWu+p-ExwzExajfON=2iD4wtvf0yw@mail.gmail.com>
	<CAB4ELO6UCYb2Q+L+ff3nsJdXUEksM_oxQdvbwJ3v88w9GtTApw@mail.gmail.com>
	<CA+gWKMAuNUcFLxToH9BXEbA=pk4Ejud_KF-DZ=ch+CknM0NvsQ@mail.gmail.com>
Message-ID: <CAB4ELO5rgCeymBi+xeSQMRU+OhkA0SXA+Gp0JezOOOsTAMB4iw@mail.gmail.com>

2018-02-22 13:19 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:

> Hi,
>
> One possible reason was to have a single way of treating implicit joins.
>

Sure, but if paths generated only outer joins, your statement would still
be true.


> In WHERE and ORDER BY clauses, implicit join makes sense to render an
> INNER JOIN.
>

I agree with WHERE for most cases, but I decidedly do not agree with ORDER
BY. It is even more surprising when an ORDER BY clause implicitly filters
the results due to the presence of an implicit join path. For example (not
sure if that works in JPQL right now, but I don't see anything wrong with
the concept):

   SELECT c.firstName, c.lastName
   FROM customer c
   ORDER BY c.address.city.country.code

So, this query would implicitly filter out customers without addresses (or
whose addresses had no cities, etc.) rather than applying default NULLS
FIRST / NULLS LAST semantics?

There's also a case where an outer join is useful in the WHERE clause,
namely with IS NULL predicates:

   SELECT c.firstName, c.lastName
   FROM customer c
   WHERE c.address.city.country.code IS NULL

In this case, the predicate could act like an Elvis operator on the whole
path as it evaluates to true if *any* of the values is null (address, city,
country, or country code). In the current case of generating inner joins,
only country codes that are NULL are retained. This is the only case I can
see where both join types would be reasonable in their own ways. For
consistency, I'd still opt for outer joins in this case as well.

Lukas

From steve at hibernate.org  Thu Feb 22 09:57:56 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 22 Feb 2018 14:57:56 +0000
Subject: [hibernate-dev] Why does implicit join translate to inner join?
In-Reply-To: <CAB4ELO5rgCeymBi+xeSQMRU+OhkA0SXA+Gp0JezOOOsTAMB4iw@mail.gmail.com>
References: <CAB4ELO6Q5VAXMPe-GpYKr4-hV7+nONViSV9vSoF7VrhbuuJjiw@mail.gmail.com>
	<CAL00eST_WAfuhsFUppK5YvWu+p-ExwzExajfON=2iD4wtvf0yw@mail.gmail.com>
	<CAB4ELO6UCYb2Q+L+ff3nsJdXUEksM_oxQdvbwJ3v88w9GtTApw@mail.gmail.com>
	<CA+gWKMAuNUcFLxToH9BXEbA=pk4Ejud_KF-DZ=ch+CknM0NvsQ@mail.gmail.com>
	<CAB4ELO5rgCeymBi+xeSQMRU+OhkA0SXA+Gp0JezOOOsTAMB4iw@mail.gmail.com>
Message-ID: <CAFdSV9vT7mFsYg9CPG6w+XZow8PDLVTiqjwkTNogsjTzKqU8fg@mail.gmail.com>

Yes, this could be made sensitive to where the implicit join occurs.

However, there is another, better way... explicit joins.  In our opinion
originally (and nothing has changed my mind about this) it is better to be
consistent in how implicit joins are handled.  It is far easier to impart
to users that "implicit inner joins are always inner joins" as opposed to
"well implicit joins are interpreted relative to the association being
joined".  Not to mention, adjusting the type of SQL join used for implicit
jois means I can no longer just look at the query and know what is
happening in terms of SQL joins - which is bad.

Not to mention, IMO interpreting these as inner joins is more OO-ish.  I
realize there are different points of view on this, but again, if you want
explicit joining characteristics you can, you know, declare thew joins
explicitly.

On Thu, Feb 22, 2018 at 7:14 AM Lukas Eder <lukas.eder at gmail.com> wrote:

> 2018-02-22 13:19 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
>
> > Hi,
> >
> > One possible reason was to have a single way of treating implicit joins.
> >
>
> Sure, but if paths generated only outer joins, your statement would still
> be true.
>
>
> > In WHERE and ORDER BY clauses, implicit join makes sense to render an
> > INNER JOIN.
> >
>
> I agree with WHERE for most cases, but I decidedly do not agree with ORDER
> BY. It is even more surprising when an ORDER BY clause implicitly filters
> the results due to the presence of an implicit join path. For example (not
> sure if that works in JPQL right now, but I don't see anything wrong with
> the concept):
>
>    SELECT c.firstName, c.lastName
>    FROM customer c
>    ORDER BY c.address.city.country.code
>
> So, this query would implicitly filter out customers without addresses (or
> whose addresses had no cities, etc.) rather than applying default NULLS
> FIRST / NULLS LAST semantics?
>
> There's also a case where an outer join is useful in the WHERE clause,
> namely with IS NULL predicates:
>
>    SELECT c.firstName, c.lastName
>    FROM customer c
>    WHERE c.address.city.country.code IS NULL
>
> In this case, the predicate could act like an Elvis operator on the whole
> path as it evaluates to true if *any* of the values is null (address, city,
> country, or country code). In the current case of generating inner joins,
> only country codes that are NULL are retained. This is the only case I can
> see where both join types would be reasonable in their own ways. For
> consistency, I'd still opt for outer joins in this case as well.
>
> Lukas
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From lukas.eder at gmail.com  Thu Feb 22 10:10:58 2018
From: lukas.eder at gmail.com (Lukas Eder)
Date: Thu, 22 Feb 2018 16:10:58 +0100
Subject: [hibernate-dev] Why does implicit join translate to inner join?
In-Reply-To: <CAFdSV9vT7mFsYg9CPG6w+XZow8PDLVTiqjwkTNogsjTzKqU8fg@mail.gmail.com>
References: <CAB4ELO6Q5VAXMPe-GpYKr4-hV7+nONViSV9vSoF7VrhbuuJjiw@mail.gmail.com>
	<CAL00eST_WAfuhsFUppK5YvWu+p-ExwzExajfON=2iD4wtvf0yw@mail.gmail.com>
	<CAB4ELO6UCYb2Q+L+ff3nsJdXUEksM_oxQdvbwJ3v88w9GtTApw@mail.gmail.com>
	<CA+gWKMAuNUcFLxToH9BXEbA=pk4Ejud_KF-DZ=ch+CknM0NvsQ@mail.gmail.com>
	<CAB4ELO5rgCeymBi+xeSQMRU+OhkA0SXA+Gp0JezOOOsTAMB4iw@mail.gmail.com>
	<CAFdSV9vT7mFsYg9CPG6w+XZow8PDLVTiqjwkTNogsjTzKqU8fg@mail.gmail.com>
Message-ID: <CAB4ELO5mib8sqmRJSfVMzbA2YNH_kr-76QQG-hXfRRE8SXLc4A@mail.gmail.com>

Hi Steve,

Thanks for your message. Of course, being explicit always has the advantage
of ... being explicit. But my question here is really about the implicit
join feature and how it works.

2018-02-22 15:57 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> it is better to be consistent in how implicit joins are handled.  It is
> far easier to impart to users that "implicit inner joins are always inner
> joins" as opposed to "well implicit joins are interpreted relative to the
> association being joined"
>

I don't disagree at all. In my opinion, the ideal approach would be
"implicit joins are always outer joins"


> Not to mention, adjusting the type of SQL join used for implicit jois
> means I can no longer just look at the query and know what is happening in
> terms of SQL joins - which is bad.
>

Why not? There's just an additional keyword between the generated tables:
LEFT (or if you will, LEFT OUTER).


> Not to mention, IMO interpreting these as inner joins is more OO-ish.
>

I'm curious about that, would you mind elaborating?

And what's your opinion on the Stream analogy, where the current behaviour
(implicit joins from the context of a SELECT clause) corresponds to
Stream.map() potentially applying filters?

From steve at hibernate.org  Thu Feb 22 15:39:37 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 22 Feb 2018 20:39:37 +0000
Subject: [hibernate-dev] Why does implicit join translate to inner join?
In-Reply-To: <CAB4ELO5mib8sqmRJSfVMzbA2YNH_kr-76QQG-hXfRRE8SXLc4A@mail.gmail.com>
References: <CAB4ELO6Q5VAXMPe-GpYKr4-hV7+nONViSV9vSoF7VrhbuuJjiw@mail.gmail.com>
	<CAL00eST_WAfuhsFUppK5YvWu+p-ExwzExajfON=2iD4wtvf0yw@mail.gmail.com>
	<CAB4ELO6UCYb2Q+L+ff3nsJdXUEksM_oxQdvbwJ3v88w9GtTApw@mail.gmail.com>
	<CA+gWKMAuNUcFLxToH9BXEbA=pk4Ejud_KF-DZ=ch+CknM0NvsQ@mail.gmail.com>
	<CAB4ELO5rgCeymBi+xeSQMRU+OhkA0SXA+Gp0JezOOOsTAMB4iw@mail.gmail.com>
	<CAFdSV9vT7mFsYg9CPG6w+XZow8PDLVTiqjwkTNogsjTzKqU8fg@mail.gmail.com>
	<CAB4ELO5mib8sqmRJSfVMzbA2YNH_kr-76QQG-hXfRRE8SXLc4A@mail.gmail.com>
Message-ID: <CAFdSV9vuGNQSaOWSXYCYOJvib5fUHcT31MDSxR+Jgn=s8yiqqA@mail.gmail.com>

On Thu, Feb 22, 2018 at 9:11 AM Lukas Eder <lukas.eder at gmail.com> wrote:

> Hi Steve,
>
> Thanks for your message. Of course, being explicit always has the
> advantage of ... being explicit. But my question here is really about the
> implicit join feature and how it works.
>

Sure, but that is also part of the answer.  A big part



> Not to mention, adjusting the type of SQL join used for implicit jois
>> means I can no longer just look at the query and know what is happening in
>> terms of SQL joins - which is bad.
>>
>
> Why not? There's just an additional keyword between the generated tables:
> LEFT (or if you will, LEFT OUTER).
>

I think you misunderstand...  I was saying that I can no longer look at the
HQL/JPQL and tell what kind of SQL joins will be used for that if it is
dependent on the mapped association.  This approach was mentioned  earlier
in the thread.  But you clarified that you mean that implicit joins ought
to just always be interpreted as an outer join.

You could plugin in your own query handling and interpret implicit joins
however you want.  That is current not the most trivial task though.



>
>> Not to mention, IMO interpreting these as inner joins is more OO-ish.
>>
>
> I'm curious about that, would you mind elaborating?
>

Well in normal Java - Idiomatic Java ;) - calling `p.address.city` leads to
a NPE if `p.address` happens to be null, right?  To me, using inner joins
naturally follows from that - you are saying no intermediate path is null.


And what's your opinion on the Stream analogy, where the current behaviour
> (implicit joins from the context of a SELECT clause) corresponds to
> Stream.map() potentially applying filters?
>

Well 2 things:

1) I personally think its not good form to put null in the output of a
Stream map operation, so to me that in fact does imply a filtering
2) You think its odd that the SELECT clause "applies a filter", but your ok
with the fact that it can expand the query domain (from clause)?  I think
that is inconsistent.

From yoann at hibernate.org  Fri Feb 23 04:11:12 2018
From: yoann at hibernate.org (Yoann Rodiere)
Date: Fri, 23 Feb 2018 09:11:12 +0000
Subject: [hibernate-dev] Hibernate Search 5.10.0.Beta1 is out
Message-ID: <CAEqagpqgOKr0kQMC2RhdVQUFDejwu=mnVWXMfH6SrAkDEOdkqQ@mail.gmail.com>

Hello,

We just published 5.10.0.Beta1, the first release in the 5.10 branch. This
release is designed to work with Hibernate ORM 5.3, which is still just a
Candidate Release. This means you can now test your applications relying on
ORM+Search with ORM 5.3 and Search 5.10.

Check out our blog for more information about this release:

http://in.relation.to/2018/02/23/hibernate-search-5-10-0-Beta1/



-- 
Yoann Rodiere
yoann at hibernate.org / yrodiere at redhat.com
Software Engineer
Hibernate NoORM team

From lukas.eder at gmail.com  Fri Feb 23 04:39:58 2018
From: lukas.eder at gmail.com (Lukas Eder)
Date: Fri, 23 Feb 2018 10:39:58 +0100
Subject: [hibernate-dev] Why does implicit join translate to inner join?
In-Reply-To: <CAFdSV9vuGNQSaOWSXYCYOJvib5fUHcT31MDSxR+Jgn=s8yiqqA@mail.gmail.com>
References: <CAB4ELO6Q5VAXMPe-GpYKr4-hV7+nONViSV9vSoF7VrhbuuJjiw@mail.gmail.com>
	<CAL00eST_WAfuhsFUppK5YvWu+p-ExwzExajfON=2iD4wtvf0yw@mail.gmail.com>
	<CAB4ELO6UCYb2Q+L+ff3nsJdXUEksM_oxQdvbwJ3v88w9GtTApw@mail.gmail.com>
	<CA+gWKMAuNUcFLxToH9BXEbA=pk4Ejud_KF-DZ=ch+CknM0NvsQ@mail.gmail.com>
	<CAB4ELO5rgCeymBi+xeSQMRU+OhkA0SXA+Gp0JezOOOsTAMB4iw@mail.gmail.com>
	<CAFdSV9vT7mFsYg9CPG6w+XZow8PDLVTiqjwkTNogsjTzKqU8fg@mail.gmail.com>
	<CAB4ELO5mib8sqmRJSfVMzbA2YNH_kr-76QQG-hXfRRE8SXLc4A@mail.gmail.com>
	<CAFdSV9vuGNQSaOWSXYCYOJvib5fUHcT31MDSxR+Jgn=s8yiqqA@mail.gmail.com>
Message-ID: <CAB4ELO43kWFjZ4n7b5pi-0RuWNmVA8nU4mP3H_-g3k-ro=qT-Q@mail.gmail.com>

2018-02-22 21:39 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> On Thu, Feb 22, 2018 at 9:11 AM Lukas Eder <lukas.eder at gmail.com> wrote:
>
>> Hi Steve,
>>
>> Thanks for your message. Of course, being explicit always has the
>> advantage of ... being explicit. But my question here is really about the
>> implicit join feature and how it works.
>>
>
> Sure, but that is also part of the answer.  A big part
>

I take you kinda regret the feature? :-) But I'm certain that many users
find it extremely useful.


> Not to mention, adjusting the type of SQL join used for implicit jois
>>> means I can no longer just look at the query and know what is happening in
>>> terms of SQL joins - which is bad.
>>>
>>
>> Why not? There's just an additional keyword between the generated tables:
>> LEFT (or if you will, LEFT OUTER).
>>
>
> I think you misunderstand...  I was saying that I can no longer look at
> the HQL/JPQL and tell what kind of SQL joins will be used for that if it is
> dependent on the mapped association.
>

OK, I see. However, this could be said of a few other features as well (at
least in SQL). For instance, Oracle's FETCH FIRST n ROWS ONLY is translated
to nesting queries and filtering on ROW_NUMBER() window functions, which is
indeed the same thing. FETCH FIRST n ROWS WITH TIES is translated to
nesting them and filtering on RANK(). FETCH FIRST n PERCENT ROWS can be
implemented with PERCENT_RANK() (although, I think that's not what's being
done). PIVOT could be seen as syntax sugar for GROUP BY and a generated set
of projections, UNPIVOT and GROUPING SETS for UNION ALL. That's the nature
of syntax sugar. It hides verbosity in favour of simplicity and development
ease, and in some cases, offers an option for a specific optimisation that
is only possible when the syntax sugar is used, not the "expanded" version.
For example, few databases are as mad as Oracle to translate FETCH FIRST to
window function filtering - they have more optimal LIMIT implementations.
That's just a historic Oracle issue.

The price is, well, the verbose version (which is more explicit and thus
more "clear") is hidden. But is that a high price to pay? I personally
think not.


>   This approach was mentioned  earlier in the thread.  But you clarified
> that you mean that implicit joins ought to just always be interpreted as an
> outer join.
>

I may have misstated that. Personally, I prefer them to be implemented in
the most optimal way because sadly, not all databases are able to transform
outer joins to inner joins when this is appropriate. From the databases I
checked (DB2 LUW, MySQL, Oracle, PostgreSQL, SQL Server), only DB2 does it.
I can imagine some edge cases where an inner join produces better
cardinality estimates in complex queries than a left join.

On the other hand, not all databases can eliminate inner joins. E.g.
PostgreSQL can only eliminate outer joins. This shouldn't apply in this
discussion, but just to show, there are pros and cons to both join types
from a performance perspective.

But for most trivial cases (and I'm assuming that most JPQL/HQL generated
queries, which don't support derived tables nor unions, will still match my
definition of trivial), this doesn't really matter much anyway, so I
understand that the pragmatic, preferred argument here is to always do it
in the same way.


> You could plugin in your own query handling and interpret implicit joins
> however you want.  That is current not the most trivial task though.
>

Sure, that's always an option! Perhaps a nice blog post for Vlad? ;-)


> Not to mention, IMO interpreting these as inner joins is more OO-ish.
>>>
>>
>> I'm curious about that, would you mind elaborating?
>>
>
> Well in normal Java - Idiomatic Java ;) - calling `p.address.city` leads
> to a NPE if `p.address` happens to be null, right?  To me, using inner
> joins naturally follows from that - you are saying no intermediate path is
> null.
>

I see. Although the query language, even if based on Java-annotated
entities, is a relational-ish one where NULL has a different semantics.
E.g. I don't suppose that substring(NULL, 1, 2) throws a NPE in JPQL, it'll
rather return NULL, just like NULL + 1 returns NULL. Likewise, I'm
expecting a NULL = NULL comparison to yield NULL, not TRUE.

I guess that's a matter of perspective. As a SQL person, I'd expect a
language (JPQL) that so obviously translates to SQL to follow SQL idioms
much more than Java idioms.


> And what's your opinion on the Stream analogy, where the current behaviour
>> (implicit joins from the context of a SELECT clause) corresponds to
>> Stream.map() potentially applying filters?
>>
>
> Well 2 things:
>
> 1) I personally think its not good form to put null in the output of a
> Stream map operation, so to me that in fact does imply a filtering
>

You should try suggesting that to the Stream EG :-) I'm pretty sure
everyone will agree that while your perception of good form is reasonable,
your implication is not. Besides, my example isn't equivalent to returning
null from a Stream.map() operation. It is equivalent to returning a tuple /
object where one of the attributes is null, which is probably a bit less
bad form.


> 2) You think its odd that the SELECT clause "applies a filter", but your
> ok with the fact that it can expand the query domain (from clause)?  I
> think that is inconsistent.
>

Technically, the canonical approach to implementing "implicit joins" is not
to implement joins at all, but correlated subqueries. My original query
example:

  SELECT c.firstName, c.lastName, c.address.city.country.code
  FROM customer c

Could easily be translated to:

  SELECT
    c.first_name,
    c.last_name,
    (
      SELECT co.code
      FROM country co
      JOIN city ci USING (country_id)
      JOIN address a USING (city_id)
      WHERE a.address_id = c.address_id
    )
  FROM customer c

While quickly being more verbose than a join-based solution, this looks
very natural. In addition to that, we get the desired behaviour of having
either the country code if all of address, city, country, and code are
present, or NULL if any of these things are absent. But never an implicit
filter.

This approach would work well logically, regardless where the implicit join
is located (including WHERE, GROUP BY, ORDER BY). However, it is quickly
prohibitive, performance wise, in pretty much every database. Even DB2 has
trouble factoring out similar join graphs to avoid doing them several times.

Yet in principle, correlated subqueries and left joins can be transformed
into each other in many cases, so left join is a pragmatic improvement
here, both from a readability and from a performance perspective. Inner
joins are not, because they are semantically very different.

I hope this clarifies why I don't think that modifying the "query domain",
as you call it, is inconsistent with my mental model of SQL-style
relational algebra. At least as long as the behaviour of SELECT * is
maintained correctly (i.e. the implicitly joined columns will not be
projected).

Lukas

From sanne at hibernate.org  Fri Feb 23 15:00:43 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 23 Feb 2018 20:00:43 +0000
Subject: [hibernate-dev] Byte-buddy: default enhancer in 5.3 ? [HHH-11253]
Message-ID: <CAFm4XO2FhuLz1AJ0oYQMPsbQpz4D5F7fh8195dhkZdY5SyVzHw@mail.gmail.com>

HHH-11253 is about making ByteBuddy the default implementation, but
it's flagged for 6.

I think that in Paris there was consensus to make it the default in
5.3 alredy, to possibly drop Javassist entirely in 6.0.

May I change this to 6 ? If that's ok, I can assign it to myself.

Thanks,
Sanne

From steve at hibernate.org  Fri Feb 23 15:29:20 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 23 Feb 2018 20:29:20 +0000
Subject: [hibernate-dev] Byte-buddy: default enhancer in 5.3 ?
	[HHH-11253]
In-Reply-To: <CAFm4XO2FhuLz1AJ0oYQMPsbQpz4D5F7fh8195dhkZdY5SyVzHw@mail.gmail.com>
References: <CAFm4XO2FhuLz1AJ0oYQMPsbQpz4D5F7fh8195dhkZdY5SyVzHw@mail.gmail.com>
Message-ID: <CAFdSV9tpkwoGn_sjywnfjxUBnOOPQDN_qGm2dA2dnSzeg_waeQ@mail.gmail.com>

You mean change to 5.3?  +1

On Fri, Feb 23, 2018 at 2:09 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> HHH-11253 is about making ByteBuddy the default implementation, but
> it's flagged for 6.
>
> I think that in Paris there was consensus to make it the default in
> 5.3 alredy, to possibly drop Javassist entirely in 6.0.
>
> May I change this to 6 ? If that's ok, I can assign it to myself.
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From andrea at hibernate.org  Tue Feb 27 02:43:14 2018
From: andrea at hibernate.org (andrea boriero)
Date: Tue, 27 Feb 2018 07:43:14 +0000
Subject: [hibernate-dev] Starting 5.2.14 release
Message-ID: <CAL00eSRQBLu4aAd-fOBN=uxAEUqWYvT=dwYGCUz_y-XUDbstrw@mail.gmail.com>

*Please do not push anything to 5.2 branch.Thanks,Andrea*

From sanne at hibernate.org  Tue Feb 27 06:13:18 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 27 Feb 2018 11:13:18 +0000
Subject: [hibernate-dev] Byte-buddy: default enhancer in 5.3 ?
	[HHH-11253]
In-Reply-To: <CAFdSV9tpkwoGn_sjywnfjxUBnOOPQDN_qGm2dA2dnSzeg_waeQ@mail.gmail.com>
References: <CAFm4XO2FhuLz1AJ0oYQMPsbQpz4D5F7fh8195dhkZdY5SyVzHw@mail.gmail.com>
	<CAFdSV9tpkwoGn_sjywnfjxUBnOOPQDN_qGm2dA2dnSzeg_waeQ@mail.gmail.com>
Message-ID: <CAFm4XO067GHWcREFhBQbpQeMVHd+8NgMcjnu-bqW7c7QiiFmuA@mail.gmail.com>

On 23 February 2018 at 20:29, Steve Ebersole <steve at hibernate.org> wrote:
> You mean change to 5.3?  +1

Right that's what I meant. Thanks, will do!

>
> On Fri, Feb 23, 2018 at 2:09 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> HHH-11253 is about making ByteBuddy the default implementation, but
>> it's flagged for 6.
>>
>> I think that in Paris there was consensus to make it the default in
>> 5.3 alredy, to possibly drop Javassist entirely in 6.0.
>>
>> May I change this to 6 ? If that's ok, I can assign it to myself.
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From andrea at hibernate.org  Tue Feb 27 08:37:13 2018
From: andrea at hibernate.org (andrea boriero)
Date: Tue, 27 Feb 2018 13:37:13 +0000
Subject: [hibernate-dev] Hibernate ORM 5.2.14.Final has been released
Message-ID: <CAL00eSRkq3nRQy8Dm+uFAnESM-TXNUHwFMzqQ=77BXftnKbmzw@mail.gmail.com>

*For
details:http://in.relation.to/2018/02/27/hibernate-orm-5214-final-release
<http://in.relation.to/2018/02/27/hibernate-orm-5214-final-release>*

From guillaume.smet at gmail.com  Tue Feb 27 09:44:02 2018
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 27 Feb 2018 15:44:02 +0100
Subject: [hibernate-dev] NoORM IRC meeting minutes
Message-ID: <CALt0+o8jqcM1i=wkU34vCcfUX+pR4ZWuA51eSn6E=YemJQgcGQ@mail.gmail.com>

Hi,

Here are the minutes of our biweekly NoORM IRC meeting:

15:42 < jbott> Meeting ended Tue Feb 27 14:42:36 2018 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:42 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-02-27-14.01.html
15:42 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-02-27-14.01.txt
15:42 < jbott> Log:

http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-02-27-14.01.log.html

Cheers,

-- 
Guillaume

From gbadner at redhat.com  Wed Feb 28 01:19:49 2018
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 27 Feb 2018 22:19:49 -0800
Subject: [hibernate-dev] Should EntityManager#refresh retain an existing
	lock?
In-Reply-To: <CA+gWKMCar73Y2LThNaFZSKjaWyTt_REncaVhmWP1XVva0Dr8-Q@mail.gmail.com>
References: <CAFDzhiS-T-bNbPAS3zqUmvVL1YE9XxeinZRTn5kg_9tGfCn8+g@mail.gmail.com>
	<CAFm4XO00KFXuhB6j9ZFrac8mwfZ5xbxs-TJm55uMoCJbu30qgg@mail.gmail.com>
	<CAFDzhiSEsBgwLC6t8J6tH3FRnL5EbkHYHDi-xoX+js9dE3ajSQ@mail.gmail.com>
	<CAFdSV9sy9DZdtfP30KyetAVavfO9+4ZrjytBOidwOd3pkvEWZA@mail.gmail.com>
	<CAFDzhiRbG=VWKvMuf9h+fQX=3mAkrCTxKtY72MQWj90orFdGMg@mail.gmail.com>
	<CA+gWKMCar73Y2LThNaFZSKjaWyTt_REncaVhmWP1XVva0Dr8-Q@mail.gmail.com>
Message-ID: <CAFDzhiSPa1fc1bRdROakKRpav9x+TzpHdv8Md37ddz2pPzkkyA@mail.gmail.com>

Steve,

I ran into a snag when fixing this.

Please take a look at my pull request:
https://github.com/hibernate/hibernate-orm/pull/2167

Thanks,
Gail

On Thu, Feb 1, 2018 at 5:39 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi Gail,
>
> Steve is right. Database locks cannot be released unless you end the
> transaction and that's how it works on any RDBMS, either in 2PL Mode or
> MVCC.
>
> As for optimistic locks:
>
> 1. LockModeType.OPTIMISTIC
>
> The check is done at the end of the end of the transaction. Refresh will
> only update the version, but the check should still be done so we should
> not probably switch to LockModeTypeNONE.
>
> 2. OPTIMISTIC_FORCE_INCREMENT,
>
> This one triggers a version increment in a different entity, so it should
> not be affected by the refresh of our entity.
>
> Vlad
>
> On Thu, Feb 1, 2018 at 1:12 AM, Gail Badner <gbadner at redhat.com> wrote:
>
>> OK, sounds good.
>>
>> Thanks,
>> Gail
>>
>> On Wed, Jan 31, 2018 at 2:38 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>> > It is possible to call EntityManager#lock(Object entity, LockModeType
>> >> lockMode) with a lower-level lock, but that request will be ignored.
>> >> Hibernate will only upgrade a lock.
>> >>
>> >
>> > Sure, this is in keeping with most (all?) databases - a transaction can
>> > only acquire more restrictive locks.
>> >
>> >
>> >
>> >> I think that clarifies retaining the same lock-level for the entity
>> when
>> >> calling EntityManager#refresh(Object entity).
>> >>
>> >> If no one has any comments that disagree with this in the next couple
>> of
>> >> days, I'll go with that.
>> >>
>> >
>> > That's the correct handling.
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From sanne at hibernate.org  Wed Feb 28 08:09:48 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 28 Feb 2018 13:09:48 +0000
Subject: [hibernate-dev] Byte-buddy: default enhancer in 5.3 ?
	[HHH-11253]
In-Reply-To: <CAFm4XO067GHWcREFhBQbpQeMVHd+8NgMcjnu-bqW7c7QiiFmuA@mail.gmail.com>
References: <CAFm4XO2FhuLz1AJ0oYQMPsbQpz4D5F7fh8195dhkZdY5SyVzHw@mail.gmail.com>
	<CAFdSV9tpkwoGn_sjywnfjxUBnOOPQDN_qGm2dA2dnSzeg_waeQ@mail.gmail.com>
	<CAFm4XO067GHWcREFhBQbpQeMVHd+8NgMcjnu-bqW7c7QiiFmuA@mail.gmail.com>
Message-ID: <CAFm4XO1n236hUW=Bmq0_8FL308dhdjpYnjKJr+5JDK1khMzrNQ@mail.gmail.com>

I found a couple more issues related to Byte Buddy which probably
should be fixed before we can make it the default.

I've solved the trivial ones, but there's one more problem which I
couldn't nail down yet: the testsuite is using a significant amount of
additional memory when all tests default to the Byte Buddy based
enhancer: the requirements are rocketing from about 150MB to 4GB.

A further complication is that for some reason Flight Recorder crashes
when connecting to the ORM testsuite; I've tried both versions coming
with JDK8 and JDK9 they both fail. I finally manged to get some
recordings from CLI tools so I hope to know more soon.

I also noticed that the support for
hibernate.bytecode.provider=bytebuddy was not documented; that might
explain some lack of feedback on such issues. Makes me think that
maybe this wasn't tested much yet?

Thanks,
Sanne


On 27 February 2018 at 11:13, Sanne Grinovero <sanne at hibernate.org> wrote:
> On 23 February 2018 at 20:29, Steve Ebersole <steve at hibernate.org> wrote:
>> You mean change to 5.3?  +1
>
> Right that's what I meant. Thanks, will do!
>
>>
>> On Fri, Feb 23, 2018 at 2:09 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>>
>>> HHH-11253 is about making ByteBuddy the default implementation, but
>>> it's flagged for 6.
>>>
>>> I think that in Paris there was consensus to make it the default in
>>> 5.3 alredy, to possibly drop Javassist entirely in 6.0.
>>>
>>> May I change this to 6 ? If that's ok, I can assign it to myself.
>>>
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Feb 28 09:13:07 2018
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 28 Feb 2018 14:13:07 +0000
Subject: [hibernate-dev] Byte-buddy: default enhancer in 5.3 ?
	[HHH-11253]
In-Reply-To: <CAFm4XO1n236hUW=Bmq0_8FL308dhdjpYnjKJr+5JDK1khMzrNQ@mail.gmail.com>
References: <CAFm4XO2FhuLz1AJ0oYQMPsbQpz4D5F7fh8195dhkZdY5SyVzHw@mail.gmail.com>
	<CAFdSV9tpkwoGn_sjywnfjxUBnOOPQDN_qGm2dA2dnSzeg_waeQ@mail.gmail.com>
	<CAFm4XO067GHWcREFhBQbpQeMVHd+8NgMcjnu-bqW7c7QiiFmuA@mail.gmail.com>
	<CAFm4XO1n236hUW=Bmq0_8FL308dhdjpYnjKJr+5JDK1khMzrNQ@mail.gmail.com>
Message-ID: <CAFdSV9uCYBVxm-zkNYY64Wbrh4wrboGNS6wWF3uP+_ZPHiOyqw@mail.gmail.com>

I see a few (like in 3 or 4) Jiras mentioning people using Byte Buddy for
enhancement, without Byte Buddy being the reason for the issue.  I cannot
speak to how widely used it is.

On Wed, Feb 28, 2018 at 7:10 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> I found a couple more issues related to Byte Buddy which probably
> should be fixed before we can make it the default.
>
> I've solved the trivial ones, but there's one more problem which I
> couldn't nail down yet: the testsuite is using a significant amount of
> additional memory when all tests default to the Byte Buddy based
> enhancer: the requirements are rocketing from about 150MB to 4GB.
>
> A further complication is that for some reason Flight Recorder crashes
> when connecting to the ORM testsuite; I've tried both versions coming
> with JDK8 and JDK9 they both fail. I finally manged to get some
> recordings from CLI tools so I hope to know more soon.
>
> I also noticed that the support for
> hibernate.bytecode.provider=bytebuddy was not documented; that might
> explain some lack of feedback on such issues. Makes me think that
> maybe this wasn't tested much yet?
>
> Thanks,
> Sanne
>
>
> On 27 February 2018 at 11:13, Sanne Grinovero <sanne at hibernate.org> wrote:
> > On 23 February 2018 at 20:29, Steve Ebersole <steve at hibernate.org>
> wrote:
> >> You mean change to 5.3?  +1
> >
> > Right that's what I meant. Thanks, will do!
> >
> >>
> >> On Fri, Feb 23, 2018 at 2:09 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>>
> >>> HHH-11253 is about making ByteBuddy the default implementation, but
> >>> it's flagged for 6.
> >>>
> >>> I think that in Paris there was consensus to make it the default in
> >>> 5.3 alredy, to possibly drop Javassist entirely in 6.0.
> >>>
> >>> May I change this to 6 ? If that's ok, I can assign it to myself.
> >>>
> >>> Thanks,
> >>> Sanne
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From paranoiabla at gmail.com  Wed Feb 28 14:11:46 2018
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 28 Feb 2018 21:11:46 +0200
Subject: [hibernate-dev] Null-Pointer Exception with 5.2.14
Message-ID: <CAKnbemXpaHxEPZ7rprC_N8kTJ5CMT7HOsz+bZzq8mcPQ+0e3sg@mail.gmail.com>

Hi guys,
I have this exception with latest 5.2.14 (my project runs fine with 5.2.13):

Caused by: javax.persistence.PersistenceException: [PersistenceUnit:
default] Unable to build Hibernate SessionFactory
    at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:970)
    at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:895)
    at
org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:57)
    at
org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:365)
    at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.buildNativeEntityManagerFactory(AbstractEntityManagerFactoryBean.java:387)
    at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:376)
    at
org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.afterPropertiesSet(LocalContainerEntityManagerFactoryBean.java:341)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1769)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1706)
    ... 32 more
Caused by: org.hibernate.MappingException: Could not instantiate persister
org.hibernate.persister.entity.SingleTableEntityPersister
    at
org.hibernate.persister.internal.PersisterFactoryImpl.createEntityPersister(PersisterFactoryImpl.java:112)
    at
org.hibernate.persister.internal.PersisterFactoryImpl.createEntityPersister(PersisterFactoryImpl.java:77)
    at
org.hibernate.metamodel.internal.MetamodelImpl.initialize(MetamodelImpl.java:128)
    at
org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:300)
    at
org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:460)
    at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:892)
    ... 39 more
Caused by: java.lang.NullPointerException
    at
org.hibernate.persister.entity.AbstractPropertyMapping.getSuperCollection(AbstractPropertyMapping.java:285)
    at
org.hibernate.persister.entity.AbstractPropertyMapping.addPropertyPath(AbstractPropertyMapping.java:198)
    at
org.hibernate.persister.entity.AbstractPropertyMapping.initPropertyPaths(AbstractPropertyMapping.java:395)
    at
org.hibernate.persister.entity.AbstractEntityPersister.initOrdinaryPropertyPaths(AbstractEntityPersister.java:2300)
    at
org.hibernate.persister.entity.AbstractEntityPersister.initPropertyPaths(AbstractEntityPersister.java:2347)
    at
org.hibernate.persister.entity.AbstractEntityPersister.postConstruct(AbstractEntityPersister.java:3906)
    at
org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:437)
    at sun.reflect.GeneratedConstructorAccessor94.newInstance(Unknown
Source)
    at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at
org.hibernate.persister.internal.PersisterFactoryImpl.createEntityPersister(PersisterFactoryImpl.java:96)
    ... 44 more





-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From christian.beikov at gmail.com  Wed Feb 28 14:52:21 2018
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 28 Feb 2018 20:52:21 +0100
Subject: [hibernate-dev] Null-Pointer Exception with 5.2.14
In-Reply-To: <CAKnbemXpaHxEPZ7rprC_N8kTJ5CMT7HOsz+bZzq8mcPQ+0e3sg@mail.gmail.com>
References: <CAKnbemXpaHxEPZ7rprC_N8kTJ5CMT7HOsz+bZzq8mcPQ+0e3sg@mail.gmail.com>
Message-ID: <cf7ab593-59ae-4c82-d859-acb0e40b650b@gmail.com>

Hey, I saw the comment on the issue. Thanks for reporting. Could you 
maybe post the model that causes this? I'd need to create a reproducer 
to be able to analyze this further.


Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 28.02.2018 um 20:11 schrieb Petar Tahchiev:
> Hi guys,
> I have this exception with latest 5.2.14 (my project runs fine with 5.2.13):
>
> Caused by: javax.persistence.PersistenceException: [PersistenceUnit:
> default] Unable to build Hibernate SessionFactory
>      at
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:970)
>      at
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:895)
>      at
> org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:57)
>      at
> org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:365)
>      at
> org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.buildNativeEntityManagerFactory(AbstractEntityManagerFactoryBean.java:387)
>      at
> org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:376)
>      at
> org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.afterPropertiesSet(LocalContainerEntityManagerFactoryBean.java:341)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1769)
>      at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1706)
>      ... 32 more
> Caused by: org.hibernate.MappingException: Could not instantiate persister
> org.hibernate.persister.entity.SingleTableEntityPersister
>      at
> org.hibernate.persister.internal.PersisterFactoryImpl.createEntityPersister(PersisterFactoryImpl.java:112)
>      at
> org.hibernate.persister.internal.PersisterFactoryImpl.createEntityPersister(PersisterFactoryImpl.java:77)
>      at
> org.hibernate.metamodel.internal.MetamodelImpl.initialize(MetamodelImpl.java:128)
>      at
> org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:300)
>      at
> org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:460)
>      at
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:892)
>      ... 39 more
> Caused by: java.lang.NullPointerException
>      at
> org.hibernate.persister.entity.AbstractPropertyMapping.getSuperCollection(AbstractPropertyMapping.java:285)
>      at
> org.hibernate.persister.entity.AbstractPropertyMapping.addPropertyPath(AbstractPropertyMapping.java:198)
>      at
> org.hibernate.persister.entity.AbstractPropertyMapping.initPropertyPaths(AbstractPropertyMapping.java:395)
>      at
> org.hibernate.persister.entity.AbstractEntityPersister.initOrdinaryPropertyPaths(AbstractEntityPersister.java:2300)
>      at
> org.hibernate.persister.entity.AbstractEntityPersister.initPropertyPaths(AbstractEntityPersister.java:2347)
>      at
> org.hibernate.persister.entity.AbstractEntityPersister.postConstruct(AbstractEntityPersister.java:3906)
>      at
> org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:437)
>      at sun.reflect.GeneratedConstructorAccessor94.newInstance(Unknown
> Source)
>      at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>      at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>      at
> org.hibernate.persister.internal.PersisterFactoryImpl.createEntityPersister(PersisterFactoryImpl.java:96)
>      ... 44 more
>
>
>
>
>