From sanne at hibernate.org  Fri Dec  2 11:26:38 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 2 Dec 2016 16:26:38 +0000
Subject: [hibernate-dev] AutoCloseable is great.. what about JPA?
Message-ID: <CAFm4XO2XD1vvskbta56g6dzUr1_Ljbg=r9bOdyZB9233VThyZA@mail.gmail.com>

We updated several Hibernate APIs to allow using the
try-with-resources pattern a while back,
and I've been finding that quite handy.

Had to write some code using JPA's EntityManager these days; in
contrast it feels it's stuck somewhere between the stone age and the
dark ages to not be able to do the same.

Should we propose the same API fixes to the JPA expert group?

Thanks,
Sanne

From sanne at hibernate.org  Fri Dec  2 11:42:35 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 2 Dec 2016 16:42:35 +0000
Subject: [hibernate-dev] AutoCloseable is great.. what about JPA?
In-Reply-To: <CAFm4XO2XD1vvskbta56g6dzUr1_Ljbg=r9bOdyZB9233VThyZA@mail.gmail.com>
References: <CAFm4XO2XD1vvskbta56g6dzUr1_Ljbg=r9bOdyZB9233VThyZA@mail.gmail.com>
Message-ID: <CAFm4XO2dYwBBQc15g3fOj82t5u_uTa02FUnA=rF6AZ0opz-aHg@mail.gmail.com>

Following up on myself, I found references on the expert group and the issue:
 - https://java.net/jira/browse/JPA_SPEC-77

It seems it's not being considered for JPA 2.2 as it would break
people on Java 6.

On 2 December 2016 at 16:26, Sanne Grinovero <sanne at hibernate.org> wrote:
> We updated several Hibernate APIs to allow using the
> try-with-resources pattern a while back,
> and I've been finding that quite handy.
>
> Had to write some code using JPA's EntityManager these days; in
> contrast it feels it's stuck somewhere between the stone age and the
> dark ages to not be able to do the same.
>
> Should we propose the same API fixes to the JPA expert group?
>
> Thanks,
> Sanne

From steve at hibernate.org  Fri Dec  2 11:48:26 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 02 Dec 2016 16:48:26 +0000
Subject: [hibernate-dev] AutoCloseable is great.. what about JPA?
In-Reply-To: <CAFm4XO2XD1vvskbta56g6dzUr1_Ljbg=r9bOdyZB9233VThyZA@mail.gmail.com>
References: <CAFm4XO2XD1vvskbta56g6dzUr1_Ljbg=r9bOdyZB9233VThyZA@mail.gmail.com>
Message-ID: <CAFdSV9uy-1z2xog9d-cmA7EWVzxC+t+BqwZrtpMTG5J4Y-3=sw@mail.gmail.com>

+1

we should start collecting a list.  And voila:
https://github.com/hibernate/hibernate-orm/wiki/Post-JPA-2.1-proposals-working-doc
 :)

On Fri, Dec 2, 2016 at 10:31 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> We updated several Hibernate APIs to allow using the
> try-with-resources pattern a while back,
> and I've been finding that quite handy.
>
> Had to write some code using JPA's EntityManager these days; in
> contrast it feels it's stuck somewhere between the stone age and the
> dark ages to not be able to do the same.
>
> Should we propose the same API fixes to the JPA expert group?
>
> 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  Fri Dec  2 11:49:32 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 02 Dec 2016 16:49:32 +0000
Subject: [hibernate-dev] AutoCloseable is great.. what about JPA?
In-Reply-To: <CAFdSV9uy-1z2xog9d-cmA7EWVzxC+t+BqwZrtpMTG5J4Y-3=sw@mail.gmail.com>
References: <CAFm4XO2XD1vvskbta56g6dzUr1_Ljbg=r9bOdyZB9233VThyZA@mail.gmail.com>
	<CAFdSV9uy-1z2xog9d-cmA7EWVzxC+t+BqwZrtpMTG5J4Y-3=sw@mail.gmail.com>
Message-ID: <CAFdSV9sJKoq6kWA9-OAm4HLQdazyC9WDJpV+wQ=MBf6aicgPWQ@mail.gmail.com>

But on Java 6 there is the hack we used to use.  Using Closeable instead
and Java 8 recognizing that as well.

On Fri, Dec 2, 2016 at 10:48 AM Steve Ebersole <steve at hibernate.org> wrote:

> +1
>
> we should start collecting a list.  And voila:
> https://github.com/hibernate/hibernate-orm/wiki/Post-JPA-2.1-proposals-working-doc
>  :)
>
> On Fri, Dec 2, 2016 at 10:31 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> We updated several Hibernate APIs to allow using the
> try-with-resources pattern a while back,
> and I've been finding that quite handy.
>
> Had to write some code using JPA's EntityManager these days; in
> contrast it feels it's stuck somewhere between the stone age and the
> dark ages to not be able to do the same.
>
> Should we propose the same API fixes to the JPA expert group?
>
> 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  Fri Dec  2 12:04:09 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 2 Dec 2016 17:04:09 +0000
Subject: [hibernate-dev] AutoCloseable is great.. what about JPA?
In-Reply-To: <CAFdSV9sJKoq6kWA9-OAm4HLQdazyC9WDJpV+wQ=MBf6aicgPWQ@mail.gmail.com>
References: <CAFm4XO2XD1vvskbta56g6dzUr1_Ljbg=r9bOdyZB9233VThyZA@mail.gmail.com>
	<CAFdSV9uy-1z2xog9d-cmA7EWVzxC+t+BqwZrtpMTG5J4Y-3=sw@mail.gmail.com>
	<CAFdSV9sJKoq6kWA9-OAm4HLQdazyC9WDJpV+wQ=MBf6aicgPWQ@mail.gmail.com>
Message-ID: <CAFm4XO2MoAP46_N1QwVO6ZuZd4G1xZDXxRBnya2-NxCb9-GPRA@mail.gmail.com>

On 2 December 2016 at 16:49, Steve Ebersole <steve at hibernate.org> wrote:
> But on Java 6 there is the hack we used to use.  Using Closeable instead and
> Java 8 recognizing that as well.

Right, I added that as comment on JPA_SPEC-77.

>
> On Fri, Dec 2, 2016 at 10:48 AM Steve Ebersole <steve at hibernate.org> wrote:
>>
>> +1
>>
>> we should start collecting a list.  And voila:
>> https://github.com/hibernate/hibernate-orm/wiki/Post-JPA-2.1-proposals-working-doc
>> :)
>>
>> On Fri, Dec 2, 2016 at 10:31 AM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>>
>>> We updated several Hibernate APIs to allow using the
>>> try-with-resources pattern a while back,
>>> and I've been finding that quite handy.
>>>
>>> Had to write some code using JPA's EntityManager these days; in
>>> contrast it feels it's stuck somewhere between the stone age and the
>>> dark ages to not be able to do the same.
>>>
>>> Should we propose the same API fixes to the JPA expert group?
>>>
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Fri Dec  2 12:06:48 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 2 Dec 2016 19:06:48 +0200
Subject: [hibernate-dev] AutoCloseable is great.. what about JPA?
In-Reply-To: <CAFdSV9sJKoq6kWA9-OAm4HLQdazyC9WDJpV+wQ=MBf6aicgPWQ@mail.gmail.com>
References: <CAFm4XO2XD1vvskbta56g6dzUr1_Ljbg=r9bOdyZB9233VThyZA@mail.gmail.com>
	<CAFdSV9uy-1z2xog9d-cmA7EWVzxC+t+BqwZrtpMTG5J4Y-3=sw@mail.gmail.com>
	<CAFdSV9sJKoq6kWA9-OAm4HLQdazyC9WDJpV+wQ=MBf6aicgPWQ@mail.gmail.com>
Message-ID: <CA+gWKMB_a4=yRnr-993pctjqnanU6L3ejgestyrtqu82BojS-g@mail.gmail.com>

That's a great idea. The only problem with the JPA EG is that there wasn't
any response to emails in months. We could at least create a JIRA issue for
this. My only concern is that the JPA Jira and other resources are hosted
on java.net which will be deactivated on April next year.

Vlad

On Fri, Dec 2, 2016 at 6:49 PM, Steve Ebersole <steve at hibernate.org> wrote:

> But on Java 6 there is the hack we used to use.  Using Closeable instead
> and Java 8 recognizing that as well.
>
> On Fri, Dec 2, 2016 at 10:48 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > +1
> >
> > we should start collecting a list.  And voila:
> > https://github.com/hibernate/hibernate-orm/wiki/Post-JPA-2.
> 1-proposals-working-doc
> >  :)
> >
> > On Fri, Dec 2, 2016 at 10:31 AM Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >
> > We updated several Hibernate APIs to allow using the
> > try-with-resources pattern a while back,
> > and I've been finding that quite handy.
> >
> > Had to write some code using JPA's EntityManager these days; in
> > contrast it feels it's stuck somewhere between the stone age and the
> > dark ages to not be able to do the same.
> >
> > Should we propose the same API fixes to the JPA expert group?
> >
> > 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 steve at hibernate.org  Fri Dec  2 12:10:26 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 02 Dec 2016 17:10:26 +0000
Subject: [hibernate-dev] AutoCloseable is great.. what about JPA?
In-Reply-To: <CA+gWKMB_a4=yRnr-993pctjqnanU6L3ejgestyrtqu82BojS-g@mail.gmail.com>
References: <CAFm4XO2XD1vvskbta56g6dzUr1_Ljbg=r9bOdyZB9233VThyZA@mail.gmail.com>
	<CAFdSV9uy-1z2xog9d-cmA7EWVzxC+t+BqwZrtpMTG5J4Y-3=sw@mail.gmail.com>
	<CAFdSV9sJKoq6kWA9-OAm4HLQdazyC9WDJpV+wQ=MBf6aicgPWQ@mail.gmail.com>
	<CA+gWKMB_a4=yRnr-993pctjqnanU6L3ejgestyrtqu82BojS-g@mail.gmail.com>
Message-ID: <CAFdSV9tawpL15SvJNwihCwPg8ZA-gBpf3Zz0NgKNOQHaXsGtnQ@mail.gmail.com>

They will, and the spec group has had mentions of that happening and no
response from the EG chair.  We should offer a project on our Jira! ;)


On Fri, Dec 2, 2016 at 11:06 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> That's a great idea. The only problem with the JPA EG is that there wasn't
> any response to emails in months. We could at least create a JIRA issue for
> this. My only concern is that the JPA Jira and other resources are hosted
> on java.net which will be deactivated on April next year.
>
> Vlad
>
> On Fri, Dec 2, 2016 at 6:49 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> But on Java 6 there is the hack we used to use.  Using Closeable instead
> and Java 8 recognizing that as well.
>
> On Fri, Dec 2, 2016 at 10:48 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > +1
> >
> > we should start collecting a list.  And voila:
> >
> https://github.com/hibernate/hibernate-orm/wiki/Post-JPA-2.1-proposals-working-doc
> >  :)
> >
> > On Fri, Dec 2, 2016 at 10:31 AM Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >
> > We updated several Hibernate APIs to allow using the
> > try-with-resources pattern a while back,
> > and I've been finding that quite handy.
> >
> > Had to write some code using JPA's EntityManager these days; in
> > contrast it feels it's stuck somewhere between the stone age and the
> > dark ages to not be able to do the same.
> >
> > Should we propose the same API fixes to the JPA expert group?
> >
> > 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 mihalcea.vlad at gmail.com  Fri Dec  2 12:16:17 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 2 Dec 2016 19:16:17 +0200
Subject: [hibernate-dev] AutoCloseable is great.. what about JPA?
In-Reply-To: <CAFdSV9tawpL15SvJNwihCwPg8ZA-gBpf3Zz0NgKNOQHaXsGtnQ@mail.gmail.com>
References: <CAFm4XO2XD1vvskbta56g6dzUr1_Ljbg=r9bOdyZB9233VThyZA@mail.gmail.com>
	<CAFdSV9uy-1z2xog9d-cmA7EWVzxC+t+BqwZrtpMTG5J4Y-3=sw@mail.gmail.com>
	<CAFdSV9sJKoq6kWA9-OAm4HLQdazyC9WDJpV+wQ=MBf6aicgPWQ@mail.gmail.com>
	<CA+gWKMB_a4=yRnr-993pctjqnanU6L3ejgestyrtqu82BojS-g@mail.gmail.com>
	<CAFdSV9tawpL15SvJNwihCwPg8ZA-gBpf3Zz0NgKNOQHaXsGtnQ@mail.gmail.com>
Message-ID: <CA+gWKMBPVXgoO_Xq14pjXs+NHF1__v+JjOQcXa_wkEL7AyvK5A@mail.gmail.com>

If we can do that, it would be just awesome.

On Fri, Dec 2, 2016 at 7:10 PM, Steve Ebersole <steve at hibernate.org> wrote:

> They will, and the spec group has had mentions of that happening and no
> response from the EG chair.  We should offer a project on our Jira! ;)
>
>
> On Fri, Dec 2, 2016 at 11:06 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> That's a great idea. The only problem with the JPA EG is that there
>> wasn't any response to emails in months. We could at least create a JIRA
>> issue for this. My only concern is that the JPA Jira and other resources
>> are hosted on java.net which will be deactivated on April next year.
>>
>> Vlad
>>
>> On Fri, Dec 2, 2016 at 6:49 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>> But on Java 6 there is the hack we used to use.  Using Closeable instead
>> and Java 8 recognizing that as well.
>>
>> On Fri, Dec 2, 2016 at 10:48 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>> > +1
>> >
>> > we should start collecting a list.  And voila:
>> > https://github.com/hibernate/hibernate-orm/wiki/Post-JPA-2.
>> 1-proposals-working-doc
>> >  :)
>> >
>> > On Fri, Dec 2, 2016 at 10:31 AM Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >
>> > We updated several Hibernate APIs to allow using the
>> > try-with-resources pattern a while back,
>> > and I've been finding that quite handy.
>> >
>> > Had to write some code using JPA's EntityManager these days; in
>> > contrast it feels it's stuck somewhere between the stone age and the
>> > dark ages to not be able to do the same.
>> >
>> > Should we propose the same API fixes to the JPA expert group?
>> >
>> > 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 coladict at gmail.com  Fri Dec  2 12:40:34 2016
From: coladict at gmail.com (Jordan Gigov)
Date: Fri, 2 Dec 2016 19:40:34 +0200
Subject: [hibernate-dev] AutoCloseable is great.. what about JPA?
In-Reply-To: <CA+gWKMBPVXgoO_Xq14pjXs+NHF1__v+JjOQcXa_wkEL7AyvK5A@mail.gmail.com>
References: <CAFm4XO2XD1vvskbta56g6dzUr1_Ljbg=r9bOdyZB9233VThyZA@mail.gmail.com>
	<CAFdSV9uy-1z2xog9d-cmA7EWVzxC+t+BqwZrtpMTG5J4Y-3=sw@mail.gmail.com>
	<CAFdSV9sJKoq6kWA9-OAm4HLQdazyC9WDJpV+wQ=MBf6aicgPWQ@mail.gmail.com>
	<CA+gWKMB_a4=yRnr-993pctjqnanU6L3ejgestyrtqu82BojS-g@mail.gmail.com>
	<CAFdSV9tawpL15SvJNwihCwPg8ZA-gBpf3Zz0NgKNOQHaXsGtnQ@mail.gmail.com>
	<CA+gWKMBPVXgoO_Xq14pjXs+NHF1__v+JjOQcXa_wkEL7AyvK5A@mail.gmail.com>
Message-ID: <CA+nBocAYg6GNjDZDTqbtgC+OW+bBiLp3fyY6RL0doyzAB2WR=w@mail.gmail.com>

One thing I think JPA is lacking is the ability to map read-only result classes,
without annotating them as @Entity and making the provider expect
table for them.
ConstructorResult is a pretty hacky way of getting there and loses some of the
benefits like lazy loading collections and in Hibernate's case query caching.

From christian.beikov at gmail.com  Sat Dec  3 03:04:08 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Sat, 3 Dec 2016 09:04:08 +0100
Subject: [hibernate-dev] AutoCloseable is great.. what about JPA?
In-Reply-To: <CA+nBocAYg6GNjDZDTqbtgC+OW+bBiLp3fyY6RL0doyzAB2WR=w@mail.gmail.com>
References: <CAFm4XO2XD1vvskbta56g6dzUr1_Ljbg=r9bOdyZB9233VThyZA@mail.gmail.com>
	<CAFdSV9uy-1z2xog9d-cmA7EWVzxC+t+BqwZrtpMTG5J4Y-3=sw@mail.gmail.com>
	<CAFdSV9sJKoq6kWA9-OAm4HLQdazyC9WDJpV+wQ=MBf6aicgPWQ@mail.gmail.com>
	<CA+gWKMB_a4=yRnr-993pctjqnanU6L3ejgestyrtqu82BojS-g@mail.gmail.com>
	<CAFdSV9tawpL15SvJNwihCwPg8ZA-gBpf3Zz0NgKNOQHaXsGtnQ@mail.gmail.com>
	<CA+gWKMBPVXgoO_Xq14pjXs+NHF1__v+JjOQcXa_wkEL7AyvK5A@mail.gmail.com>
	<CA+nBocAYg6GNjDZDTqbtgC+OW+bBiLp3fyY6RL0doyzAB2WR=w@mail.gmail.com>
Message-ID: <d057350f-da05-61eb-8a04-ae3e8a66c3b0@gmail.com>

Hey Jordan,

maybe what you are looking for is Blaze-Persistence Entity Views? 
https://github.com/Blazebit/blaze-persistence#entity-view-usage
Query caching should work since it builds on top of scalar queries, but 
lazy loading is something I don't support and honestly don't think will 
support.

Regards,
Christian

Am 02.12.2016 um 18:40 schrieb Jordan Gigov:
> One thing I think JPA is lacking is the ability to map read-only result classes,
> without annotating them as @Entity and making the provider expect
> table for them.
> ConstructorResult is a pretty hacky way of getting there and loses some of the
> benefits like lazy loading collections and in Hibernate's case query caching.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Sat Dec  3 09:32:24 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 03 Dec 2016 14:32:24 +0000
Subject: [hibernate-dev] AutoCloseable is great.. what about JPA?
In-Reply-To: <d057350f-da05-61eb-8a04-ae3e8a66c3b0@gmail.com>
References: <CAFm4XO2XD1vvskbta56g6dzUr1_Ljbg=r9bOdyZB9233VThyZA@mail.gmail.com>
	<CAFdSV9uy-1z2xog9d-cmA7EWVzxC+t+BqwZrtpMTG5J4Y-3=sw@mail.gmail.com>
	<CAFdSV9sJKoq6kWA9-OAm4HLQdazyC9WDJpV+wQ=MBf6aicgPWQ@mail.gmail.com>
	<CA+gWKMB_a4=yRnr-993pctjqnanU6L3ejgestyrtqu82BojS-g@mail.gmail.com>
	<CAFdSV9tawpL15SvJNwihCwPg8ZA-gBpf3Zz0NgKNOQHaXsGtnQ@mail.gmail.com>
	<CA+gWKMBPVXgoO_Xq14pjXs+NHF1__v+JjOQcXa_wkEL7AyvK5A@mail.gmail.com>
	<CA+nBocAYg6GNjDZDTqbtgC+OW+bBiLp3fyY6RL0doyzAB2WR=w@mail.gmail.com>
	<d057350f-da05-61eb-8a04-ae3e8a66c3b0@gmail.com>
Message-ID: <CAFdSV9tQzGDRitAowfF1VtZv-kRy+rXXfeF1U5DhrHBxWaD4NQ@mail.gmail.com>

Personally I don't think dynamic-instantiations  (ConstructorResults) are
hacky at all.  In fact I love dynamic-instantiations for all kinds of use
cases.  I wonder if your concern with them is their limited capabilities.

For example, JPA does not define support for nesting dynamic-instantiations
or the ability to use setter injection (both of which I have already
implemented for 6.0 btw).  Otherwise we'd need to understand more exactly
what you are talking about.

On Sat, Dec 3, 2016, 2:07 AM Christian Beikov <christian.beikov at gmail.com>
wrote:

> Hey Jordan,
>
> maybe what you are looking for is Blaze-Persistence Entity Views?
> https://github.com/Blazebit/blaze-persistence#entity-view-usage
> Query caching should work since it builds on top of scalar queries, but
> lazy loading is something I don't support and honestly don't think will
> support.
>
> Regards,
> Christian
>
> Am 02.12.2016 um 18:40 schrieb Jordan Gigov:
> > One thing I think JPA is lacking is the ability to map read-only result
> classes,
> > without annotating them as @Entity and making the provider expect
> > table for them.
> > ConstructorResult is a pretty hacky way of getting there and loses some
> of the
> > benefits like lazy loading collections and in Hibernate's case query
> caching.
> > _______________________________________________
> > 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 chris at hibernate.org  Mon Dec  5 09:26:47 2016
From: chris at hibernate.org (Chris Cranford)
Date: Mon, 5 Dec 2016 09:26:47 -0500
Subject: [hibernate-dev] RH Summit 2017 CFP
In-Reply-To: <CA+gWKMD6bbTr7PWNmpr7RFO4eu0XXM7A3Ugsa3w9S_9XXtRyPw@mail.gmail.com>
References: <43d9408d-fc47-2967-89e5-4692696bdbcf@hibernate.org>
	<CA+gWKMD6bbTr7PWNmpr7RFO4eu0XXM7A3Ugsa3w9S_9XXtRyPw@mail.gmail.com>
Message-ID: <c234f301-1d30-bbde-7b37-77e35ea92a9d@hibernate.org>

Vlad -

Do we have anyone who would like to present the talk?

Chris


On 11/28/2016 09:43 AM, Vlad Mihalcea wrote:
> Hi,
>
> I've talked to Steve about this topic, and I remember that we 
> concluded that we should send a presentation proposal on the following 
> two topics:
>
> - What's new in Hibernate 6.0
> - Hibernate Performance Tuning Tips
>
> Vlad
>
> On Mon, Nov 28, 2016 at 4:40 PM, Chris Cranford <chris at hibernate.org 
> <mailto:chris at hibernate.org>> wrote:
>
>     The Red Hat Summit 2017 CFP is closing on December 16th and I would
>     recommend we try and submit our abstracts this week if we could. 
>      From
>     the ORM side, is there any particular topics we'd care to present or
>     anyone who would like to present?
>
>     Chris
>
>     _______________________________________________
>     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
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>


From koen.aers at gmail.com  Tue Dec  6 13:47:49 2016
From: koen.aers at gmail.com (Koen Aers)
Date: Tue, 6 Dec 2016 19:47:49 +0100
Subject: [hibernate-dev] RH Summit 2017 CFP
In-Reply-To: <c234f301-1d30-bbde-7b37-77e35ea92a9d@hibernate.org>
References: <43d9408d-fc47-2967-89e5-4692696bdbcf@hibernate.org>
	<CA+gWKMD6bbTr7PWNmpr7RFO4eu0XXM7A3Ugsa3w9S_9XXtRyPw@mail.gmail.com>
	<c234f301-1d30-bbde-7b37-77e35ea92a9d@hibernate.org>
Message-ID: <CF2C0049-63C4-4EFC-BA2C-0AB0E7FFBAC9@hibernate.org>

If nobody more knowledgeable then me is found then I can do it. 

In any case, I am also interested in submitting these topics to local events. Can I find the abstracts somewhere?

Cheers,
Koen


> Op 5 dec. 2016, om 15:26 heeft Chris Cranford <chris at hibernate.org> het volgende geschreven:
> 
> Vlad -
> 
> Do we have anyone who would like to present the talk?
> 
> Chris
> 
> 
> On 11/28/2016 09:43 AM, Vlad Mihalcea wrote:
>> Hi,
>> 
>> I've talked to Steve about this topic, and I remember that we 
>> concluded that we should send a presentation proposal on the following 
>> two topics:
>> 
>> - What's new in Hibernate 6.0
>> - Hibernate Performance Tuning Tips
>> 
>> Vlad
>> 
>> On Mon, Nov 28, 2016 at 4:40 PM, Chris Cranford <chris at hibernate.org 
>> <mailto:chris at hibernate.org>> wrote:
>> 
>>    The Red Hat Summit 2017 CFP is closing on December 16th and I would
>>    recommend we try and submit our abstracts this week if we could. 
>>     From
>>    the ORM side, is there any particular topics we'd care to present or
>>    anyone who would like to present?
>> 
>>    Chris
>> 
>>    _______________________________________________
>>    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
>>    <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  Thu Dec  8 07:23:22 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 8 Dec 2016 13:23:22 +0100
Subject: [hibernate-dev] Hibernate Validator 5.4.0.Beta1 and 5.3.4.Final
	released
Message-ID: <CADGJaX-CZEfh9r1QFmnAkbSuRVHhK15eyVvnzObw-Ru0NP+Kqw@mail.gmail.com>

Hi,

It's my pleasure to announce two new releases of Hibernate Validator.

The first Beta of 5.4 brings support for javax.money, many new checks for
the HV annotation processor, a patch file for easily upgrading HV within
WildFly 10 and much more.

5.3.4 is a bug fix release for our current stable branch; it's a
recommended update for all users.

Please check out the announcement post [1] for all the details.

--Gunnar

[1]
http://in.relation.to/2016/12/08/hibernate-validator-540-beta1-and-534-final-out/

From davide at hibernate.org  Fri Dec  9 08:40:06 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Fri, 9 Dec 2016 13:40:06 +0000
Subject: [hibernate-dev] Update JDK 9 on ci.hibernate.org: JDK 9 build 148
Message-ID: <CANoTJYOjfavD-qaXWZ4oP+fGjGJHw8LHsHf7tyjKe6Ddj4=nxA@mail.gmail.com>

Hi,
I just wanted to inform that I've updated the JDK 9 version on CI to build 148.

Let me know if there are problems.

Cheers,
Davide

From steve at hibernate.org  Fri Dec  9 09:02:36 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 09 Dec 2016 14:02:36 +0000
Subject: [hibernate-dev] Update JDK 9 on ci.hibernate.org: JDK 9 build
	148
In-Reply-To: <CANoTJYOjfavD-qaXWZ4oP+fGjGJHw8LHsHf7tyjKe6Ddj4=nxA@mail.gmail.com>
References: <CANoTJYOjfavD-qaXWZ4oP+fGjGJHw8LHsHf7tyjKe6Ddj4=nxA@mail.gmail.com>
Message-ID: <CAFdSV9tDJH5F2SqBwvx4BNQe7Fk80KrLdqZWa7XKHgjOKfkEfA@mail.gmail.com>

Is this the build with the "disruptive change"?


On Fri, Dec 9, 2016, 7:43 AM Davide D'Alto <davide at hibernate.org> wrote:

Hi,
I just wanted to inform that I've updated the JDK 9 version on CI to build
148.

Let me know if there are problems.

Cheers,
Davide
_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Fri Dec  9 09:19:36 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 9 Dec 2016 14:19:36 +0000
Subject: [hibernate-dev] Update JDK 9 on ci.hibernate.org: JDK 9 build
	148
In-Reply-To: <CAFdSV9tDJH5F2SqBwvx4BNQe7Fk80KrLdqZWa7XKHgjOKfkEfA@mail.gmail.com>
References: <CANoTJYOjfavD-qaXWZ4oP+fGjGJHw8LHsHf7tyjKe6Ddj4=nxA@mail.gmail.com>
	<CAFdSV9tDJH5F2SqBwvx4BNQe7Fk80KrLdqZWa7XKHgjOKfkEfA@mail.gmail.com>
Message-ID: <CAFm4XO1aAVi8NnfkZK2krPTs2077SY0wTcpebqdSfun7AbnkZA@mail.gmail.com>

Yes! It broke some Byteman tests in Search already; might simply need
some different JVM switches, but I'll look at this next week.

Pasting Rory O'Donnell's email:
========================

JDK 9 build b148 includes an important Refresh of the module system
[1] , summary of  changes are listed here .

This refresh includes a disruptive change that is important to understand.

For those that have been trying out modules with regular JDK 9 builds
then be aware that `requires public` changes to `requires transitive`.
In addition, the binary representation of the module declaration
(module-info.class) has changed so that you need to recompile any
modules that were compiled with previous JDK 9 builds.

As things stand today in JDK 9 then you use setAccessible to break
into non-public elements of any type in exported packages. However, it
cannot be used to break into any type in non-exported package. The
current specified behavior was a compromise for the initial
integration of the module system. It is of course not very
satisfactory, hence the #AwkwardStrongEncapsulation issue [2] on the
JSR 376 issues list. With the updated proposal in the JSR, this
refresh changes setAccessible further so that it cannot be used to
break into non-public types, or non-public elements of public types,
in exported packages. Code that uses setAccessible to hack into the
private constructor of java.lang.invoke.MethodHandles.Lookup will be
disappointed for example.

This change will expose hacks in many existing libraries and tools. As
a workaround then a new command line option `--add-opens` can be used
to open specific packages for "deep reflection". For example, a really
popular build tool fails with this refresh because it uses
setAccessible + core reflection to hack into a private field of an
unmodifiable collection so that it can mutate it, facepalm! This code
will continue to work as before when run with `--add-opens
java.base/java.util=ALL-UNNAMED` to open the package java.util in
module java.base to "all unnamed modules" (think class path).

Any help reporting issues to popular tools and libraries would be appreciated.

A debugging aid that is useful to identify issues is to run with
-Dsun.reflect.debugModuleAccessChecks=true to get a stack trace when
setAccessible fails, this is particularly useful when code swallows
exceptions without any logging.


Rgds,Rory


[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-November/005276.html
[2] http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsulation

On 9 December 2016 at 14:02, Steve Ebersole <steve at hibernate.org> wrote:
> Is this the build with the "disruptive change"?
>
>
> On Fri, Dec 9, 2016, 7:43 AM Davide D'Alto <davide at hibernate.org> wrote:
>
> Hi,
> I just wanted to inform that I've updated the JDK 9 version on CI to build
> 148.
>
> Let me know if there are problems.
>
> Cheers,
> Davide
> _______________________________________________
> 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  Fri Dec  9 09:21:48 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 9 Dec 2016 15:21:48 +0100
Subject: [hibernate-dev] Update JDK 9 on ci.hibernate.org: JDK 9 build
	148
In-Reply-To: <CAFdSV9tDJH5F2SqBwvx4BNQe7Fk80KrLdqZWa7XKHgjOKfkEfA@mail.gmail.com>
References: <CANoTJYOjfavD-qaXWZ4oP+fGjGJHw8LHsHf7tyjKe6Ddj4=nxA@mail.gmail.com>
	<CAFdSV9tDJH5F2SqBwvx4BNQe7Fk80KrLdqZWa7XKHgjOKfkEfA@mail.gmail.com>
Message-ID: <CADGJaX-Q=2ioTO_HwR5smQW4KRQS=KsORMOVqpYPzi_qzkyzfw@mail.gmail.com>

It's the one described here:
http://lists.jboss.org/pipermail/wildfly-dev/2016-December/005606.html


2016-12-09 15:02 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> Is this the build with the "disruptive change"?
>
>
> On Fri, Dec 9, 2016, 7:43 AM Davide D'Alto <davide at hibernate.org> wrote:
>
> Hi,
> I just wanted to inform that I've updated the JDK 9 version on CI to build
> 148.
>
> Let me know if there are problems.
>
> Cheers,
> Davide
> _______________________________________________
> 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 rory.odonnell at oracle.com  Fri Dec  9 09:43:20 2016
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 9 Dec 2016 14:43:20 +0000
Subject: [hibernate-dev] JDK 9 b148 including a refresh of the module system
 is available on java.net
Message-ID: <a5442efc-2bec-2def-d1f4-a468abed9b13@oracle.com>


Hi Sanne,

As requested, I will send availability emails to hibernate-dev mailing 
list in future.

JDK 9 build b148 <https://jdk9.java.net/download/> includes an important 
Refresh of the module system [1] , summary of changes are listed here 
<http://download.java.net/java/jdk9/changes/jdk-9+148.html>.

*This refresh includes a disruptive change that is important to understand.

*For those that have been trying out modules with regular JDK 9 builds 
then be aware that `requires public` changes to `requires transitive`. 
In addition, the binary representation of the module declaration 
(module-info.class) has changed so that you need to recompile any 
modules that were compiled with previous JDK 9 builds.

As things stand today in JDK 9 then you use setAccessible to break into 
non-public elements of any type in exported packages. However, it cannot 
be used to break into any type in non-exported package. The current 
specified behavior was a compromise for the initial integration of the 
module system. It is of course not very satisfactory, hence the 
#AwkwardStrongEncapsulation issue [2] on the JSR 376 issues list. With 
the updated proposal in the JSR, this refresh changes setAccessible 
further so that it cannot be used to break into non-public types, or 
non-public elements of public types, in exported packages. Code that 
uses setAccessible to hack into the private constructor of 
java.lang.invoke.MethodHandles.Lookup will be disappointed for example.

This change will expose hacks in many existing libraries and tools. As a 
workaround then a new command line option `--add-opens` can be used to 
open specific packages for "deep reflection". For example, a really 
popular build tool fails with this refresh because it uses setAccessible 
+ core reflection to hack into a private field of an unmodifiable 
collection so that it can mutate it, facepalm! This code will continue 
to work as before when run with `--add-opens 
java.base/java.util=ALL-UNNAMED` to open the package java.util in module 
java.base to "all unnamed modules" (think class path).

*Any help reporting issues to popular tools and libraries would be 
appreciated. *

A debugging aid that is useful to identify issues is to run with 
-Dsun.reflect.debugModuleAccessChecks=true to get a stack trace when 
setAccessible fails, this is particularly useful when code swallows 
exceptions without any logging.


Rgds,Rory


[1] 
http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-November/005276.html 
<http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html>
[2] 
http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsulation

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


From yoann at hibernate.org  Tue Dec 13 03:26:57 2016
From: yoann at hibernate.org (Yoann Rodiere)
Date: Tue, 13 Dec 2016 09:26:57 +0100
Subject: [hibernate-dev] [SEARCH] Translating analyzer definitions from
	HSearch to Elasticsearch
Message-ID: <CAEqagpr2=2pEdck5W5ZbuSGbpO_a7+yFYMtvMwr+Rv=uP+xa-w@mail.gmail.com>

Hello everyone,

I'm currently working on HSEARCH-2219, "Define analyzers via the REST API",
whose purpose is to automatically translate @AnalyzerDefs in Hibernate
Search to settings in Elasticsearch, removing the need for users to
configure analyzers separately in their Elasticsearch instance.

The thing is, the structure of our configuration in Hibernate Search is
different from the one in Elasticsearch. In particular, we can't name
instances of token filters, char filters, etc, while in Elasticsearch one
*has* to name them in order to provide parameters.

See for instance:

@AnalyzerDef(
  name = "myAnalyzer",
  tokenizer = @TokenizerDef(
    factory = StandardTokenizerFactory.class,
    parameters = @Parameters(@Parameter(name = "maxTokenLength", value =
"900"))
  )
)

compared to the Elasticsearch way:

index :
    analysis :
        analyzer :
            myAnalyzer :
                type : custom
                tokenizer : myTokenizer1
        tokenizer :
            myTokenizer1 :
                type : standard
                max_token_length : 900

The analyzer name is there on both sides, @TokenizerDef.factory would give
me the tokenizer type, and parameters are pretty obvious too. But
"myTokenizer1", the tokenizer name, has absolutely no equivalent in
Hibernate Search.

I could try to generate names automatically, but those would need to be
more or less stable across multiple executions in order for schema
validation to work properly. And there's nothing we could really use as an
identifier in our annotations, at least not reliably.

To fill the gap, I'd like to add a "name" attribute to the TokenizerDef,
CharFilterDef and TokenFilterDef annotations. This attribute would be
optional and the documentation would mention that it's useless for embedded
Lucene.

Another solution would be to have a "magic" @Parameter, named after a
constant (ElasticsearchParameters.TOKENIZER_NAME for instance), and detect
that parameter automatically, but it feels wrong... mainly because
@AnalyzerDef already has its own "name" attribute, so why wouldn't
@TokenizerDef?

And finally, we could bring our annotations closer to the Elasticsearch
way, by providing a way to define tokenizers/char filters/token filters and
a separate way to reference those definitions, but I don't think that's 5.6
material, since we'd likely have to break things or lose consistency.

WDYT?

Yoann Rodi?re <yoann at hibernate.org>
Hibernate NoORM Team

From sanne at hibernate.org  Tue Dec 13 09:12:34 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 13 Dec 2016 14:12:34 +0000
Subject: [hibernate-dev] [SEARCH] Translating analyzer definitions from
 HSearch to Elasticsearch
In-Reply-To: <CAEqagpr2=2pEdck5W5ZbuSGbpO_a7+yFYMtvMwr+Rv=uP+xa-w@mail.gmail.com>
References: <CAEqagpr2=2pEdck5W5ZbuSGbpO_a7+yFYMtvMwr+Rv=uP+xa-w@mail.gmail.com>
Message-ID: <CAFm4XO2hH4ME2VpgzPtrMN8hryAvr_fuSC0cvo=srKPqO7aJ9w@mail.gmail.com>

Adding a "name" attribute to the @TokenizerDef annotation seems like a
good idea.

Make it an optional attribute of course, we can throw an exception if
it's missing and ES is being used, while maintaining compatibility
with existing apps using Lucene.
Perhaps you could be slightly forgiving in certain situations - I
guess you could use the fully qualified classname for example when
it's used only once - but your choice to see if that little benefit is
a worthy trade-off to implement.

Rather than documenting that this is useless for Lucene, we might even
take advantage of that (eventually) for some diagnostics messages /
tooling / debugging?
Not suggesting you do that now, just justifying that the "name"
attribute isn't entirely out of scope even for the Lucene embedded
case.

+1 to defer separating the filter chains into named, reusable
components: that can wait.

Thanks,
Sanne


On 13 December 2016 at 08:26, Yoann Rodiere <yoann at hibernate.org> wrote:
> Hello everyone,
>
> I'm currently working on HSEARCH-2219, "Define analyzers via the REST API",
> whose purpose is to automatically translate @AnalyzerDefs in Hibernate
> Search to settings in Elasticsearch, removing the need for users to
> configure analyzers separately in their Elasticsearch instance.
>
> The thing is, the structure of our configuration in Hibernate Search is
> different from the one in Elasticsearch. In particular, we can't name
> instances of token filters, char filters, etc, while in Elasticsearch one
> *has* to name them in order to provide parameters.
>
> See for instance:
>
> @AnalyzerDef(
>   name = "myAnalyzer",
>   tokenizer = @TokenizerDef(
>     factory = StandardTokenizerFactory.class,
>     parameters = @Parameters(@Parameter(name = "maxTokenLength", value =
> "900"))
>   )
> )
>
> compared to the Elasticsearch way:
>
> index :
>     analysis :
>         analyzer :
>             myAnalyzer :
>                 type : custom
>                 tokenizer : myTokenizer1
>         tokenizer :
>             myTokenizer1 :
>                 type : standard
>                 max_token_length : 900
>
> The analyzer name is there on both sides, @TokenizerDef.factory would give
> me the tokenizer type, and parameters are pretty obvious too. But
> "myTokenizer1", the tokenizer name, has absolutely no equivalent in
> Hibernate Search.
>
> I could try to generate names automatically, but those would need to be
> more or less stable across multiple executions in order for schema
> validation to work properly. And there's nothing we could really use as an
> identifier in our annotations, at least not reliably.
>
> To fill the gap, I'd like to add a "name" attribute to the TokenizerDef,
> CharFilterDef and TokenFilterDef annotations. This attribute would be
> optional and the documentation would mention that it's useless for embedded
> Lucene.
>
> Another solution would be to have a "magic" @Parameter, named after a
> constant (ElasticsearchParameters.TOKENIZER_NAME for instance), and detect
> that parameter automatically, but it feels wrong... mainly because
> @AnalyzerDef already has its own "name" attribute, so why wouldn't
> @TokenizerDef?
>
> And finally, we could bring our annotations closer to the Elasticsearch
> way, by providing a way to define tokenizers/char filters/token filters and
> a separate way to reference those definitions, but I don't think that's 5.6
> material, since we'd likely have to break things or lose consistency.
>
> WDYT?
>
> Yoann Rodi?re <yoann at hibernate.org>
> Hibernate NoORM Team
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From rvansa at redhat.com  Tue Dec 13 12:20:54 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Tue, 13 Dec 2016 18:20:54 +0100
Subject: [hibernate-dev] Testing DB lock timeouts
Message-ID: <75b00a3b-eaca-6433-6853-6c42974ae29b@redhat.com>

Hi,

since hibernate-infinispan testsuite has been set on by default, 
recently I've set myself to improve the execution time which is several 
minutes due to various sleeps and timeouts.

Many of the tests test concurrency issues, and that often involves 
issuing two writes to single table/row in DB. In H2, this results in 
waiting 10 seconds (as configured default lock timeout), and since the 
tests are executed sequentially, the testsuite takes much longer than it 
should.

Obvious workaround is reducing this timeout to, say, 100 ms, but this 
could lead to a) false positives and b) those 100 ms add up and with 
over thousand of tests (for various configurations), this could be 
minutes anyway.

Q: is there any infrastructure in testsuite to hook into the DB, assert 
that it's waiting in lock and let the thread time out if everything is 
as expected?

Radim

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


From steve at hibernate.org  Tue Dec 13 13:55:09 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 13 Dec 2016 18:55:09 +0000
Subject: [hibernate-dev] Testing DB lock timeouts
In-Reply-To: <75b00a3b-eaca-6433-6853-6c42974ae29b@redhat.com>
References: <75b00a3b-eaca-6433-6853-6c42974ae29b@redhat.com>
Message-ID: <CAFdSV9u13L3-L3TZpS8jyZcWKJZBsbNsEjvKQJf80C+voNvi6w@mail.gmail.com>

ConnectionProvider mocking the Connection?

To help there is org.hibernate.testing.jdbc.JdbcMocks


On Tue, Dec 13, 2016 at 11:23 AM Radim Vansa <rvansa at redhat.com> wrote:

> Hi,
>
> since hibernate-infinispan testsuite has been set on by default,
> recently I've set myself to improve the execution time which is several
> minutes due to various sleeps and timeouts.
>
> Many of the tests test concurrency issues, and that often involves
> issuing two writes to single table/row in DB. In H2, this results in
> waiting 10 seconds (as configured default lock timeout), and since the
> tests are executed sequentially, the testsuite takes much longer than it
> should.
>
> Obvious workaround is reducing this timeout to, say, 100 ms, but this
> could lead to a) false positives and b) those 100 ms add up and with
> over thousand of tests (for various configurations), this could be
> minutes anyway.
>
> Q: is there any infrastructure in testsuite to hook into the DB, assert
> that it's waiting in lock and let the thread time out if everything is
> as expected?
>
> Radim
>
> --
> 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
>

From sanne at hibernate.org  Thu Dec 15 10:18:13 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 15 Dec 2016 15:18:13 +0000
Subject: [hibernate-dev] Jenkins build became unstable:
	hibernate-search-master-mariadb #244
In-Reply-To: <CAAV25CHHDbw2drbO9fgBa-q2EjATVrWopsh903rnP5PpiDL-Rw@mail.gmail.com>
References: <725560922.26.1481813923616.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
	<CAAV25CHHDbw2drbO9fgBa-q2EjATVrWopsh903rnP5PpiDL-Rw@mail.gmail.com>
Message-ID: <CAFm4XO1P=fDgHpcy94bobQPPiCfrUEQBgy4tzoGGfcL2bcRKKQ@mail.gmail.com>

mysteries of Maven .. it sometimes reports SUCCESS, yet you have to
scroll into the logs to find the error.

I wonder if there's something off in our pom files: it's the the first
time it happens.

=========

Results :

Tests in error:
  SearchNewEntityJmsMasterSlaveIT>MasterSlaveTestTemplate.deleteExistingMembers:55
? EJBTransactionRolledback

Tests run: 64, Failures: 0, Errors: 1, Skipped: 0

==========



On 15 December 2016 at 15:00, Gustavo Fernandes <gustavonalle at gmail.com> wrote:
> I can see BUILD SUCCESS in the logs, what happened?
>
> On Thu, Dec 15, 2016 at 2:58 PM, Hibernate CI <ci at hibernate.org> wrote:
>>
>> See
>> <http://ci.hibernate.org/job/hibernate-search-master-mariadb/244/changes>
>>
>


From gbadner at redhat.com  Fri Dec 16 19:06:15 2016
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 16 Dec 2016 16:06:15 -0800
Subject: [hibernate-dev] EntityGraph query spaces not applied to Query
	(HHH-11213)
Message-ID: <CAFDzhiRiVPsVmZpfQs9xSrvMkBMkp44jyHmi=uTwQWp-oiau6g@mail.gmail.com>

Query spaces for EntityGraph nodes/subgraphs are not currently added
when applied to a Query, and so the session is not flushed if it
contains updated data relevant to the EntityGraph that is not in the
query spaces defined for the Query.

I originally though this was a critical issue, but now that I'm
looking into it, I'm not so sure. I am having a hard time coming up
with a test case where it matters.

I've created a pull request with the test case attached to HHH-11213,
with some added checks to detect if the session flushes. [1]

In this case, the session does not flush, but the query results are
still correct because the updated entity is taken from the Session,
not from the ResultSet returned by the query.

I wonder now if it really is necessary to flush the Session when the
session has updates that apply *only* to the EntityGraph (and not to
the base Query).

Thoughts?

Thanks,
Gail


[1] https://github.com/hibernate/hibernate-orm/pull/1707

From steve at hibernate.org  Fri Dec 16 20:03:38 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 17 Dec 2016 01:03:38 +0000
Subject: [hibernate-dev] EntityGraph query spaces not applied to Query
	(HHH-11213)
In-Reply-To: <CAFDzhiRiVPsVmZpfQs9xSrvMkBMkp44jyHmi=uTwQWp-oiau6g@mail.gmail.com>
References: <CAFDzhiRiVPsVmZpfQs9xSrvMkBMkp44jyHmi=uTwQWp-oiau6g@mail.gmail.com>
Message-ID: <CAFdSV9sHz90-qNnsmqa25oK4pOja1Udv4p3CNzrpAzhwFR4roA@mail.gmail.com>

It likely is not an issue.  Query spaces only come into play with regards
to restrictions.  Since the EntityGraph is not part of the query proper
restrictions cannot be based on it.

That would be a scenario to try though... create a query restricting
results based on some joined attribute and then supply an EntityGraph hint
for that attribute.  But IMO that is a completely contrived scenario.

On Fri, Dec 16, 2016, 6:09 PM Gail Badner <gbadner at redhat.com> wrote:

> Query spaces for EntityGraph nodes/subgraphs are not currently added
> when applied to a Query, and so the session is not flushed if it
> contains updated data relevant to the EntityGraph that is not in the
> query spaces defined for the Query.
>
> I originally though this was a critical issue, but now that I'm
> looking into it, I'm not so sure. I am having a hard time coming up
> with a test case where it matters.
>
> I've created a pull request with the test case attached to HHH-11213,
> with some added checks to detect if the session flushes. [1]
>
> In this case, the session does not flush, but the query results are
> still correct because the updated entity is taken from the Session,
> not from the ResultSet returned by the query.
>
> I wonder now if it really is necessary to flush the Session when the
> session has updates that apply *only* to the EntityGraph (and not to
> the base Query).
>
> Thoughts?
>
> Thanks,
> Gail
>
>
> [1] https://github.com/hibernate/hibernate-orm/pull/1707
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Dec 16 23:15:08 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 17 Dec 2016 04:15:08 +0000
Subject: [hibernate-dev] SQM - PoC design doc
Message-ID: <CAFdSV9t8HOiFyrd8Wujn83XaG4D0ocmDi+j4dgTPbuYZn7x8bg@mail.gmail.com>

I have pushed a newly updated version of the design.adoc bringing the
discussions up-to-date with the latest code/design.

This PoC work is getting very far along and I really have not had much
feedback. My concern is that this code is only going to become harder to
review (more to look at) as more time passes.

I know digging in the code (it is a lot) is not really feasible, but please
at least take some time to look over the design.adoc in the poc repo.

Feedback sooner is better :)

From gbadner at redhat.com  Tue Dec 20 04:47:11 2016
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 20 Dec 2016 01:47:11 -0800
Subject: [hibernate-dev] EntityGraph query spaces not applied to Query
	(HHH-11213)
In-Reply-To: <CAFdSV9sHz90-qNnsmqa25oK4pOja1Udv4p3CNzrpAzhwFR4roA@mail.gmail.com>
References: <CAFDzhiRiVPsVmZpfQs9xSrvMkBMkp44jyHmi=uTwQWp-oiau6g@mail.gmail.com>
	<CAFdSV9sHz90-qNnsmqa25oK4pOja1Udv4p3CNzrpAzhwFR4roA@mail.gmail.com>
Message-ID: <CAFDzhiQq1hS0+=-q83OzU5N1Xr8yuDinFbVp85vQ0+SYr53+ew@mail.gmail.com>

See below...

On Fri, Dec 16, 2016 at 5:03 PM, Steve Ebersole <steve at hibernate.org> wrote:
> It likely is not an issue.  Query spaces only come into play with regards to
> restrictions.  Since the EntityGraph is not part of the query proper
> restrictions cannot be based on it.
>
> That would be a scenario to try though... create a query restricting results
> based on some joined attribute and then supply an EntityGraph hint for that
> attribute.  But IMO that is a completely contrived scenario.

I've confirmed that adding the restriction on an attribute to the
Query will add that joined entity as an affected query space, with or
without an EntityGraph. Any changes affecting the joined query space
would force a flush before executing the query.

For example, changing the query in the PR to something like:

query = entityManager.createQuery( "from Company.class where
location.address = '123 somewhereelse'");
query.setHint( QueryHints.HINT_LOADGRAPH, entityGraph );

The change to location#address that is already in the Session would
result in flushing the session before executing the query.

Is this the sort of test that you are suggesting? If not, please give
me an example.

>
> On Fri, Dec 16, 2016, 6:09 PM Gail Badner <gbadner at redhat.com> wrote:
>>
>> Query spaces for EntityGraph nodes/subgraphs are not currently added
>> when applied to a Query, and so the session is not flushed if it
>> contains updated data relevant to the EntityGraph that is not in the
>> query spaces defined for the Query.
>>
>> I originally though this was a critical issue, but now that I'm
>> looking into it, I'm not so sure. I am having a hard time coming up
>> with a test case where it matters.
>>
>> I've created a pull request with the test case attached to HHH-11213,
>> with some added checks to detect if the session flushes. [1]
>>
>> In this case, the session does not flush, but the query results are
>> still correct because the updated entity is taken from the Session,
>> not from the ResultSet returned by the query.
>>
>> I wonder now if it really is necessary to flush the Session when the
>> session has updates that apply *only* to the EntityGraph (and not to
>> the base Query).
>>
>> Thoughts?
>>
>> Thanks,
>> Gail
>>
>>
>> [1] https://github.com/hibernate/hibernate-orm/pull/1707
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From dreborier at gmail.com  Tue Dec 20 05:12:08 2016
From: dreborier at gmail.com (andrea boriero)
Date: Tue, 20 Dec 2016 10:12:08 +0000
Subject: [hibernate-dev] Starting 5.2.6 release
Message-ID: <CAL00eSTE-5zbKTh99whg9bbHpg0=Hjuwg_RKw9=PNGQTwDKBkw@mail.gmail.com>

Please do not push anything to master branch.

Thanks,

Andrea

From dreborier at gmail.com  Tue Dec 20 09:49:37 2016
From: dreborier at gmail.com (andrea boriero)
Date: Tue, 20 Dec 2016 14:49:37 +0000
Subject: [hibernate-dev] Hibernate ORM 5.2.6.Final has been released
Message-ID: <CAL00eSQYKWKnT_i4igwXwyrKKWk+E4e+Q00Rmx8bs0r+62wcvw@mail.gmail.com>

For details:

http://in.relation.to/2016/12/20/hibernate-orm-526-final-release

From guillaume.smet at gmail.com  Tue Dec 20 10:06:11 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 20 Dec 2016 16:06:11 +0100
Subject: [hibernate-dev] NoORM IRC meeting minutes
Message-ID: <CALt0+o8xm=kv_3LLd75xba3cTPxwVhebL6U4yGb1SmXDBzSqeA@mail.gmail.com>

Hi,

Here are the minutes of our biweekly IRC meeting:

16:03 < jbott> Meeting ended Tue Dec 20 15:02:28 2016 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:03 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-12-20-14.00.html
16:03 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-12-20-14.00.txt
16:03 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-12-20-14.00.log.html

Happy holidays!

-- 
Guillaume

From yoann at hibernate.org  Tue Dec 20 10:55:21 2016
From: yoann at hibernate.org (Yoann Rodiere)
Date: Tue, 20 Dec 2016 16:55:21 +0100
Subject: [hibernate-dev] Hibernate Search 5.6.0.CR1 and 5.7.0.Beta2 released
Message-ID: <CAEqagppuuyf9DFBeGg=6T31bmuAUQ_8az_3MRqdVdnEFjrEOyg@mail.gmail.com>

Hello everyone,

We just released Hibernate Search 5.6.0.CR1 and 5.7.0.Beta2, with the
latest bugfixes and previously missing features for our experimental
Elasticsearch integration.

This is the last step before 5.6 is released, so be sure to check it out so
you can share your thoughts with us before the release!

For more information, please see our blog:

http://in.relation.to/2016/12/20/hibernate-search-5-6-0-CR1-and-5-7-0-Beta2/

Cheers,

Yoann Rodi?re <yoann at hibernate.org>
Hibernate NoORM Team

From davide at hibernate.org  Tue Dec 20 13:22:09 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Tue, 20 Dec 2016 18:22:09 +0000
Subject: [hibernate-dev] [OGM} 5.1.0.Beta2 release delayed because of Nexus
Message-ID: <CANoTJYNctNg546cgYgmrnb8wZe=K4PcTZtivqUTcMbKSQFozbQ@mail.gmail.com>

Hi,
Jenkins deployed everything but Nexus doesn't want to release it.

Any suggestions?

I'll try again tomorrow

Thanks

From steve at hibernate.org  Tue Dec 20 16:55:52 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 20 Dec 2016 21:55:52 +0000
Subject: [hibernate-dev] SQM - PoC design doc
In-Reply-To: <CAFdSV9t8HOiFyrd8Wujn83XaG4D0ocmDi+j4dgTPbuYZn7x8bg@mail.gmail.com>
References: <CAFdSV9t8HOiFyrd8Wujn83XaG4D0ocmDi+j4dgTPbuYZn7x8bg@mail.gmail.com>
Message-ID: <CAFdSV9uqZA=dpLNy_66MQh_T_uFyZnkvXfaHF+FVupdYAmbTmQ@mail.gmail.com>

Christian provided some good feedback on the HipChat channel and we have
started a discussion about those there.

I have run into a new one specific to union-subclasses and building the
Table/Column structures for these.  The problem is that we need 2
distinction understandings of the Tables for these entities:
1) Is the union query used for selects.
2) is the physical hierarchy tables for DML operations

The problem comes from the fact that Column holds a link to its Table.
Here we'd have to create duplicated columns, one for the union-query table
and one for the physical tables.  And then we'd have to do the same for
things that expose columns.  For example, if I ask the "identifier
descriptor" for a union-subclass entity for its columns, do I get the
Columns that report the union-query as its Table?  Or do I get the Columns
that report the physical Table for its Table?


On Fri, Dec 16, 2016 at 10:15 PM Steve Ebersole <steve at hibernate.org> wrote:

> I have pushed a newly updated version of the design.adoc bringing the
> discussions up-to-date with the latest code/design.
>
> This PoC work is getting very far along and I really have not had much
> feedback. My concern is that this code is only going to become harder to
> review (more to look at) as more time passes.
>
> I know digging in the code (it is a lot) is not really feasible, but
> please at least take some time to look over the design.adoc in the poc
> repo.
>
> Feedback sooner is better :)
>

From andrea at hibernate.org  Wed Dec 21 01:28:23 2016
From: andrea at hibernate.org (andrea boriero)
Date: Wed, 21 Dec 2016 06:28:23 +0000
Subject: [hibernate-dev] SQM - PoC design doc
In-Reply-To: <CAFdSV9uqZA=dpLNy_66MQh_T_uFyZnkvXfaHF+FVupdYAmbTmQ@mail.gmail.com>
References: <CAFdSV9t8HOiFyrd8Wujn83XaG4D0ocmDi+j4dgTPbuYZn7x8bg@mail.gmail.com>
	<CAFdSV9uqZA=dpLNy_66MQh_T_uFyZnkvXfaHF+FVupdYAmbTmQ@mail.gmail.com>
Message-ID: <CAL00eSQS2=ZYF9jnbwkyj26d1nOkc=sF9P9T8uHgFSUtQUm+Tg@mail.gmail.com>

I think it should return the Columns
that reports the physical Table for its Table.

On 20 Dec 2016 22:02, "Steve Ebersole" <steve at hibernate.org> wrote:

Christian provided some good feedback on the HipChat channel and we have
started a discussion about those there.

I have run into a new one specific to union-subclasses and building the
Table/Column structures for these.  The problem is that we need 2
distinction understandings of the Tables for these entities:
1) Is the union query used for selects.
2) is the physical hierarchy tables for DML operations

The problem comes from the fact that Column holds a link to its Table.
Here we'd have to create duplicated columns, one for the union-query table
and one for the physical tables.  And then we'd have to do the same for
things that expose columns.  For example, if I ask the "identifier
descriptor" for a union-subclass entity for its columns, do I get the
Columns that report the union-query as its Table?  Or do I get the Columns
that report the physical Table for its Table?


On Fri, Dec 16, 2016 at 10:15 PM Steve Ebersole <steve at hibernate.org> wrote:

> I have pushed a newly updated version of the design.adoc bringing the
> discussions up-to-date with the latest code/design.
>
> This PoC work is getting very far along and I really have not had much
> feedback. My concern is that this code is only going to become harder to
> review (more to look at) as more time passes.
>
> I know digging in the code (it is a lot) is not really feasible, but
> please at least take some time to look over the design.adoc in the poc
> repo.
>
> Feedback sooner is better :)
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

From christian.beikov at gmail.com  Wed Dec 21 03:33:36 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 21 Dec 2016 09:33:36 +0100
Subject: [hibernate-dev] SQM - PoC design doc
In-Reply-To: <CAL00eSQS2=ZYF9jnbwkyj26d1nOkc=sF9P9T8uHgFSUtQUm+Tg@mail.gmail.com>
References: <CAFdSV9t8HOiFyrd8Wujn83XaG4D0ocmDi+j4dgTPbuYZn7x8bg@mail.gmail.com>
	<CAFdSV9uqZA=dpLNy_66MQh_T_uFyZnkvXfaHF+FVupdYAmbTmQ@mail.gmail.com>
	<CAL00eSQS2=ZYF9jnbwkyj26d1nOkc=sF9P9T8uHgFSUtQUm+Tg@mail.gmail.com>
Message-ID: <5f780e32-d36b-bde4-0ee1-5f19c9a88675@gmail.com>

I tried to think of a case where returning the union-query as table 
would enable optimizations, but so far I couldn't come up with anything. 
With the other approach, depending on the stage this optimization should 
happen, it might be pretty simple to omit columns of table references 
and furthermore the table references themselves which have by proof no 
effect on the query outcome.

How about letting a "Table" have a kind of parent table? The physical 
table could then have the union-query as parent table.
Have you thought about possible implications of the approaches apart 
from having to create "duplicate" column objects?

Am 21.12.2016 um 07:28 schrieb andrea boriero:
> I think it should return the Columns
> that reports the physical Table for its Table.
>
> On 20 Dec 2016 22:02, "Steve Ebersole" <steve at hibernate.org> wrote:
>
> Christian provided some good feedback on the HipChat channel and we have
> started a discussion about those there.
>
> I have run into a new one specific to union-subclasses and building the
> Table/Column structures for these.  The problem is that we need 2
> distinction understandings of the Tables for these entities:
> 1) Is the union query used for selects.
> 2) is the physical hierarchy tables for DML operations
>
> The problem comes from the fact that Column holds a link to its Table.
> Here we'd have to create duplicated columns, one for the union-query table
> and one for the physical tables.  And then we'd have to do the same for
> things that expose columns.  For example, if I ask the "identifier
> descriptor" for a union-subclass entity for its columns, do I get the
> Columns that report the union-query as its Table?  Or do I get the Columns
> that report the physical Table for its Table?
>
>
> On Fri, Dec 16, 2016 at 10:15 PM Steve Ebersole <steve at hibernate.org> wrote:
>
>> I have pushed a newly updated version of the design.adoc bringing the
>> discussions up-to-date with the latest code/design.
>>
>> This PoC work is getting very far along and I really have not had much
>> feedback. My concern is that this code is only going to become harder to
>> review (more to look at) as more time passes.
>>
>> I know digging in the code (it is a lot) is not really feasible, but
>> please at least take some time to look over the design.adoc in the poc
>> repo.
>>
>> Feedback sooner is better :)
>>
> _______________________________________________
> 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 christian.beikov at gmail.com  Wed Dec 21 03:33:43 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 21 Dec 2016 09:33:43 +0100
Subject: [hibernate-dev] SQM - PoC design doc
In-Reply-To: <CAL00eSQS2=ZYF9jnbwkyj26d1nOkc=sF9P9T8uHgFSUtQUm+Tg@mail.gmail.com>
References: <CAFdSV9t8HOiFyrd8Wujn83XaG4D0ocmDi+j4dgTPbuYZn7x8bg@mail.gmail.com>
	<CAFdSV9uqZA=dpLNy_66MQh_T_uFyZnkvXfaHF+FVupdYAmbTmQ@mail.gmail.com>
	<CAL00eSQS2=ZYF9jnbwkyj26d1nOkc=sF9P9T8uHgFSUtQUm+Tg@mail.gmail.com>
Message-ID: <9c15ca1f-5fd9-309f-d229-46d942e4bc7b@gmail.com>

I tried to think of a case where returning the union-query as table 
would enable optimizations, but so far I couldn't come up with anything. 
With the other approach, depending on the stage this optimization should 
happen, it might be pretty simple to omit columns of table references 
and furthermore the table references themselves which have by proof no 
effect on the query outcome.

How about letting a "Table" have a kind of parent table? The physical 
table could then have the union-query as parent table.
Have you thought about possible implications of the approaches apart 
from having to create "duplicate" column objects?

Am 21.12.2016 um 07:28 schrieb andrea boriero:
> I think it should return the Columns
> that reports the physical Table for its Table.
>
> On 20 Dec 2016 22:02, "Steve Ebersole" <steve at hibernate.org> wrote:
>
> Christian provided some good feedback on the HipChat channel and we have
> started a discussion about those there.
>
> I have run into a new one specific to union-subclasses and building the
> Table/Column structures for these.  The problem is that we need 2
> distinction understandings of the Tables for these entities:
> 1) Is the union query used for selects.
> 2) is the physical hierarchy tables for DML operations
>
> The problem comes from the fact that Column holds a link to its Table.
> Here we'd have to create duplicated columns, one for the union-query table
> and one for the physical tables.  And then we'd have to do the same for
> things that expose columns.  For example, if I ask the "identifier
> descriptor" for a union-subclass entity for its columns, do I get the
> Columns that report the union-query as its Table?  Or do I get the Columns
> that report the physical Table for its Table?
>
>
> On Fri, Dec 16, 2016 at 10:15 PM Steve Ebersole <steve at hibernate.org> wrote:
>
>> I have pushed a newly updated version of the design.adoc bringing the
>> discussions up-to-date with the latest code/design.
>>
>> This PoC work is getting very far along and I really have not had much
>> feedback. My concern is that this code is only going to become harder to
>> review (more to look at) as more time passes.
>>
>> I know digging in the code (it is a lot) is not really feasible, but
>> please at least take some time to look over the design.adoc in the poc
>> repo.
>>
>> Feedback sooner is better :)
>>
> _______________________________________________
> 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 Dec 21 08:42:37 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 Dec 2016 13:42:37 +0000
Subject: [hibernate-dev] SQM - PoC design doc
In-Reply-To: <9c15ca1f-5fd9-309f-d229-46d942e4bc7b@gmail.com>
References: <CAFdSV9t8HOiFyrd8Wujn83XaG4D0ocmDi+j4dgTPbuYZn7x8bg@mail.gmail.com>
	<CAFdSV9uqZA=dpLNy_66MQh_T_uFyZnkvXfaHF+FVupdYAmbTmQ@mail.gmail.com>
	<CAL00eSQS2=ZYF9jnbwkyj26d1nOkc=sF9P9T8uHgFSUtQUm+Tg@mail.gmail.com>
	<9c15ca1f-5fd9-309f-d229-46d942e4bc7b@gmail.com>
Message-ID: <CAFdSV9twemOn4m_jBHNm1Zas2SUqFt=q6-8xwXPjDS3CjwnCpA@mail.gmail.com>

I should have been more clear as to why this is a problem :)

The columns are resolved as the persisters are built.  Later as we build
the SQL AST part of that process is resolving ColumnBindings.  To do that
the Column is passed to the TableGroup which is asked to resolve it into a
ColumnBinding.  To do that in needs to find the TableBinding within the
TableGroup for that Colum#sourceTable.

A ColumnBinding is a reference to a column in relation to a specific table
reference.  In other words a qualified column reference.

It is conceivable that some special Table definition could help.  In fact
that is the preliminary path I started down by creating a
UnionSubclassTable specialization.  So far that is still hitting some
problems.

On Wed, Dec 21, 2016, 2:36 AM Christian Beikov <christian.beikov at gmail.com>
wrote:

> I tried to think of a case where returning the union-query as table
> would enable optimizations, but so far I couldn't come up with anything.
> With the other approach, depending on the stage this optimization should
> happen, it might be pretty simple to omit columns of table references
> and furthermore the table references themselves which have by proof no
> effect on the query outcome.
>
> How about letting a "Table" have a kind of parent table? The physical
> table could then have the union-query as parent table.
> Have you thought about possible implications of the approaches apart
> from having to create "duplicate" column objects?
>
> Am 21.12.2016 um 07:28 schrieb andrea boriero:
> > I think it should return the Columns
> > that reports the physical Table for its Table.
> >
> > On 20 Dec 2016 22:02, "Steve Ebersole" <steve at hibernate.org> wrote:
> >
> > Christian provided some good feedback on the HipChat channel and we have
> > started a discussion about those there.
> >
> > I have run into a new one specific to union-subclasses and building the
> > Table/Column structures for these.  The problem is that we need 2
> > distinction understandings of the Tables for these entities:
> > 1) Is the union query used for selects.
> > 2) is the physical hierarchy tables for DML operations
> >
> > The problem comes from the fact that Column holds a link to its Table.
> > Here we'd have to create duplicated columns, one for the union-query
> table
> > and one for the physical tables.  And then we'd have to do the same for
> > things that expose columns.  For example, if I ask the "identifier
> > descriptor" for a union-subclass entity for its columns, do I get the
> > Columns that report the union-query as its Table?  Or do I get the
> Columns
> > that report the physical Table for its Table?
> >
> >
> > On Fri, Dec 16, 2016 at 10:15 PM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> I have pushed a newly updated version of the design.adoc bringing the
> >> discussions up-to-date with the latest code/design.
> >>
> >> This PoC work is getting very far along and I really have not had much
> >> feedback. My concern is that this code is only going to become harder to
> >> review (more to look at) as more time passes.
> >>
> >> I know digging in the code (it is a lot) is not really feasible, but
> >> please at least take some time to look over the design.adoc in the poc
> >> repo.
> >>
> >> Feedback sooner is better :)
> >>
> > _______________________________________________
> > 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 Dec 21 09:53:54 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 Dec 2016 14:53:54 +0000
Subject: [hibernate-dev] SQM - PoC design doc
In-Reply-To: <CAFdSV9twemOn4m_jBHNm1Zas2SUqFt=q6-8xwXPjDS3CjwnCpA@mail.gmail.com>
References: <CAFdSV9t8HOiFyrd8Wujn83XaG4D0ocmDi+j4dgTPbuYZn7x8bg@mail.gmail.com>
	<CAFdSV9uqZA=dpLNy_66MQh_T_uFyZnkvXfaHF+FVupdYAmbTmQ@mail.gmail.com>
	<CAL00eSQS2=ZYF9jnbwkyj26d1nOkc=sF9P9T8uHgFSUtQUm+Tg@mail.gmail.com>
	<9c15ca1f-5fd9-309f-d229-46d942e4bc7b@gmail.com>
	<CAFdSV9twemOn4m_jBHNm1Zas2SUqFt=q6-8xwXPjDS3CjwnCpA@mail.gmail.com>
Message-ID: <CAFdSV9s4SFoRMaJCRxujUe5WUTX-Gc6t-KLf+Nrh2-c6=evSSg@mail.gmail.com>

Christian what do you mean by "case where returning the union-query as
table would enable optimizations".



On Wed, Dec 21, 2016 at 7:42 AM Steve Ebersole <steve at hibernate.org> wrote:

> I should have been more clear as to why this is a problem :)
>
> The columns are resolved as the persisters are built.  Later as we build
> the SQL AST part of that process is resolving ColumnBindings.  To do that
> the Column is passed to the TableGroup which is asked to resolve it into a
> ColumnBinding.  To do that in needs to find the TableBinding within the
> TableGroup for that Colum#sourceTable.
>
> A ColumnBinding is a reference to a column in relation to a specific table
> reference.  In other words a qualified column reference.
>
> It is conceivable that some special Table definition could help.  In fact
> that is the preliminary path I started down by creating a
> UnionSubclassTable specialization.  So far that is still hitting some
> problems.
>
> On Wed, Dec 21, 2016, 2:36 AM Christian Beikov <christian.beikov at gmail.com>
> wrote:
>
> I tried to think of a case where returning the union-query as table
> would enable optimizations, but so far I couldn't come up with anything.
> With the other approach, depending on the stage this optimization should
> happen, it might be pretty simple to omit columns of table references
> and furthermore the table references themselves which have by proof no
> effect on the query outcome.
>
> How about letting a "Table" have a kind of parent table? The physical
> table could then have the union-query as parent table.
> Have you thought about possible implications of the approaches apart
> from having to create "duplicate" column objects?
>
> Am 21.12.2016 um 07:28 schrieb andrea boriero:
> > I think it should return the Columns
> > that reports the physical Table for its Table.
> >
> > On 20 Dec 2016 22:02, "Steve Ebersole" <steve at hibernate.org> wrote:
> >
> > Christian provided some good feedback on the HipChat channel and we have
> > started a discussion about those there.
> >
> > I have run into a new one specific to union-subclasses and building the
> > Table/Column structures for these.  The problem is that we need 2
> > distinction understandings of the Tables for these entities:
> > 1) Is the union query used for selects.
> > 2) is the physical hierarchy tables for DML operations
> >
> > The problem comes from the fact that Column holds a link to its Table.
> > Here we'd have to create duplicated columns, one for the union-query
> table
> > and one for the physical tables.  And then we'd have to do the same for
> > things that expose columns.  For example, if I ask the "identifier
> > descriptor" for a union-subclass entity for its columns, do I get the
> > Columns that report the union-query as its Table?  Or do I get the
> Columns
> > that report the physical Table for its Table?
> >
> >
> > On Fri, Dec 16, 2016 at 10:15 PM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> I have pushed a newly updated version of the design.adoc bringing the
> >> discussions up-to-date with the latest code/design.
> >>
> >> This PoC work is getting very far along and I really have not had much
> >> feedback. My concern is that this code is only going to become harder to
> >> review (more to look at) as more time passes.
> >>
> >> I know digging in the code (it is a lot) is not really feasible, but
> >> please at least take some time to look over the design.adoc in the poc
> >> repo.
> >>
> >> Feedback sooner is better :)
> >>
> > _______________________________________________
> > 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 Dec 21 12:10:54 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 Dec 2016 17:10:54 +0000
Subject: [hibernate-dev] SQM - PoC design doc
In-Reply-To: <CAFdSV9twemOn4m_jBHNm1Zas2SUqFt=q6-8xwXPjDS3CjwnCpA@mail.gmail.com>
References: <CAFdSV9t8HOiFyrd8Wujn83XaG4D0ocmDi+j4dgTPbuYZn7x8bg@mail.gmail.com>
	<CAFdSV9uqZA=dpLNy_66MQh_T_uFyZnkvXfaHF+FVupdYAmbTmQ@mail.gmail.com>
	<CAL00eSQS2=ZYF9jnbwkyj26d1nOkc=sF9P9T8uHgFSUtQUm+Tg@mail.gmail.com>
	<9c15ca1f-5fd9-309f-d229-46d942e4bc7b@gmail.com>
	<CAFdSV9twemOn4m_jBHNm1Zas2SUqFt=q6-8xwXPjDS3CjwnCpA@mail.gmail.com>
Message-ID: <CAFdSV9t=TDOy6QwJGbr1d6K3mrH2VepyzcYDM+TYzfi8BEhbSg@mail.gmail.com>

The general problem is actually a choice in the current EntityPersister
design, that we decided to leave for later in terms of whether to carry
that forward into the new persister design.

The original choice was to duplicate column and attribute info on an
EntityPersister from super and sub types.  E.g. given a hierarchy like
Human <- Employee <- Manager:

   - Human contains the column and attribute info from Employee and
   Manager.
   - Employee contains the column and attribute info from Human and Manager
   - Manager contains the column and attribute info from Employee and Human

I have a semi-working solution accounting for the columns part.  But the
attributes part is still tbd.  I personally would rather see declared
attributes only on the persister defining them and persisters with links to
their super/subs to access attributes when needed.


On Wed, Dec 21, 2016 at 7:42 AM Steve Ebersole <steve at hibernate.org> wrote:

> I should have been more clear as to why this is a problem :)
>
> The columns are resolved as the persisters are built.  Later as we build
> the SQL AST part of that process is resolving ColumnBindings.  To do that
> the Column is passed to the TableGroup which is asked to resolve it into a
> ColumnBinding.  To do that in needs to find the TableBinding within the
> TableGroup for that Colum#sourceTable.
>
> A ColumnBinding is a reference to a column in relation to a specific table
> reference.  In other words a qualified column reference.
>
> It is conceivable that some special Table definition could help.  In fact
> that is the preliminary path I started down by creating a
> UnionSubclassTable specialization.  So far that is still hitting some
> problems.
>
> On Wed, Dec 21, 2016, 2:36 AM Christian Beikov <christian.beikov at gmail.com>
> wrote:
>
> I tried to think of a case where returning the union-query as table
> would enable optimizations, but so far I couldn't come up with anything.
> With the other approach, depending on the stage this optimization should
> happen, it might be pretty simple to omit columns of table references
> and furthermore the table references themselves which have by proof no
> effect on the query outcome.
>
> How about letting a "Table" have a kind of parent table? The physical
> table could then have the union-query as parent table.
> Have you thought about possible implications of the approaches apart
> from having to create "duplicate" column objects?
>
> Am 21.12.2016 um 07:28 schrieb andrea boriero:
> > I think it should return the Columns
> > that reports the physical Table for its Table.
> >
> > On 20 Dec 2016 22:02, "Steve Ebersole" <steve at hibernate.org> wrote:
> >
> > Christian provided some good feedback on the HipChat channel and we have
> > started a discussion about those there.
> >
> > I have run into a new one specific to union-subclasses and building the
> > Table/Column structures for these.  The problem is that we need 2
> > distinction understandings of the Tables for these entities:
> > 1) Is the union query used for selects.
> > 2) is the physical hierarchy tables for DML operations
> >
> > The problem comes from the fact that Column holds a link to its Table.
> > Here we'd have to create duplicated columns, one for the union-query
> table
> > and one for the physical tables.  And then we'd have to do the same for
> > things that expose columns.  For example, if I ask the "identifier
> > descriptor" for a union-subclass entity for its columns, do I get the
> > Columns that report the union-query as its Table?  Or do I get the
> Columns
> > that report the physical Table for its Table?
> >
> >
> > On Fri, Dec 16, 2016 at 10:15 PM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> I have pushed a newly updated version of the design.adoc bringing the
> >> discussions up-to-date with the latest code/design.
> >>
> >> This PoC work is getting very far along and I really have not had much
> >> feedback. My concern is that this code is only going to become harder to
> >> review (more to look at) as more time passes.
> >>
> >> I know digging in the code (it is a lot) is not really feasible, but
> >> please at least take some time to look over the design.adoc in the poc
> >> repo.
> >>
> >> Feedback sooner is better :)
> >>
> > _______________________________________________
> > 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 christian.beikov at gmail.com  Wed Dec 21 23:59:44 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 22 Dec 2016 05:59:44 +0100
Subject: [hibernate-dev] SQM - PoC design doc
In-Reply-To: <CAFdSV9s4SFoRMaJCRxujUe5WUTX-Gc6t-KLf+Nrh2-c6=evSSg@mail.gmail.com>
References: <CAFdSV9t8HOiFyrd8Wujn83XaG4D0ocmDi+j4dgTPbuYZn7x8bg@mail.gmail.com>
	<CAFdSV9uqZA=dpLNy_66MQh_T_uFyZnkvXfaHF+FVupdYAmbTmQ@mail.gmail.com>
	<CAL00eSQS2=ZYF9jnbwkyj26d1nOkc=sF9P9T8uHgFSUtQUm+Tg@mail.gmail.com>
	<9c15ca1f-5fd9-309f-d229-46d942e4bc7b@gmail.com>
	<CAFdSV9twemOn4m_jBHNm1Zas2SUqFt=q6-8xwXPjDS3CjwnCpA@mail.gmail.com>
	<CAFdSV9s4SFoRMaJCRxujUe5WUTX-Gc6t-KLf+Nrh2-c6=evSSg@mail.gmail.com>
Message-ID: <930a6435-03c4-7d5d-373d-70dd71881e52@gmail.com>

I was thinking that during the SQL generation process or maybe an 
earlier phase, one could analyze and determine that a column is only 
used in a context that doesn't change the query result e.g. in a 
predicate that can be removed. If by removing that predicate and thus 
the column binding, there are no column bindings left for a table, the 
table could be omitted. By having the physical table being returned by 
the column, I was thinking it might get easier to implement this.
I was thinking about whether using the union-query as the "table" for a 
column would allow for optimizations, but couldn't come up with ideas 
yet. Hope that makes things clearer?

Am 21.12.2016 um 15:53 schrieb Steve Ebersole:
> Christian what do you mean by "case where returning the union-query as 
> table would enable optimizations".
>
>
>
> On Wed, Dec 21, 2016 at 7:42 AM Steve Ebersole <steve at hibernate.org 
> <mailto:steve at hibernate.org>> wrote:
>
>     I should have been more clear as to why this is a problem :)
>
>     The columns are resolved as the persisters are built.  Later as we
>     build the SQL AST part of that process is resolving
>     ColumnBindings.  To do that the Column is passed to the TableGroup
>     which is asked to resolve it into a ColumnBinding.  To do that in
>     needs to find the TableBinding within the TableGroup for that
>     Colum#sourceTable.
>
>     A ColumnBinding is a reference to a column in relation to a
>     specific table reference.  In other words a qualified column
>     reference.
>
>     It is conceivable that some special Table definition could help. 
>     In fact that is the preliminary path I started down by creating a
>     UnionSubclassTable specialization.  So far that is still hitting
>     some problems.
>
>
>     On Wed, Dec 21, 2016, 2:36 AM Christian Beikov
>     <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>     wrote:
>
>         I tried to think of a case where returning the union-query as
>         table
>         would enable optimizations, but so far I couldn't come up with
>         anything.
>         With the other approach, depending on the stage this
>         optimization should
>         happen, it might be pretty simple to omit columns of table
>         references
>         and furthermore the table references themselves which have by
>         proof no
>         effect on the query outcome.
>
>         How about letting a "Table" have a kind of parent table? The
>         physical
>         table could then have the union-query as parent table.
>         Have you thought about possible implications of the approaches
>         apart
>         from having to create "duplicate" column objects?
>
>         Am 21.12.2016 um 07:28 schrieb andrea boriero:
>         > I think it should return the Columns
>         > that reports the physical Table for its Table.
>         >
>         > On 20 Dec 2016 22:02, "Steve Ebersole" <steve at hibernate.org
>         <mailto:steve at hibernate.org>> wrote:
>         >
>         > Christian provided some good feedback on the HipChat channel
>         and we have
>         > started a discussion about those there.
>         >
>         > I have run into a new one specific to union-subclasses and
>         building the
>         > Table/Column structures for these.  The problem is that we
>         need 2
>         > distinction understandings of the Tables for these entities:
>         > 1) Is the union query used for selects.
>         > 2) is the physical hierarchy tables for DML operations
>         >
>         > The problem comes from the fact that Column holds a link to
>         its Table.
>         > Here we'd have to create duplicated columns, one for the
>         union-query table
>         > and one for the physical tables.  And then we'd have to do
>         the same for
>         > things that expose columns.  For example, if I ask the
>         "identifier
>         > descriptor" for a union-subclass entity for its columns, do
>         I get the
>         > Columns that report the union-query as its Table?  Or do I
>         get the Columns
>         > that report the physical Table for its Table?
>         >
>         >
>         > On Fri, Dec 16, 2016 at 10:15 PM Steve Ebersole
>         <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
>         >
>         >> I have pushed a newly updated version of the design.adoc
>         bringing the
>         >> discussions up-to-date with the latest code/design.
>         >>
>         >> This PoC work is getting very far along and I really have
>         not had much
>         >> feedback. My concern is that this code is only going to
>         become harder to
>         >> review (more to look at) as more time passes.
>         >>
>         >> I know digging in the code (it is a lot) is not really
>         feasible, but
>         >> please at least take some time to look over the design.adoc
>         in the poc
>         >> repo.
>         >>
>         >> Feedback sooner is better :)
>         >>
>         > _______________________________________________
>         > 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
>         <mailto:hibernate-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From davide at hibernate.org  Thu Dec 22 08:37:25 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Thu, 22 Dec 2016 13:37:25 +0000
Subject: [hibernate-dev] Jenkins upgrade on CI
Message-ID: <CANoTJYPejjPMPndWRoJnCfKHhPmwpLKc+eB0U4oZW1uX0fW+Zg@mail.gmail.com>

Hi,
I'm going to upgrade our Jenkins on CI  next week, the 27th of December.

This could  be a relatively safe procedure but because our version is
old and we are using several plugins I'm not sure it will go smoothly.

If you have some jobs that need to be executed that day, let me know.

Davide

From steve at hibernate.org  Tue Dec 27 16:01:24 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 27 Dec 2016 21:01:24 +0000
Subject: [hibernate-dev] ScrollableResults and 6.0
Message-ID: <CAFdSV9tJYJ5ASJKM4GxJNKUSg6pS7PbFc8e24emsim_trQ_fuQ@mail.gmail.com>

For 6.0 I'd like to also make ScrollableResults parameterized wrt the "row
type".  E.g.

ScrollableResults<Person> sr = session.createQuery( ..., Person.class
).scroll();

However that changes the signature of its methods returning a "row"
(currently always defined as Object[]).

How would everyone prefer we handle this?  Do I just change the signatures
of the existing methods?  Or add new methods?

From steve at hibernate.org  Tue Dec 27 16:02:58 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 27 Dec 2016 21:02:58 +0000
Subject: [hibernate-dev] ScrollableResults and 6.0
In-Reply-To: <CAFdSV9tJYJ5ASJKM4GxJNKUSg6pS7PbFc8e24emsim_trQ_fuQ@mail.gmail.com>
References: <CAFdSV9tJYJ5ASJKM4GxJNKUSg6pS7PbFc8e24emsim_trQ_fuQ@mail.gmail.com>
Message-ID: <CAFdSV9s_wJRCvPJbGdgGe2M99neTvF3uVSeG1-gq5=QtiM-5xA@mail.gmail.com>

FWIW my inclination is to just change the existing signatures.  6.0 is a
major release with major changes already wrt querying.


On Tue, Dec 27, 2016 at 3:01 PM Steve Ebersole <steve at hibernate.org> wrote:

> For 6.0 I'd like to also make ScrollableResults parameterized wrt the "row
> type".  E.g.
>
> ScrollableResults<Person> sr = session.createQuery( ..., Person.class
> ).scroll();
>
> However that changes the signature of its methods returning a "row"
> (currently always defined as Object[]).
>
> How would everyone prefer we handle this?  Do I just change the signatures
> of the existing methods?  Or add new methods?
>

From milo at vanderzee.org  Tue Dec 27 17:05:33 2016
From: milo at vanderzee.org (Milo van der Zee)
Date: Tue, 27 Dec 2016 23:05:33 +0100
Subject: [hibernate-dev] Preventing duplicate ForeignKey generation
Message-ID: <eba04f1d-3cc8-ccbe-2c86-81364cb35e4c@vanderzee.org>

Hello all,

During development of applications I'm used to set the schema creation 
to 'update' (hbm2ddl.auto = update). This makes life a bit easier.
Issue with the newer version of Hibernate is that the name of the 
generated keys changed and so all keys are regenerated. For the large 
databases I use this takes hours and has to be done every time a fresh 
copy from production is taken to the development environment.

I do use meaningful names for the indexes where possible. But when using 
abstract classes used by the entities that is not possible because the 
same fields from the abstract are used by many entity classes and so 
would end up having the same index names.

I checked the code that decides if the index needs to be created and 
found that it only checks the name of the index. Not what the index 
actually does. This is why I changed that piece of code to be a bit 
smarter. It is desinged for simple constraints from one column to 
another column. Not for multi to multi column indexes and constraints.

I created a Jira issue for it but nobody notices it and there are no 
comments or anything else. So now I try it here :)
Jira HHH-10934 (https://hibernate.atlassian.net/browse/HHH-10934)

Code fragment I put in SchemaMigratorImpl.java:

private  ForeignKeyInformation findMatchingForeignKey(ForeignKey foreignKey, TableInformation tableInformation) {
	if  (foreignKey.getName() ==null) {
		return  null;
	}

	/*
	 * Find existing keys based on referencing column and referencedTable
	 */
	String  referencingColumn = foreignKey.getColumn(0).getName();
	String  referencedTableName = foreignKey.getReferencedTable().getName();
	Iterable<ForeignKeyInformation> existingForeignKeys = tableInformation.getForeignKeys();
	for  (ForeignKeyInformation existingKey : existingForeignKeys) {
		Iterable<ColumnReferenceMapping> columnReferenceMappings = existingKey.getColumnReferenceMappings();
		for  (ColumnReferenceMapping mapping : columnReferenceMappings) {
			String  existingReferencingColumn = mapping.getReferencingColumnMetadata().getColumnIdentifier().getText();
			String  existingReferencedTableName = mapping.getReferencedColumnMetadata().getContainingTableInformation().getName().getTableName().getCanonicalName();
			if  (referencingColumn.equals(existingReferencingColumn) && referencedTableName.equals(existingReferencedTableName)) {
				return  existingKey;
			}
		}
	}

	// If not yet found check based on key name 	return  tableInformation.getForeignKey(Identifier.toIdentifier(foreignKey.getName()));
}

Or if you prever the Java 8 way:

private  ForeignKeyInformation findMatchingForeignKey(ForeignKey foreignKey, TableInformation tableInformation) {
	log.debug("findMatchingForeignKey");
	if  (foreignKey.getName() ==null)return  null;

	/*
	 * Find existing keys based on referencing column and referencedTable
	 */
	String  referencingColumn = foreignKey.getColumn(0).getName();
	String  referencedTableName = foreignKey.getReferencedTable().getName();
	Predicate<ColumnReferenceMapping> mappingPredicate = m -> referencingColumn.equals(m.getReferencingColumnMetadata().getColumnIdentifier().getText())
			&& referencedTableName.equals(m.getReferencedColumnMetadata().getContainingTableInformation().getName().getTableName().getCanonicalName());
	for  (ForeignKeyInformation existingKey : tableInformation.getForeignKeys()) {
		boolean  found = StreamSupport.stream(existingKey.getColumnReferenceMappings().spliterator(),false).anyMatch(mappingPredicate);
		if  (found)return  existingKey;
	}

	// If not yet found check based on key name 	return  tableInformation.getForeignKey(Identifier.toIdentifier(foreignKey.getName()));
}

The calling method does not use the returned value. It only checks if 
the returned value is null or not. So this could also be cleaned by 
changing the method to return a boolean and then remove the for loop in 
java-8 and use flatmap. But first let us agree on the validity of the 
idea to change this piece of code.

I hope anybody would like to have a look at it and if there is any 
change that the idea (not this actual very quick/dirty implementation) 
goes into the system I'll clean it up and do some actual tests for more 
complex database structures. I did not even check the junit tests yet.
At the moment it is good enough for me but I think it could be something 
more people would benefit from.

Thanks,
Milo van der Zee



From davide at hibernate.org  Tue Dec 27 20:04:02 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 28 Dec 2016 01:04:02 +0000
Subject: [hibernate-dev] CI Jenkins upgraded to version 2.38
Message-ID: <CANoTJYN5qyUb3V+R8tVLQn4+fQT+97hb5KotU9o9ELgoDOpHEQ@mail.gmail.com>

Hi,
I hope you all had great holidays.

I've upgraded our Jenkin on CI to version 2.38.

As far as i can tell everything seems all right, but if you experience
some unusual problems,
please, let me know.


Cheers,
Davide

From steve at hibernate.org  Thu Dec 29 11:20:28 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 29 Dec 2016 16:20:28 +0000
Subject: [hibernate-dev] AttributeConverter - 6.0
Message-ID: <CAFdSV9s_+qQDEzDC2gV16RBYfM6vP2Og8DOT5UNeKrhO015-FQ@mail.gmail.com>

When I first added support for AttributeConverter I incorporated it into
BasicType because that was really the only option at the time.

As we move into 6.0 though I would like to consider moving this to the new
Attribute model.  What this means practically speaking is that we'd
move AttributeConverter from the definition of BasicType and instead move
it to select "domain model reference nodes" identified by a
new ConvertibleDomainReference interface.  This is already developed
initially in the 6.0 wip where basic singular attributes, basic collection
indexes and basic collection elements are all considered
ConvertibleDomainReferences.

This work so far only makes the AttributeConverters available
via ConvertibleDomainReference; it does not apply AttributeConverters
via ConvertibleDomainReference.  That would be the next step if we decide
to go this route.

Additionally, this would mean that BasicType would no longer contain the
AttributeConverter; BasicType then would be the composition of:

   1. JavaTypeDescriptor
   2. SqlTypeDescriptor
   3. MutabilityPlan

But even MutabilityPlan... I wonder if that should move to the Attribute
model as well?

Anyway, please let me know what y'all think of these open questions asap as
I'd like to start nailing down the Type SPIs for an Alpha.

From sanne at hibernate.org  Thu Dec 29 18:37:51 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 29 Dec 2016 23:37:51 +0000
Subject: [hibernate-dev] CI Jenkins upgraded to version 2.38
In-Reply-To: <CANoTJYN5qyUb3V+R8tVLQn4+fQT+97hb5KotU9o9ELgoDOpHEQ@mail.gmail.com>
References: <CANoTJYN5qyUb3V+R8tVLQn4+fQT+97hb5KotU9o9ELgoDOpHEQ@mail.gmail.com>
Message-ID: <CAFm4XO1HME=dc-vDXmG=DKJ5XUsCatJ84+BZqksBUP5gKK4haA@mail.gmail.com>

Thanks Davide!
The builds seems to work just fine, the only minor defect I've noticed
is with the stylesheet doing some strange things when scrolling down:
the breadcrumbs will "float" down as well. Definitely not urgent,
great to have all updates!

Thanks,
Sanne


On 28 December 2016 at 01:04, Davide D'Alto <davide at hibernate.org> wrote:
> Hi,
> I hope you all had great holidays.
>
> I've upgraded our Jenkin on CI to version 2.38.
>
> As far as i can tell everything seems all right, but if you experience
> some unusual problems,
> please, let me know.
>
>
> Cheers,
> Davide
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Sat Dec 31 09:25:25 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 31 Dec 2016 14:25:25 +0000
Subject: [hibernate-dev] 6.0 - Query literal rendering
Message-ID: <CAFdSV9sO2qi55cDfs4n9Ho06dpmT6Ma22tF12owPYwfHsYp2xw@mail.gmail.com>

Currently in 6.0 I have code in place to render query literals as
PreparedStatement parameters, but only outside the SELECT clause.  Many DBs
require special handling for parameters defined in the SELECT clause
general requiring to wrap in cast functions calls.

I think it may be beneficial to allow the user to control this via a
setting.  Specifically a multi-valued (enum) value with the following
possibility set:

   1. NEVER
   2. ALWAYS
   3. OUTSIDE_SELECT

First, does anyone have an issue with this proposal?  Secondly does anyone
see other concerns that should be take into account?

From steve at hibernate.org  Sat Dec 31 15:00:05 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 31 Dec 2016 20:00:05 +0000
Subject: [hibernate-dev] 6.0 - Session#createFilter
Message-ID: <CAFdSV9u-oRQLd7R+iA58OO9uuierC=RyA=_cjxRNtztHyQFRwg@mail.gmail.com>

As I have not been hearing hardly any feedback on these 6.0 design
questions I have been trying to start, I'll be doing something different in
this and any additional emails.. I'll state what I propose to do and if
anyone has issue with it they can make a counter proposal.  Otherwise I
plan on following through with my proposal.

I plan on removing Session#createFilter.  There are numerous reasons why
which I can discuss if anyone is interested in exploring this.

Ultimately I think it makes sense to handle this via Java 8 streams[1]
although I am not sure that needs to happen in 6.0

[1] https://hibernate.atlassian.net/browse/HHH-10962