From andrea at hibernate.org  Fri Jul  1 04:13:36 2016
From: andrea at hibernate.org (andrea boriero)
Date: Fri, 1 Jul 2016 10:13:36 +0200
Subject: [hibernate-dev] Hibernate ORM 5.0.9.Final has been released
Message-ID: <CAL00eSQE8vuvNuGGTgyTQLgQzRbK1ppBL2QOdfp0m6JofzT49Q@mail.gmail.com>

For details:
http://in.relation.to/2016/06/30/hibernate-orm-521-final-release/

From sanne at hibernate.org  Fri Jul  1 04:16:42 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 1 Jul 2016 09:16:42 +0100
Subject: [hibernate-dev] Hibernate ORM 5.0.9.Final has been released
In-Reply-To: <CAL00eSQE8vuvNuGGTgyTQLgQzRbK1ppBL2QOdfp0m6JofzT49Q@mail.gmail.com>
References: <CAL00eSQE8vuvNuGGTgyTQLgQzRbK1ppBL2QOdfp0m6JofzT49Q@mail.gmail.com>
Message-ID: <CAFm4XO0K_=borXGsX_yrrEtQ+6qL2xp=RkzpU6eB2QBtbixYcQ@mail.gmail.com>

Hi Andrea,
the email subject mentions 5.0.9, the blog talks about 5.2.1 .. did we
release both?

Thanks,
Sanne

On 1 July 2016 at 09:13, andrea boriero <andrea at hibernate.org> wrote:
> For details:
> http://in.relation.to/2016/06/30/hibernate-orm-521-final-release/
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From andrea at hibernate.org  Fri Jul  1 04:18:25 2016
From: andrea at hibernate.org (andrea boriero)
Date: Fri, 1 Jul 2016 10:18:25 +0200
Subject: [hibernate-dev] Hibernate ORM 5.2.1.Final has been released
Message-ID: <CAL00eSSmhSL4bio3=fmW7iqzw6kyutvk2mmkyGPX=ZSMXugoEA@mail.gmail.com>

sorry for the previous wrong  subject,

Hibernate ORM 5.2.1.Final has been released

For details:
http://in.relation.to/2016/06/30/hibernate-orm-521-final-release/

From andrea at hibernate.org  Fri Jul  1 04:19:32 2016
From: andrea at hibernate.org (andrea boriero)
Date: Fri, 1 Jul 2016 10:19:32 +0200
Subject: [hibernate-dev] Hibernate ORM 5.0.9.Final has been released
In-Reply-To: <CAFm4XO0K_=borXGsX_yrrEtQ+6qL2xp=RkzpU6eB2QBtbixYcQ@mail.gmail.com>
References: <CAL00eSQE8vuvNuGGTgyTQLgQzRbK1ppBL2QOdfp0m6JofzT49Q@mail.gmail.com>
	<CAFm4XO0K_=borXGsX_yrrEtQ+6qL2xp=RkzpU6eB2QBtbixYcQ@mail.gmail.com>
Message-ID: <CAL00eSRvoMqfdF_DeZ=WHAas+SvdgghNXZP1v_9q++fQC5H10g@mail.gmail.com>

i have just realized and sent a new message with the correct subject.

Thanks

On 1 July 2016 at 10:16, Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Andrea,
> the email subject mentions 5.0.9, the blog talks about 5.2.1 .. did we
> release both?
>
> Thanks,
> Sanne
>
> On 1 July 2016 at 09:13, andrea boriero <andrea at hibernate.org> wrote:
> > For details:
> > http://in.relation.to/2016/06/30/hibernate-orm-521-final-release/
> > _______________________________________________
> > 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 Jul  1 04:29:17 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 1 Jul 2016 11:29:17 +0300
Subject: [hibernate-dev] Hibernate ORM 5.0.9.Final has been released
In-Reply-To: <CAL00eSRvoMqfdF_DeZ=WHAas+SvdgghNXZP1v_9q++fQC5H10g@mail.gmail.com>
References: <CAL00eSQE8vuvNuGGTgyTQLgQzRbK1ppBL2QOdfp0m6JofzT49Q@mail.gmail.com>
	<CAFm4XO0K_=borXGsX_yrrEtQ+6qL2xp=RkzpU6eB2QBtbixYcQ@mail.gmail.com>
	<CAL00eSRvoMqfdF_DeZ=WHAas+SvdgghNXZP1v_9q++fQC5H10g@mail.gmail.com>
Message-ID: <CA+gWKMA+c-j+Da_8ZRCBvboF5k0ajw8QKEwrwppLEN020mu4Ag@mail.gmail.com>

Congrats, Andrea for the release.

Vlad

On Fri, Jul 1, 2016 at 11:19 AM, andrea boriero <andrea at hibernate.org>
wrote:

> i have just realized and sent a new message with the correct subject.
>
> Thanks
>
> On 1 July 2016 at 10:16, Sanne Grinovero <sanne at hibernate.org> wrote:
>
> > Hi Andrea,
> > the email subject mentions 5.0.9, the blog talks about 5.2.1 .. did we
> > release both?
> >
> > Thanks,
> > Sanne
> >
> > On 1 July 2016 at 09:13, andrea boriero <andrea at hibernate.org> wrote:
> > > For details:
> > > http://in.relation.to/2016/06/30/hibernate-orm-521-final-release/
> > > _______________________________________________
> > > 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 Jul  1 15:17:18 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 01 Jul 2016 19:17:18 +0000
Subject: [hibernate-dev] EnhancementContext and HHH-10801
In-Reply-To: <CAFDzhiSuvM7z7dinKUso3+XX3iBX+ZwtOzhGffzjY7KCbj7iaw@mail.gmail.com>
References: <CAFDzhiSuvM7z7dinKUso3+XX3iBX+ZwtOzhGffzjY7KCbj7iaw@mail.gmail.com>
Message-ID: <CAFdSV9ueLCJWfhpnS6FUmhS5QVA88wdYJTfaPH2Ct3S=Z+Ps8Q@mail.gmail.com>

As it is an addition of a method to an SPI interface, then no it will not
be breaking applications.

It may or may not affect integrations.  The only implementations of
EnhancementContext
I know of are our implementations.  So,  certainly you could say that it
potentially breaks integrations.  But afaik it is only our implementations
of these things that fall under your label of support.


On Thu, Jun 30, 2016 at 12:07 AM Gail Badner <gbadner at redhat.com> wrote:

> The fix for HHH-10801 added a method,
> isMappedSuperclassClass(CtClass), to
> org.hibernate.bytecode.enhance.spi.EnhancementContext.
> [1]
>
> Would an application implement EnhancementContext? I don't see anything
> that would break, but I'd like to confirm before backporting HHH-10801 to
> 5.0 and 5.1.
>
> Thanks,
> Gail
>
> [1]
>
> https://github.com/hibernate/hibernate-orm/blob/cdc69a475bb9f37a61e571950072eaf777086cae/hibernate-core/src/main/java/org/hibernate/bytecode/enhance/spi/EnhancementContext.java#L55
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Jul  1 16:15:46 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 01 Jul 2016 20:15:46 +0000
Subject: [hibernate-dev] HHH-10888
In-Reply-To: <CAFDzhiTNOX4Bsi1i8pQLAfp=pNmM5_PGnm6Ax+kHP7ikrvQhRg@mail.gmail.com>
References: <CAFDzhiTNOX4Bsi1i8pQLAfp=pNmM5_PGnm6Ax+kHP7ikrvQhRg@mail.gmail.com>
Message-ID: <CAFdSV9vNUnE36chvVBW4xM2sYwnXBqMip8kBsabsqC832vKsbQ@mail.gmail.com>

I think that is just an oversight back to the original impl of the JPA
metamodel.  I cannot speak for the tests.  I can definitely see the
argument for PluralAttribute#isAssociation logically returning false for @
ElementCollection.

The spec is very unclear about it unfortunately.  WRT entities actually the
term I see more often in the spec is "relationship".

Personally I logically segment collections exactly the way you suggest,
so +1 from me.  The only really consideration I guess is compatibility.
But still, +1 from me.

On Thu, Jun 23, 2016 at 4:37 PM Gail Badner <gbadner at redhat.com> wrote:

> Currently, Hibernate's implementation of
> javax.persistence.metamodel.PluralAttribute#isAssociation always returns
> true. I haven't found anything in JSR 338 (yet) that refers to an element
> collection as an association.
>
> I don't see a good definition of "association", but the term is used with
> respect to entities. I also see examples of @ElementCollection with
> @AttributeOverride, but none with @AssociationOverride.
>
> The change suggested in HHH-10888 is to have
> PluralAttributeImpl#isAssociation return true only for one-to-many and
> many-to-many. I believe this is correct, but it breaks a couple of tests
> that specifically check if an element collection is an association.
>
> I wanted to pass this by you in case I'm missing something here.
>
> Please take a look at the pull request to see the fix and the required
> test changes. [1]
>
> Thanks,
> Gail
>
> https://github.com/hibernate/hibernate-orm/pull/1447
>

From gunnar at hibernate.org  Fri Jul  1 16:29:53 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 1 Jul 2016 22:29:53 +0200
Subject: [hibernate-dev] Hibernate ORM 5.0.9.Final has been released
In-Reply-To: <CA+gWKMA+c-j+Da_8ZRCBvboF5k0ajw8QKEwrwppLEN020mu4Ag@mail.gmail.com>
References: <CAL00eSQE8vuvNuGGTgyTQLgQzRbK1ppBL2QOdfp0m6JofzT49Q@mail.gmail.com>
	<CAFm4XO0K_=borXGsX_yrrEtQ+6qL2xp=RkzpU6eB2QBtbixYcQ@mail.gmail.com>
	<CAL00eSRvoMqfdF_DeZ=WHAas+SvdgghNXZP1v_9q++fQC5H10g@mail.gmail.com>
	<CA+gWKMA+c-j+Da_8ZRCBvboF5k0ajw8QKEwrwppLEN020mu4Ag@mail.gmail.com>
Message-ID: <CADGJaX91y5u9r_pHg4Ka6WdVP9fh2z19eQ7gSkJ_gubZ0EY64Q@mail.gmail.com>

People on Reddit complain that they cannot see the list of resolved issues
without being logged into JIRA:
https://www.reddit.com/r/java/comments/4qqo8p/hibernate_orm_521_has_been_released/
.

Can we make that change log visible without the need for an account?
Otherwise it's very hard for people to find out what has changed, esp. as
the release announcement itself doesn't provide any hints. IMHO it'd be
nice if a few highlights were described there.

--Gunnar


2016-07-01 10:29 GMT+02:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:

> Congrats, Andrea for the release.
>
> Vlad
>
> On Fri, Jul 1, 2016 at 11:19 AM, andrea boriero <andrea at hibernate.org>
> wrote:
>
> > i have just realized and sent a new message with the correct subject.
> >
> > Thanks
> >
> > On 1 July 2016 at 10:16, Sanne Grinovero <sanne at hibernate.org> wrote:
> >
> > > Hi Andrea,
> > > the email subject mentions 5.0.9, the blog talks about 5.2.1 .. did we
> > > release both?
> > >
> > > Thanks,
> > > Sanne
> > >
> > > On 1 July 2016 at 09:13, andrea boriero <andrea at hibernate.org> wrote:
> > > > For details:
> > > > http://in.relation.to/2016/06/30/hibernate-orm-521-final-release/
> > > > _______________________________________________
> > > > 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  Fri Jul  1 16:46:57 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 01 Jul 2016 20:46:57 +0000
Subject: [hibernate-dev] Hibernate ORM 5.0.9.Final has been released
In-Reply-To: <CADGJaX91y5u9r_pHg4Ka6WdVP9fh2z19eQ7gSkJ_gubZ0EY64Q@mail.gmail.com>
References: <CAL00eSQE8vuvNuGGTgyTQLgQzRbK1ppBL2QOdfp0m6JofzT49Q@mail.gmail.com>
	<CAFm4XO0K_=borXGsX_yrrEtQ+6qL2xp=RkzpU6eB2QBtbixYcQ@mail.gmail.com>
	<CAL00eSRvoMqfdF_DeZ=WHAas+SvdgghNXZP1v_9q++fQC5H10g@mail.gmail.com>
	<CA+gWKMA+c-j+Da_8ZRCBvboF5k0ajw8QKEwrwppLEN020mu4Ag@mail.gmail.com>
	<CADGJaX91y5u9r_pHg4Ka6WdVP9fh2z19eQ7gSkJ_gubZ0EY64Q@mail.gmail.com>
Message-ID: <CAFdSV9vuCikOPHP-h22NwmiP=RUdE-+tRuOFUQxddJ43a8tTVA@mail.gmail.com>

That is an ongoing argument with Atlassian.  So yes, there is a way.  It
means disabling the GitHub integration.  I personally find the solution
worse than the problem.  Also realize that it is always available via the
SCM'ed changelog file:
https://github.com/hibernate/hibernate-orm/blob/master/changelog.txt


On Fri, Jul 1, 2016 at 3:30 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> People on Reddit complain that they cannot see the list of resolved issues
> without being logged into JIRA:
>
> https://www.reddit.com/r/java/comments/4qqo8p/hibernate_orm_521_has_been_released/
> .
>
> Can we make that change log visible without the need for an account?
> Otherwise it's very hard for people to find out what has changed, esp. as
> the release announcement itself doesn't provide any hints. IMHO it'd be
> nice if a few highlights were described there.
>
> --Gunnar
>
>
> 2016-07-01 10:29 GMT+02:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
>
> > Congrats, Andrea for the release.
> >
> > Vlad
> >
> > On Fri, Jul 1, 2016 at 11:19 AM, andrea boriero <andrea at hibernate.org>
> > wrote:
> >
> > > i have just realized and sent a new message with the correct subject.
> > >
> > > Thanks
> > >
> > > On 1 July 2016 at 10:16, Sanne Grinovero <sanne at hibernate.org> wrote:
> > >
> > > > Hi Andrea,
> > > > the email subject mentions 5.0.9, the blog talks about 5.2.1 .. did
> we
> > > > release both?
> > > >
> > > > Thanks,
> > > > Sanne
> > > >
> > > > On 1 July 2016 at 09:13, andrea boriero <andrea at hibernate.org>
> wrote:
> > > > > For details:
> > > > > http://in.relation.to/2016/06/30/hibernate-orm-521-final-release/
> > > > > _______________________________________________
> > > > > hibernate-dev mailing list
> > > > > hibernate-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > >
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From davide at hibernate.org  Fri Jul  1 18:16:59 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Fri, 1 Jul 2016 23:16:59 +0100
Subject: [hibernate-dev] Hibernate ORM 5.0.9.Final has been released
In-Reply-To: <CAFdSV9vuCikOPHP-h22NwmiP=RUdE-+tRuOFUQxddJ43a8tTVA@mail.gmail.com>
References: <CAL00eSQE8vuvNuGGTgyTQLgQzRbK1ppBL2QOdfp0m6JofzT49Q@mail.gmail.com>
	<CAFm4XO0K_=borXGsX_yrrEtQ+6qL2xp=RkzpU6eB2QBtbixYcQ@mail.gmail.com>
	<CAL00eSRvoMqfdF_DeZ=WHAas+SvdgghNXZP1v_9q++fQC5H10g@mail.gmail.com>
	<CA+gWKMA+c-j+Da_8ZRCBvboF5k0ajw8QKEwrwppLEN020mu4Ag@mail.gmail.com>
	<CADGJaX91y5u9r_pHg4Ka6WdVP9fh2z19eQ7gSkJ_gubZ0EY64Q@mail.gmail.com>
	<CAFdSV9vuCikOPHP-h22NwmiP=RUdE-+tRuOFUQxddJ43a8tTVA@mail.gmail.com>
Message-ID: <CANoTJYMbaxx4KUzR+Zw1i9fBmQ5Eb74kSjkbcm38_zxbrN4UVw@mail.gmail.com>

Maybe we could create an easier to remember link to the changelog on
github, something like
http://orm.hibernate.org/changelog/5.2.1.Final


On Fri, Jul 1, 2016 at 9:46 PM, Steve Ebersole <steve at hibernate.org> wrote:
> That is an ongoing argument with Atlassian.  So yes, there is a way.  It
> means disabling the GitHub integration.  I personally find the solution
> worse than the problem.  Also realize that it is always available via the
> SCM'ed changelog file:
> https://github.com/hibernate/hibernate-orm/blob/master/changelog.txt
>
>
> On Fri, Jul 1, 2016 at 3:30 PM Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> People on Reddit complain that they cannot see the list of resolved issues
>> without being logged into JIRA:
>>
>> https://www.reddit.com/r/java/comments/4qqo8p/hibernate_orm_521_has_been_released/
>> .
>>
>> Can we make that change log visible without the need for an account?
>> Otherwise it's very hard for people to find out what has changed, esp. as
>> the release announcement itself doesn't provide any hints. IMHO it'd be
>> nice if a few highlights were described there.
>>
>> --Gunnar
>>
>>
>> 2016-07-01 10:29 GMT+02:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
>>
>> > Congrats, Andrea for the release.
>> >
>> > Vlad
>> >
>> > On Fri, Jul 1, 2016 at 11:19 AM, andrea boriero <andrea at hibernate.org>
>> > wrote:
>> >
>> > > i have just realized and sent a new message with the correct subject.
>> > >
>> > > Thanks
>> > >
>> > > On 1 July 2016 at 10:16, Sanne Grinovero <sanne at hibernate.org> wrote:
>> > >
>> > > > Hi Andrea,
>> > > > the email subject mentions 5.0.9, the blog talks about 5.2.1 .. did
>> we
>> > > > release both?
>> > > >
>> > > > Thanks,
>> > > > Sanne
>> > > >
>> > > > On 1 July 2016 at 09:13, andrea boriero <andrea at hibernate.org>
>> wrote:
>> > > > > For details:
>> > > > > http://in.relation.to/2016/06/30/hibernate-orm-521-final-release/
>> > > > > _______________________________________________
>> > > > > hibernate-dev mailing list
>> > > > > hibernate-dev at lists.jboss.org
>> > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > > >
>> > > _______________________________________________
>> > > hibernate-dev mailing list
>> > > hibernate-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Fri Jul  1 18:39:40 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 1 Jul 2016 23:39:40 +0100
Subject: [hibernate-dev] Hibernate ORM 5.0.9.Final has been released
In-Reply-To: <CANoTJYMbaxx4KUzR+Zw1i9fBmQ5Eb74kSjkbcm38_zxbrN4UVw@mail.gmail.com>
References: <CAL00eSQE8vuvNuGGTgyTQLgQzRbK1ppBL2QOdfp0m6JofzT49Q@mail.gmail.com>
	<CAFm4XO0K_=borXGsX_yrrEtQ+6qL2xp=RkzpU6eB2QBtbixYcQ@mail.gmail.com>
	<CAL00eSRvoMqfdF_DeZ=WHAas+SvdgghNXZP1v_9q++fQC5H10g@mail.gmail.com>
	<CA+gWKMA+c-j+Da_8ZRCBvboF5k0ajw8QKEwrwppLEN020mu4Ag@mail.gmail.com>
	<CADGJaX91y5u9r_pHg4Ka6WdVP9fh2z19eQ7gSkJ_gubZ0EY64Q@mail.gmail.com>
	<CAFdSV9vuCikOPHP-h22NwmiP=RUdE-+tRuOFUQxddJ43a8tTVA@mail.gmail.com>
	<CANoTJYMbaxx4KUzR+Zw1i9fBmQ5Eb74kSjkbcm38_zxbrN4UVw@mail.gmail.com>
Message-ID: <CAFm4XO0rNor1vp96DCHuTRj7OWcscrKxDb9fDFZsVhW1FxCJkw@mail.gmail.com>

We have several options, these alternatives work already:
 - https://hibernate.atlassian.net/issues/?jql=project%20%3D%20HHH%20AND%20fixVersion%20%3D%205.2.1
 - https://raw.githubusercontent.com/hibernate/hibernate-orm/5.2.1/changelog.txt

the second option is similar to Steve's proposal but pointing to the tag.

In addition on JIRA we can create a filter, which would be similar to
the first above but with a slightly more readable URL, at cost of
needing to create one at each release.


On 1 July 2016 at 23:16, Davide D'Alto <davide at hibernate.org> wrote:
> Maybe we could create an easier to remember link to the changelog on
> github, something like
> http://orm.hibernate.org/changelog/5.2.1.Final
>
>
> On Fri, Jul 1, 2016 at 9:46 PM, Steve Ebersole <steve at hibernate.org> wrote:
>> That is an ongoing argument with Atlassian.  So yes, there is a way.  It
>> means disabling the GitHub integration.  I personally find the solution
>> worse than the problem.  Also realize that it is always available via the
>> SCM'ed changelog file:
>> https://github.com/hibernate/hibernate-orm/blob/master/changelog.txt
>>
>>
>> On Fri, Jul 1, 2016 at 3:30 PM Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>>> People on Reddit complain that they cannot see the list of resolved issues
>>> without being logged into JIRA:
>>>
>>> https://www.reddit.com/r/java/comments/4qqo8p/hibernate_orm_521_has_been_released/
>>> .
>>>
>>> Can we make that change log visible without the need for an account?
>>> Otherwise it's very hard for people to find out what has changed, esp. as
>>> the release announcement itself doesn't provide any hints. IMHO it'd be
>>> nice if a few highlights were described there.
>>>
>>> --Gunnar
>>>
>>>
>>> 2016-07-01 10:29 GMT+02:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
>>>
>>> > Congrats, Andrea for the release.
>>> >
>>> > Vlad
>>> >
>>> > On Fri, Jul 1, 2016 at 11:19 AM, andrea boriero <andrea at hibernate.org>
>>> > wrote:
>>> >
>>> > > i have just realized and sent a new message with the correct subject.
>>> > >
>>> > > Thanks
>>> > >
>>> > > On 1 July 2016 at 10:16, Sanne Grinovero <sanne at hibernate.org> wrote:
>>> > >
>>> > > > Hi Andrea,
>>> > > > the email subject mentions 5.0.9, the blog talks about 5.2.1 .. did
>>> we
>>> > > > release both?
>>> > > >
>>> > > > Thanks,
>>> > > > Sanne
>>> > > >
>>> > > > On 1 July 2016 at 09:13, andrea boriero <andrea at hibernate.org>
>>> wrote:
>>> > > > > For details:
>>> > > > > http://in.relation.to/2016/06/30/hibernate-orm-521-final-release/
>>> > > > > _______________________________________________
>>> > > > > hibernate-dev mailing list
>>> > > > > hibernate-dev at lists.jboss.org
>>> > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > > >
>>> > > _______________________________________________
>>> > > hibernate-dev mailing list
>>> > > hibernate-dev at lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > >
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From davide at hibernate.org  Sat Jul  2 04:49:27 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Sat, 2 Jul 2016 09:49:27 +0100
Subject: [hibernate-dev] Hibernate ORM 5.0.9.Final has been released
In-Reply-To: <CAFm4XO0rNor1vp96DCHuTRj7OWcscrKxDb9fDFZsVhW1FxCJkw@mail.gmail.com>
References: <CAL00eSQE8vuvNuGGTgyTQLgQzRbK1ppBL2QOdfp0m6JofzT49Q@mail.gmail.com>
	<CAFm4XO0K_=borXGsX_yrrEtQ+6qL2xp=RkzpU6eB2QBtbixYcQ@mail.gmail.com>
	<CAL00eSRvoMqfdF_DeZ=WHAas+SvdgghNXZP1v_9q++fQC5H10g@mail.gmail.com>
	<CA+gWKMA+c-j+Da_8ZRCBvboF5k0ajw8QKEwrwppLEN020mu4Ag@mail.gmail.com>
	<CADGJaX91y5u9r_pHg4Ka6WdVP9fh2z19eQ7gSkJ_gubZ0EY64Q@mail.gmail.com>
	<CAFdSV9vuCikOPHP-h22NwmiP=RUdE-+tRuOFUQxddJ43a8tTVA@mail.gmail.com>
	<CANoTJYMbaxx4KUzR+Zw1i9fBmQ5Eb74kSjkbcm38_zxbrN4UVw@mail.gmail.com>
	<CAFm4XO0rNor1vp96DCHuTRj7OWcscrKxDb9fDFZsVhW1FxCJkw@mail.gmail.com>
Message-ID: <CANoTJYNAjoMF92Ez=Hgcefx=dLu0Mdbad70PF-gKJ++rAurCRw@mail.gmail.com>

This one works as well:
https://github.com/hibernate/hibernate-ogm/blob/5.0.1.Final/changelog.txt

We could also add the changelog link in the download page for each
release: http://hibernate.org/orm/downloads/

On Fri, Jul 1, 2016 at 11:39 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> We have several options, these alternatives work already:
>  - https://hibernate.atlassian.net/issues/?jql=project%20%3D%20HHH%20AND%20fixVersion%20%3D%205.2.1
>  - https://raw.githubusercontent.com/hibernate/hibernate-orm/5.2.1/changelog.txt
>
> the second option is similar to Steve's proposal but pointing to the tag.
>
> In addition on JIRA we can create a filter, which would be similar to
> the first above but with a slightly more readable URL, at cost of
> needing to create one at each release.
>
>
> On 1 July 2016 at 23:16, Davide D'Alto <davide at hibernate.org> wrote:
>> Maybe we could create an easier to remember link to the changelog on
>> github, something like
>> http://orm.hibernate.org/changelog/5.2.1.Final
>>
>>
>> On Fri, Jul 1, 2016 at 9:46 PM, Steve Ebersole <steve at hibernate.org> wrote:
>>> That is an ongoing argument with Atlassian.  So yes, there is a way.  It
>>> means disabling the GitHub integration.  I personally find the solution
>>> worse than the problem.  Also realize that it is always available via the
>>> SCM'ed changelog file:
>>> https://github.com/hibernate/hibernate-orm/blob/master/changelog.txt
>>>
>>>
>>> On Fri, Jul 1, 2016 at 3:30 PM Gunnar Morling <gunnar at hibernate.org> wrote:
>>>
>>>> People on Reddit complain that they cannot see the list of resolved issues
>>>> without being logged into JIRA:
>>>>
>>>> https://www.reddit.com/r/java/comments/4qqo8p/hibernate_orm_521_has_been_released/
>>>> .
>>>>
>>>> Can we make that change log visible without the need for an account?
>>>> Otherwise it's very hard for people to find out what has changed, esp. as
>>>> the release announcement itself doesn't provide any hints. IMHO it'd be
>>>> nice if a few highlights were described there.
>>>>
>>>> --Gunnar
>>>>
>>>>
>>>> 2016-07-01 10:29 GMT+02:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
>>>>
>>>> > Congrats, Andrea for the release.
>>>> >
>>>> > Vlad
>>>> >
>>>> > On Fri, Jul 1, 2016 at 11:19 AM, andrea boriero <andrea at hibernate.org>
>>>> > wrote:
>>>> >
>>>> > > i have just realized and sent a new message with the correct subject.
>>>> > >
>>>> > > Thanks
>>>> > >
>>>> > > On 1 July 2016 at 10:16, Sanne Grinovero <sanne at hibernate.org> wrote:
>>>> > >
>>>> > > > Hi Andrea,
>>>> > > > the email subject mentions 5.0.9, the blog talks about 5.2.1 .. did
>>>> we
>>>> > > > release both?
>>>> > > >
>>>> > > > Thanks,
>>>> > > > Sanne
>>>> > > >
>>>> > > > On 1 July 2016 at 09:13, andrea boriero <andrea at hibernate.org>
>>>> wrote:
>>>> > > > > For details:
>>>> > > > > http://in.relation.to/2016/06/30/hibernate-orm-521-final-release/
>>>> > > > > _______________________________________________
>>>> > > > > hibernate-dev mailing list
>>>> > > > > hibernate-dev at lists.jboss.org
>>>> > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> > > >
>>>> > > _______________________________________________
>>>> > > hibernate-dev mailing list
>>>> > > hibernate-dev at lists.jboss.org
>>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> > >
>>>> > _______________________________________________
>>>> > hibernate-dev mailing list
>>>> > hibernate-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>> _______________________________________________
>>> 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  Mon Jul  4 06:17:18 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 4 Jul 2016 12:17:18 +0200
Subject: [hibernate-dev] Fwd: Non-final dependencies in hibernate-core.gradle
In-Reply-To: <CADGJaX-vcVK--K_Za0kELKsRMdjg5jPkhfugfOxp4+rEDw-8sA@mail.gmail.com>
References: <CADGJaX-fYOLncM_GUoRBL6HPr4L8WCZYbsTqucHBohntkWqvYw@mail.gmail.com>
	<CAFdSV9tzZGDp_1s_zwpdbzH2b-UniP6YtwDZkPtWzmNscmrhNQ@mail.gmail.com>
	<CADGJaX-vcVK--K_Za0kELKsRMdjg5jPkhfugfOxp4+rEDw-8sA@mail.gmail.com>
Message-ID: <CADGJaX8ACXv5inCmoqHMT1HouiPdGUM8POsbCNOQeKUvKNR-qQ@mail.gmail.com>

Thanks for clarifying! Sent
https://github.com/hibernate/hibernate-orm/pull/1464 for updating these
versions.

--Gunnar


2016-06-30 15:02 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> That was just the latest when we updated those for JPA 2.1
>
> On Thu, Jun 30, 2016 at 6:02 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Hi,
>>
>> I noticed that a preview release of CDI is specified as dependency for the
>> ORM core module: "javax.enterprise:cdi-api:1.1-PFD [1].
>>
>> Is there a reason for using this specific one, or can we change it to the
>> Final (version "1.1")? Similarly for Weld
>> ("org.jboss.weld:weld-core:2.0.0.Beta6") and EJB API
>> ("org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:1.0.0.Alpha2").
>>
>> I can send a patch to change it, just wanted to be sure it's nothing
>> intentional.
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1]
>>
>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/hibernate-core.gradle#L68
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From davide at hibernate.org  Mon Jul  4 09:19:03 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Mon, 4 Jul 2016 14:19:03 +0100
Subject: [hibernate-dev] Hibernate OGM 5.0.1.Final released
Message-ID: <CANoTJYPzy0+e5M5FbSn8_2=84KpT5MBNa+Sg+A8Kkw90ZYk5fg@mail.gmail.com>

We released Hibernate OGM 5.0.1.Final!

What?s new?

Here some of the most interesting bug fixes and improvements in this release:

- OGM-818 - Autodetection support for @Entity annontated classes will now work
- OGM-356 - Object comparison in JPQL queries for MongoDB and Neo4j
(Thanks joexner!)
- OGM-1065 - You can now use Hibernate OGM with Cassandra 3

More information in the blog post:
http://in.relation.to/2016/07/04/hibernate-ogm-release-5

We are looking forward to hear your feedback,
Davide


From davide at hibernate.org  Tue Jul  5 10:00:26 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Tue, 5 Jul 2016 15:00:26 +0100
Subject: [hibernate-dev] NoORM IRC meeting transcripts
Message-ID: <CANoTJYPUfBTLKPWmc=sfEijiR5HWy6e=FF-vg2cufzd48Ka0WA@mail.gmail.com>

We discussed about:

- releasing OGM 5.1.0.Alpha1 with Neo4j Remote
- enabling the enforcer plugin for the Neo4j module now that the
Lucene dependency is aligned with the one in Hibernate Search
- the Hibernate ORM module ZIP and writing a blog post about it
- trying to have the HotRod dialect for OGM 5.1.0.Alpha2
- creating new CI nodes on a machine owned by Sanne
- a new account request for CentOS CI: https://ci.centos.org/

Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-07-05-13.07.html
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-07-05-13.07.txt
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-07-05-13.07.log.html


Davide

From sanne at hibernate.org  Tue Jul  5 12:57:22 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 5 Jul 2016 17:57:22 +0100
Subject: [hibernate-dev] Dropping "Serializable" requirement for IDs ?
Message-ID: <CAFm4XO3PZnxJO8UHfB4tKhF_Xp1KRe5NVOBJ-PwTrxr_mr29Gw@mail.gmail.com>

Hi all,
today creating a unit test I was greeted by this "old friend":

> org.hibernate.MappingException: Composite-id class must implement Serializable:

shall we get rid of this requirement?

It's just an inconvenience for end users to have to remember this
marker, as far as I know we don't really need this anymore.

I realise some code might still be needing this, but we probably can
do better by not actually serializing it with the default platform
serializer?

Just an idea for a potential 6.0 improvement..

Thanks,
Sanne

From steve at hibernate.org  Tue Jul  5 13:28:38 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 05 Jul 2016 17:28:38 +0000
Subject: [hibernate-dev] Dropping "Serializable" requirement for IDs ?
In-Reply-To: <CAFm4XO3PZnxJO8UHfB4tKhF_Xp1KRe5NVOBJ-PwTrxr_mr29Gw@mail.gmail.com>
References: <CAFm4XO3PZnxJO8UHfB4tKhF_Xp1KRe5NVOBJ-PwTrxr_mr29Gw@mail.gmail.com>
Message-ID: <CAFdSV9sOh4EJXwsBQfAv22unmwz-kmVhngDxAPK-dMZF-nTiog@mail.gmail.com>

I'm ok with this.  That is no longer a real requirement.

Any disagree?

On Tue, Jul 5, 2016, 11:58 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi all,
> today creating a unit test I was greeted by this "old friend":
>
> > org.hibernate.MappingException: Composite-id class must implement
> Serializable:
>
> shall we get rid of this requirement?
>
> It's just an inconvenience for end users to have to remember this
> marker, as far as I know we don't really need this anymore.
>
> I realise some code might still be needing this, but we probably can
> do better by not actually serializing it with the default platform
> serializer?
>
> Just an idea for a potential 6.0 improvement..
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From brett at hibernate.org  Tue Jul  5 15:12:07 2016
From: brett at hibernate.org (Brett Meyer)
Date: Tue, 5 Jul 2016 15:12:07 -0400
Subject: [hibernate-dev] Dropping "Serializable" requirement for IDs ?
In-Reply-To: <CAFdSV9sOh4EJXwsBQfAv22unmwz-kmVhngDxAPK-dMZF-nTiog@mail.gmail.com>
References: <CAFm4XO3PZnxJO8UHfB4tKhF_Xp1KRe5NVOBJ-PwTrxr_mr29Gw@mail.gmail.com>
	<CAFdSV9sOh4EJXwsBQfAv22unmwz-kmVhngDxAPK-dMZF-nTiog@mail.gmail.com>
Message-ID: <577C0687.4000208@hibernate.org>

+1 from me as well -- thanks for bringing that up, Sanne.

On 07/05/2016 01:28 PM, Steve Ebersole wrote:
> I'm ok with this.  That is no longer a real requirement.
>
> Any disagree?
>
> On Tue, Jul 5, 2016, 11:58 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>
>> Hi all,
>> today creating a unit test I was greeted by this "old friend":
>>
>>> org.hibernate.MappingException: Composite-id class must implement
>> Serializable:
>>
>> shall we get rid of this requirement?
>>
>> It's just an inconvenience for end users to have to remember this
>> marker, as far as I know we don't really need this anymore.
>>
>> I realise some code might still be needing this, but we probably can
>> do better by not actually serializing it with the default platform
>> serializer?
>>
>> Just an idea for a potential 6.0 improvement..
>>
>> 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 chris at hibernate.org  Tue Jul  5 15:24:22 2016
From: chris at hibernate.org (Chris Cranford)
Date: Tue, 5 Jul 2016 14:24:22 -0500
Subject: [hibernate-dev] Dropping "Serializable" requirement for IDs ?
In-Reply-To: <577C0687.4000208@hibernate.org>
References: <CAFm4XO3PZnxJO8UHfB4tKhF_Xp1KRe5NVOBJ-PwTrxr_mr29Gw@mail.gmail.com>
	<CAFdSV9sOh4EJXwsBQfAv22unmwz-kmVhngDxAPK-dMZF-nTiog@mail.gmail.com>
	<577C0687.4000208@hibernate.org>
Message-ID: <dd0c7b3a-cc2d-2ef8-b265-4ab647b4ba16@hibernate.org>

+1

On 07/05/2016 02:12 PM, Brett Meyer wrote:
> +1 from me as well -- thanks for bringing that up, Sanne.
>
> On 07/05/2016 01:28 PM, Steve Ebersole wrote:
>> I'm ok with this.  That is no longer a real requirement.
>>
>> Any disagree?
>>
>> On Tue, Jul 5, 2016, 11:58 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>>> Hi all,
>>> today creating a unit test I was greeted by this "old friend":
>>>
>>>> org.hibernate.MappingException: Composite-id class must implement
>>> Serializable:
>>>
>>> shall we get rid of this requirement?
>>>
>>> It's just an inconvenience for end users to have to remember this
>>> marker, as far as I know we don't really need this anymore.
>>>
>>> I realise some code might still be needing this, but we probably can
>>> do better by not actually serializing it with the default platform
>>> serializer?
>>>
>>> Just an idea for a potential 6.0 improvement..
>>>
>>> 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
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From emmanuel at hibernate.org  Wed Jul  6 12:49:24 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 6 Jul 2016 18:49:24 +0200
Subject: [hibernate-dev] Dropping "Serializable" requirement for IDs ?
In-Reply-To: <CAFdSV9sOh4EJXwsBQfAv22unmwz-kmVhngDxAPK-dMZF-nTiog@mail.gmail.com>
References: <CAFm4XO3PZnxJO8UHfB4tKhF_Xp1KRe5NVOBJ-PwTrxr_mr29Gw@mail.gmail.com>
	<CAFdSV9sOh4EJXwsBQfAv22unmwz-kmVhngDxAPK-dMZF-nTiog@mail.gmail.com>
Message-ID: <20160706164924.GG49312@hibernate.org>

+1, one less people will complain about :)

On Tue 2016-07-05 17:28, Steve Ebersole wrote:
> I'm ok with this.  That is no longer a real requirement.
> 
> Any disagree?
> 
> On Tue, Jul 5, 2016, 11:58 AM Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> > Hi all,
> > today creating a unit test I was greeted by this "old friend":
> >
> > > org.hibernate.MappingException: Composite-id class must implement
> > Serializable:
> >
> > shall we get rid of this requirement?
> >
> > It's just an inconvenience for end users to have to remember this
> > marker, as far as I know we don't really need this anymore.
> >
> > I realise some code might still be needing this, but we probably can
> > do better by not actually serializing it with the default platform
> > serializer?
> >
> > Just an idea for a potential 6.0 improvement..
> >
> > 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  Wed Jul  6 15:01:47 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 06 Jul 2016 19:01:47 +0000
Subject: [hibernate-dev] "matching" table/column names (and naming
	strategies)
Message-ID: <CAFdSV9vm3+y0Ggg+d5VxKt3hKiOcBG44O_Zbd6jmz1HvJUy7yw@mail.gmail.com>

This is something that has been bothering me for a long time.  HHH-6328[1]
is a specific example.  Basically we are very inconsistent in how we
attempt to match up table and column names, especially when there are
naming strategies involved.  We see this with secondary tables,
@org.hibernate.annotations.Table, etc.

Consider the following mapping:

@Entity
@Table( name="`USER`" )
class User {
    ...
}

The question is how they should refer to this table in other annotations
such as @Column or @org.hibernate.annotations.Table e.g.

And part of this gets to whether the implicit or physical naming strategies
should have any part in the matching process.  I think I am not a fan of
the mapping having to change just because they plug in a new naming
strategy.  So ideally I'd prefer that the naming strategies not take part
in this process.

I guess I just wanted to start a discussion about how to best deal with
this.

One option is that they need to match exactly (maybe with some simple
handling of quoted versus case-insensitive, similar to Identifier#equals
leveraging Identifier#getCanonicalName), e.g.:

@Entity
@Table( name="`USER`" )
@org.hibernate.annotations.Table( appliesTo="`USER`", ... )
class User {
    ...
}

I guess the first question here is whether we want to support referring to
implicit table names in other annotations at all.  JPA for the most part
discourages this; in order for a table name to be referenced in other
annotations it should be named explicitly.

Another option is to leverage the "logical name" (implicit or explicit) and
to apply a Identifier#equals-like check for matching.  This would however
lead to what I mentioned above wrt naming strategies playing a part in the
matching.  Consider we base matching on the logical name and that we have:

@Entity
@org.hibernate.annotations.Table( appliesTo="user", ... )
class User {
    ...
}

So this *might work* depending on the configured naming strategies.  But it
is also therefore highly dependent upon the naming strategies and changing
the naming strategy could conceivably cause the match to no longer find the
table.

A sort of hybrid approach between those 2 would be to use a specific
"matchable name determination strategy" (think JPA implicit naming rules).

At the very least, as HHH-6328 shows again, we really ought to stay away
from simple String comparisons.  Even a simple move to using Identifier for
the comparisons would help in that specific area.


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

From sanne at hibernate.org  Wed Jul  6 16:19:42 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 6 Jul 2016 21:19:42 +0100
Subject: [hibernate-dev] Dropping "Serializable" requirement for IDs ?
In-Reply-To: <20160706164924.GG49312@hibernate.org>
References: <CAFm4XO3PZnxJO8UHfB4tKhF_Xp1KRe5NVOBJ-PwTrxr_mr29Gw@mail.gmail.com>
	<CAFdSV9sOh4EJXwsBQfAv22unmwz-kmVhngDxAPK-dMZF-nTiog@mail.gmail.com>
	<20160706164924.GG49312@hibernate.org>
Message-ID: <CAFm4XO21714PUMfnjMX2vx=2oMCmNa8RJpLd86YccLKh5ybjiw@mail.gmail.com>

Tracked now as:
 - https://hibernate.atlassian.net/browse/HHH-10935

Thank you all!

On 6 July 2016 at 17:49, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> +1, one less people will complain about :)
>
> On Tue 2016-07-05 17:28, Steve Ebersole wrote:
>> I'm ok with this.  That is no longer a real requirement.
>>
>> Any disagree?
>>
>> On Tue, Jul 5, 2016, 11:58 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> > Hi all,
>> > today creating a unit test I was greeted by this "old friend":
>> >
>> > > org.hibernate.MappingException: Composite-id class must implement
>> > Serializable:
>> >
>> > shall we get rid of this requirement?
>> >
>> > It's just an inconvenience for end users to have to remember this
>> > marker, as far as I know we don't really need this anymore.
>> >
>> > I realise some code might still be needing this, but we probably can
>> > do better by not actually serializing it with the default platform
>> > serializer?
>> >
>> > Just an idea for a potential 6.0 improvement..
>> >
>> > 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 gunnar at hibernate.org  Wed Jul  6 17:10:16 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 6 Jul 2016 23:10:16 +0200
Subject: [hibernate-dev] Dropping "Serializable" requirement for IDs ?
In-Reply-To: <CAFm4XO21714PUMfnjMX2vx=2oMCmNa8RJpLd86YccLKh5ybjiw@mail.gmail.com>
References: <CAFm4XO3PZnxJO8UHfB4tKhF_Xp1KRe5NVOBJ-PwTrxr_mr29Gw@mail.gmail.com>
	<CAFdSV9sOh4EJXwsBQfAv22unmwz-kmVhngDxAPK-dMZF-nTiog@mail.gmail.com>
	<20160706164924.GG49312@hibernate.org>
	<CAFm4XO21714PUMfnjMX2vx=2oMCmNa8RJpLd86YccLKh5ybjiw@mail.gmail.com>
Message-ID: <CADGJaX_OVTgPcw=+20isaKb3pRYx1kGFuHXVRS31wG8iLNHE2w@mail.gmail.com>

Serializability of composite key types is mandated by the JPA spec, but I
suppose it's fine to be less strict in our implementation. Out of interest,
does anyone know why that requirement is part of the spec?

2016-07-06 22:19 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Tracked now as:
>  - https://hibernate.atlassian.net/browse/HHH-10935
>
> Thank you all!
>
> On 6 July 2016 at 17:49, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > +1, one less people will complain about :)
> >
> > On Tue 2016-07-05 17:28, Steve Ebersole wrote:
> >> I'm ok with this.  That is no longer a real requirement.
> >>
> >> Any disagree?
> >>
> >> On Tue, Jul 5, 2016, 11:58 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> > Hi all,
> >> > today creating a unit test I was greeted by this "old friend":
> >> >
> >> > > org.hibernate.MappingException: Composite-id class must implement
> >> > Serializable:
> >> >
> >> > shall we get rid of this requirement?
> >> >
> >> > It's just an inconvenience for end users to have to remember this
> >> > marker, as far as I know we don't really need this anymore.
> >> >
> >> > I realise some code might still be needing this, but we probably can
> >> > do better by not actually serializing it with the default platform
> >> > serializer?
> >> >
> >> > Just an idea for a potential 6.0 improvement..
> >> >
> >> > 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Jul  6 18:23:48 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 06 Jul 2016 22:23:48 +0000
Subject: [hibernate-dev] Dropping "Serializable" requirement for IDs ?
In-Reply-To: <CADGJaX_OVTgPcw=+20isaKb3pRYx1kGFuHXVRS31wG8iLNHE2w@mail.gmail.com>
References: <CAFm4XO3PZnxJO8UHfB4tKhF_Xp1KRe5NVOBJ-PwTrxr_mr29Gw@mail.gmail.com>
	<CAFdSV9sOh4EJXwsBQfAv22unmwz-kmVhngDxAPK-dMZF-nTiog@mail.gmail.com>
	<20160706164924.GG49312@hibernate.org>
	<CAFm4XO21714PUMfnjMX2vx=2oMCmNa8RJpLd86YccLKh5ybjiw@mail.gmail.com>
	<CADGJaX_OVTgPcw=+20isaKb3pRYx1kGFuHXVRS31wG8iLNHE2w@mail.gmail.com>
Message-ID: <CAFdSV9tJ9BcPWwR32H9-x8u_hsY2x_b_ZHFiJS8g=SWM57xABw@mail.gmail.com>

I believe the spec actually just says that the composite key class must be
serializable if the model is to be serialized (duh).  I could be
misremembering, but I believe that is right.

The spec does not say anything about the serializability of simple keys
because the spec severely limits id types (which are inherently
serializable).

For the most part, this is our requirement.

On Wed, Jul 6, 2016 at 4:10 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> Serializability of composite key types is mandated by the JPA spec, but I
> suppose it's fine to be less strict in our implementation. Out of interest,
> does anyone know why that requirement is part of the spec?
>
> 2016-07-06 22:19 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
> > Tracked now as:
> >  - https://hibernate.atlassian.net/browse/HHH-10935
> >
> > Thank you all!
> >
> > On 6 July 2016 at 17:49, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> > > +1, one less people will complain about :)
> > >
> > > On Tue 2016-07-05 17:28, Steve Ebersole wrote:
> > >> I'm ok with this.  That is no longer a real requirement.
> > >>
> > >> Any disagree?
> > >>
> > >> On Tue, Jul 5, 2016, 11:58 AM Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> > >>
> > >> > Hi all,
> > >> > today creating a unit test I was greeted by this "old friend":
> > >> >
> > >> > > org.hibernate.MappingException: Composite-id class must implement
> > >> > Serializable:
> > >> >
> > >> > shall we get rid of this requirement?
> > >> >
> > >> > It's just an inconvenience for end users to have to remember this
> > >> > marker, as far as I know we don't really need this anymore.
> > >> >
> > >> > I realise some code might still be needing this, but we probably can
> > >> > do better by not actually serializing it with the default platform
> > >> > serializer?
> > >> >
> > >> > Just an idea for a potential 6.0 improvement..
> > >> >
> > >> > 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
> > _______________________________________________
> > 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 Jul  6 18:27:53 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 06 Jul 2016 22:27:53 +0000
Subject: [hibernate-dev] Dropping "Serializable" requirement for IDs ?
In-Reply-To: <CAFdSV9tJ9BcPWwR32H9-x8u_hsY2x_b_ZHFiJS8g=SWM57xABw@mail.gmail.com>
References: <CAFm4XO3PZnxJO8UHfB4tKhF_Xp1KRe5NVOBJ-PwTrxr_mr29Gw@mail.gmail.com>
	<CAFdSV9sOh4EJXwsBQfAv22unmwz-kmVhngDxAPK-dMZF-nTiog@mail.gmail.com>
	<20160706164924.GG49312@hibernate.org>
	<CAFm4XO21714PUMfnjMX2vx=2oMCmNa8RJpLd86YccLKh5ybjiw@mail.gmail.com>
	<CADGJaX_OVTgPcw=+20isaKb3pRYx1kGFuHXVRS31wG8iLNHE2w@mail.gmail.com>
	<CAFdSV9tJ9BcPWwR32H9-x8u_hsY2x_b_ZHFiJS8g=SWM57xABw@mail.gmail.com>
Message-ID: <CAFdSV9v4BGKH1WJbzuToeNOaWqyGy0=7KSPhzyuT=4cEhOmXPA@mail.gmail.com>

Actually, I correct myself.  The spec does say that composite keys must be
Serializable (section 2.4).

I'd say that we cover this under our "portability/compliance guidelines"
like we do for other JPA requirements that we "softly" require.

On Wed, Jul 6, 2016 at 5:23 PM Steve Ebersole <steve at hibernate.org> wrote:

> I believe the spec actually just says that the composite key class must be
> serializable if the model is to be serialized (duh).  I could be
> misremembering, but I believe that is right.
>
> The spec does not say anything about the serializability of simple keys
> because the spec severely limits id types (which are inherently
> serializable).
>
> For the most part, this is our requirement.
>
> On Wed, Jul 6, 2016 at 4:10 PM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Serializability of composite key types is mandated by the JPA spec, but I
>> suppose it's fine to be less strict in our implementation. Out of
>> interest,
>> does anyone know why that requirement is part of the spec?
>>
>> 2016-07-06 22:19 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> > Tracked now as:
>> >  - https://hibernate.atlassian.net/browse/HHH-10935
>> >
>> > Thank you all!
>> >
>> > On 6 July 2016 at 17:49, Emmanuel Bernard <emmanuel at hibernate.org>
>> wrote:
>> > > +1, one less people will complain about :)
>> > >
>> > > On Tue 2016-07-05 17:28, Steve Ebersole wrote:
>> > >> I'm ok with this.  That is no longer a real requirement.
>> > >>
>> > >> Any disagree?
>> > >>
>> > >> On Tue, Jul 5, 2016, 11:58 AM Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> > >>
>> > >> > Hi all,
>> > >> > today creating a unit test I was greeted by this "old friend":
>> > >> >
>> > >> > > org.hibernate.MappingException: Composite-id class must implement
>> > >> > Serializable:
>> > >> >
>> > >> > shall we get rid of this requirement?
>> > >> >
>> > >> > It's just an inconvenience for end users to have to remember this
>> > >> > marker, as far as I know we don't really need this anymore.
>> > >> >
>> > >> > I realise some code might still be needing this, but we probably
>> can
>> > >> > do better by not actually serializing it with the default platform
>> > >> > serializer?
>> > >> >
>> > >> > Just an idea for a potential 6.0 improvement..
>> > >> >
>> > >> > 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
>> > _______________________________________________
>> > 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 andrea at hibernate.org  Thu Jul  7 04:57:49 2016
From: andrea at hibernate.org (andrea boriero)
Date: Thu, 7 Jul 2016 10:57:49 +0200
Subject: [hibernate-dev] "matching" table/column names (and naming
	strategies)
In-Reply-To: <CAFdSV9vm3+y0Ggg+d5VxKt3hKiOcBG44O_Zbd6jmz1HvJUy7yw@mail.gmail.com>
References: <CAFdSV9vm3+y0Ggg+d5VxKt3hKiOcBG44O_Zbd6jmz1HvJUy7yw@mail.gmail.com>
Message-ID: <CAL00eSSA+YPggegSEtsp99wiS+xPw_YPYh1VY5EJz8Qaj5v-gw@mail.gmail.com>

On 6 July 2016 at 21:01, Steve Ebersole <steve at hibernate.org> wrote:

> This is something that has been bothering me for a long time.  HHH-6328[1]
> is a specific example.  Basically we are very inconsistent in how we
> attempt to match up table and column names, especially when there are
> naming strategies involved.  We see this with secondary tables,
> @org.hibernate.annotations.Table, etc.
>
> Consider the following mapping:
>
> @Entity
> @Table( name="`USER`" )
> class User {
>     ...
> }
>
> The question is how they should refer to this table in other annotations
> such as @Column or @org.hibernate.annotations.Table e.g.
>
> And part of this gets to whether the implicit or physical naming strategies
> should have any part in the matching process.  I think I am not a fan of
> the mapping having to change just because they plug in a new naming
> strategy.  So ideally I'd prefer that the naming strategies not take part
> in this process.
>

I also prefer the mapping not to change based on the chosen naming strategy

>
> I guess I just wanted to start a discussion about how to best deal with
> this.
>
> One option is that they need to match exactly (maybe with some simple
> handling of quoted versus case-insensitive, similar to Identifier#equals
> leveraging Identifier#getCanonicalName), e.g.:
>
> @Entity
> @Table( name="`USER`" )
> @org.hibernate.annotations.Table( appliesTo="`USER`", ... )
> class User {
>     ...
> }
>
> I guess the first question here is whether we want to support referring to
> implicit table names in other annotations at all.  JPA for the most part
> discourages this; in order for a table name to be referenced in other
> annotations it should be named explicitly.
>
> In my opinion make sense not supporting implicit naming strategy.

What about comparing the names after having previously removed, if
presents, the quoting chars?

Another option is to leverage the "logical name" (implicit or explicit) and
> to apply a Identifier#equals-like check for matching.  This would however
> lead to what I mentioned above wrt naming strategies playing a part in the
> matching.  Consider we base matching on the logical name and that we have:
>
> @Entity
> @org.hibernate.annotations.Table( appliesTo="user", ... )
> class User {
>     ...
> }
>
> So this *might work* depending on the configured naming strategies.  But it
> is also therefore highly dependent upon the naming strategies and changing
> the naming strategy could conceivably cause the match to no longer find the
> table.
>

A sort of hybrid approach between those 2 would be to use a specific
> "matchable name determination strategy" (think JPA implicit naming rules).
>
> At the very least, as HHH-6328 shows again, we really ought to stay away
> from simple String comparisons.  Even a simple move to using Identifier for
> the comparisons would help in that specific area.
>
>
> [1] https://hibernate.atlassian.net/browse/HHH-6328
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Jul  7 09:43:49 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 07 Jul 2016 13:43:49 +0000
Subject: [hibernate-dev] "matching" table/column names (and naming
	strategies)
In-Reply-To: <CAL00eSSA+YPggegSEtsp99wiS+xPw_YPYh1VY5EJz8Qaj5v-gw@mail.gmail.com>
References: <CAFdSV9vm3+y0Ggg+d5VxKt3hKiOcBG44O_Zbd6jmz1HvJUy7yw@mail.gmail.com>
	<CAL00eSSA+YPggegSEtsp99wiS+xPw_YPYh1VY5EJz8Qaj5v-gw@mail.gmail.com>
Message-ID: <CAFdSV9v20hkP+BxeGs-fYqsAYzApfWh+7ziRAyDTfKmdtTGNRQ@mail.gmail.com>

On Thu, Jul 7, 2016 at 3:58 AM andrea boriero <andrea at hibernate.org> wrote:

> On 6 July 2016 at 21:01, Steve Ebersole <steve at hibernate.org> wrote:
>
>>
>> One option is that they need to match exactly (maybe with some simple
>> handling of quoted versus case-insensitive, similar to Identifier#equals
>> leveraging Identifier#getCanonicalName), e.g.:
>>
>> @Entity
>> @Table( name="`USER`" )
>> @org.hibernate.annotations.Table( appliesTo="`USER`", ... )
>> class User {
>>     ...
>> }
>>
>> I guess the first question here is whether we want to support referring to
>> implicit table names in other annotations at all.  JPA for the most part
>> discourages this; in order for a table name to be referenced in other
>> annotations it should be named explicitly.
>>
>> In my opinion make sense not supporting implicit naming strategy.
>

I was not so much asking about leveraging the ImplicitNamingStrategy.  More
I was asking conceptually whether we want to allow this at all.

What about comparing the names after having previously removed, if
> presents, the quoting chars?
>

Personally, I think using straight String comparisons is the main problem.
If you look at the code for Identifier#equals that is really exactly what
we need already.

We cannot just drop the quotes for an accurate comparison.  "`MY_TABLE`"
and "`my_table`" are different tables to each sane and SQL spec compliant
database.  But conversely "MY_TABLE" and "my_table" are the same table.

Overall though I think it is reasonable to just expect to match an explicit
name.  Especially if we allow org.hibernate.annotations.Table#appliesTo to
be empty like javax.persistence.Column#table, etc as a means to refer to
the root table.

From andrea at hibernate.org  Thu Jul  7 09:57:16 2016
From: andrea at hibernate.org (andrea boriero)
Date: Thu, 7 Jul 2016 15:57:16 +0200
Subject: [hibernate-dev] "matching" table/column names (and naming
	strategies)
In-Reply-To: <CAFdSV9v20hkP+BxeGs-fYqsAYzApfWh+7ziRAyDTfKmdtTGNRQ@mail.gmail.com>
References: <CAFdSV9vm3+y0Ggg+d5VxKt3hKiOcBG44O_Zbd6jmz1HvJUy7yw@mail.gmail.com>
	<CAL00eSSA+YPggegSEtsp99wiS+xPw_YPYh1VY5EJz8Qaj5v-gw@mail.gmail.com>
	<CAFdSV9v20hkP+BxeGs-fYqsAYzApfWh+7ziRAyDTfKmdtTGNRQ@mail.gmail.com>
Message-ID: <CAL00eSTLh-kQ6VQp==MRogqWqPn5KwcEF6rBrAtHvjsF6WyEpA@mail.gmail.com>

On 7 July 2016 at 15:43, Steve Ebersole <steve at hibernate.org> wrote:

> On Thu, Jul 7, 2016 at 3:58 AM andrea boriero <andrea at hibernate.org>
> wrote:
>
>> On 6 July 2016 at 21:01, Steve Ebersole <steve at hibernate.org> wrote:
>>
>>>
>>> One option is that they need to match exactly (maybe with some simple
>>> handling of quoted versus case-insensitive, similar to Identifier#equals
>>> leveraging Identifier#getCanonicalName), e.g.:
>>>
>>> @Entity
>>> @Table( name="`USER`" )
>>> @org.hibernate.annotations.Table( appliesTo="`USER`", ... )
>>> class User {
>>>     ...
>>> }
>>>
>>> I guess the first question here is whether we want to support referring
>>> to
>>> implicit table names in other annotations at all.  JPA for the most part
>>> discourages this; in order for a table name to be referenced in other
>>> annotations it should be named explicitly.
>>>
>>> In my opinion make sense not supporting implicit naming strategy.
>>
>
> I was not so much asking about leveraging the ImplicitNamingStrategy.
> More I was asking conceptually whether we want to allow this at all.
>

+1 for requiring explicitly naming tables and columns in order to be
referred in annotations.

>
> What about comparing the names after having previously removed, if
>> presents, the quoting chars?
>>
>
> Personally, I think using straight String comparisons is the main
> problem.  If you look at the code for Identifier#equals that is really
> exactly what we need already.
>
> We cannot just drop the quotes for an accurate comparison.  "`MY_TABLE`"
> and "`my_table`" are different tables to each sane and SQL spec compliant
> database.  But conversely "MY_TABLE" and "my_table" are the same table.
>

That's true, so if one or both names are quoted, we can remove the quoting
chars and do a case-sensitive comparison otherwise we we can do a
case-insensitive comparison, am I right?

>
> Overall though I think it is reasonable to just expect to match an
> explicit name.  Especially if we
> allow org.hibernate.annotations.Table#appliesTo to be empty
> like javax.persistence.Column#table, etc as a means to refer to the root
> table.
>
>

From steve at hibernate.org  Thu Jul  7 10:23:21 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 07 Jul 2016 14:23:21 +0000
Subject: [hibernate-dev] "matching" table/column names (and naming
	strategies)
In-Reply-To: <CAL00eSTLh-kQ6VQp==MRogqWqPn5KwcEF6rBrAtHvjsF6WyEpA@mail.gmail.com>
References: <CAFdSV9vm3+y0Ggg+d5VxKt3hKiOcBG44O_Zbd6jmz1HvJUy7yw@mail.gmail.com>
	<CAL00eSSA+YPggegSEtsp99wiS+xPw_YPYh1VY5EJz8Qaj5v-gw@mail.gmail.com>
	<CAFdSV9v20hkP+BxeGs-fYqsAYzApfWh+7ziRAyDTfKmdtTGNRQ@mail.gmail.com>
	<CAL00eSTLh-kQ6VQp==MRogqWqPn5KwcEF6rBrAtHvjsF6WyEpA@mail.gmail.com>
Message-ID: <CAFdSV9ub1+i1Lo49xDozzNrLQ=O0dFHaAL43vxHV+Q2kyX-vVw@mail.gmail.com>

>
> Personally, I think using straight String comparisons is the main
>> problem.  If you look at the code for Identifier#equals that is really
>> exactly what we need already.
>>
>> We cannot just drop the quotes for an accurate comparison.  "`MY_TABLE`"
>> and "`my_table`" are different tables to each sane and SQL spec compliant
>> database.  But conversely "MY_TABLE" and "my_table" are the same table.
>>
>
> That's true, so if one or both names are quoted, we can remove the quoting
> chars and do a case-sensitive comparison otherwise we we can do a
> case-insensitive comparison, am I right?
>

Correct.  That is more or less what Identifier#equals does, although atm in
the interest of simplicity it simply leverages the
Identifier#getCanonicalName of the 2 Identifiers to perform the
comparison.  Identifier#getCanonicalName lowercases the name if not quoted,
and then #equals compares that return.

We should really adjust this however as it can lead to false positive
hits.  Consider comparing "`my_table`" and "my_table" which really ought to
evaluate to not-equal[1].  However the canonical name in both cases is the
same ("my_table") and so would evaluate to equal.

[1] I believe this is database dependent - whether a quoted and non-quoted
identifier can ever refer to the same database/schema object.

From steve at hibernate.org  Fri Jul  8 11:16:40 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 08 Jul 2016 15:16:40 +0000
Subject: [hibernate-dev] Starting 5.1.0 release
In-Reply-To: <CAFdSV9twvXxAUWhUXj1KFz7iHGR6FAka-RM3cd2BCBJ5j5HmHg@mail.gmail.com>
References: <CAFdSV9sW8Oe5ANEed+Y1Z-uw=wYNk2vZKKGwYX8PWsz372Y83A@mail.gmail.com>
	<CAFdSV9vp-txdwSyLizMEn9-cLz8Dw87Zf__zYRUtOatPFDZLkQ@mail.gmail.com>
	<CAFm4XO0q2BgFF3otmogGMnwHJnUX6iQx9KFMZ6KzsAJ5xSKCpQ@mail.gmail.com>
	<CA+gWKMCPyuZtHni3ZsyVP0O3VaDSrsdRWJ+XeEFxg2s=ek=GZg@mail.gmail.com>
	<CAFdSV9t9wjfzzoNTDhK_9GJHbmx_mSoFoW+=pXqmPsz1XTmiYQ@mail.gmail.com>
	<CA+gWKMBtJpn41Cx_zCOP8Z7T6zZem4yGAt8uUXbzLEp3-CENBA@mail.gmail.com>
	<CAFdSV9vR5XdBSGo=d_h7_SfaTAz=xDwAQ3qiSUAJH3VZimNxpg@mail.gmail.com>
	<CAFdSV9sDNVXo=SOca8VMNJT_qPPEci=0jJO_im3aEqEYN-H6wg@mail.gmail.com>
	<CAFdSV9tMW3f5JBdM-is30fC-azCLa43fj7XtjZ0uDVoDA975mQ@mail.gmail.com>
	<CAFdSV9twvXxAUWhUXj1KFz7iHGR6FAka-RM3cd2BCBJ5j5HmHg@mail.gmail.com>
Message-ID: <CAFdSV9tNx9sOqfNNGfwyYHCrAX2=-01V86XFrXkTQYrZ86Z4vg@mail.gmail.com>

Reviving this to finish the discussion about creation of the `current`
symlink...

I think we can actually script this update to the `current` symlink.  We'd
simply limit the creation (and thus transfer) of the symlink when we do a
release that ends in "0.Final" (maybe for CR releases too).  For
example: 5.2.0.Final,
6.0.0.Final, 6.1.0.Final, etc.

WDYT?


On Wed, Feb 10, 2016 at 4:25 PM Steve Ebersole <steve at hibernate.org> wrote:

> Maybe the better option is to have the build simply upload to the
> versioned docs dir (orm/5.0, orm/5.1, etc) and to manage the `current`
> symlink by hand.  That really only needs to change when the next feature
> release becomes stable.
>
>
> On Wed, Feb 10, 2016 at 1:40 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I fixed the symlinks on the doc server as follows:
>>
>>    1. created a `/orm/current` symlink pointing to `/orm/5.1`
>>    2. updated `/stable/orm` to point to `/orm/current`
>>    3. updated `/stable/core` to point to `/stable/orm` (I could not
>>    remember what it pointed to previously).
>>
>>
>> So as of right now, all of the following urls point to orm/5.1...
>>
>>    1. http://docs.jboss.org/hibernate/orm/current/
>>    2. http://docs.jboss.org/hibernate/stable/orm
>>    3. http://docs.jboss.org/hibernate/stable/core
>>
>>
>> We will need to update all of the release builds that we still run.  That
>> includes:
>>
>>    1. 5.1
>>    2. 5.0
>>    3. 4.3 (?)
>>    4. 4.2 (?)
>>
>> Gail, am I correct that you still run 4.2 and 4.3 as part of Red Hat
>> productization?  To be honest, I am not even sure those builds (and maybe
>> even 5.0 at this point) should be updating the doc server.
>>
>>
>>
>> On Wed, Feb 10, 2016 at 1:09 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> I need to deal with the new link ontology we decided on for the doc
>>> server anyway
>>>
>>> On Wed, Feb 10, 2016 at 1:08 PM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> no, I'll do it
>>>>
>>>> On Wed, Feb 10, 2016 at 1:05 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I haven't changed the current build process. I'll have to investigate
>>>>> where to make the change.
>>>>>
>>>>> On Wed, Feb 10, 2016 at 9:01 PM, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> I thought you had updated the documentation build to build this?
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 10, 2016 at 12:31 PM Vlad Mihalcea <
>>>>>> mihalcea.vlad at gmail.com> wrote:
>>>>>>
>>>>>>> Congrats! I checked the docs but the User Guide is still the old one:
>>>>>>>
>>>>>>> http://docs.jboss.org/hibernate/orm/5.1/userGuide/en-US/html_single/
>>>>>>>
>>>>>>> Should we make the switch in a future release?
>>>>>>>
>>>>>>> On Wed, Feb 10, 2016 at 8:20 PM, Sanne Grinovero <
>>>>>>> sanne at hibernate.org> wrote:
>>>>>>>
>>>>>>>> Congratulations!!
>>>>>>>>
>>>>>>>> On 10 February 2016 at 18:16, Steve Ebersole <steve at hibernate.org>
>>>>>>>> wrote:
>>>>>>>> > The release build is done.  Push away!
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > On Wed, Feb 10, 2016 at 11:14 AM Steve Ebersole <
>>>>>>>> steve at hibernate.org> wrote:
>>>>>>>> >
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> > _______________________________________________
>>>>>>>> > 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 Jul  8 14:26:57 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 08 Jul 2016 18:26:57 +0000
Subject: [hibernate-dev] Starting 5.1.0 release
In-Reply-To: <CAFdSV9tNx9sOqfNNGfwyYHCrAX2=-01V86XFrXkTQYrZ86Z4vg@mail.gmail.com>
References: <CAFdSV9sW8Oe5ANEed+Y1Z-uw=wYNk2vZKKGwYX8PWsz372Y83A@mail.gmail.com>
	<CAFdSV9vp-txdwSyLizMEn9-cLz8Dw87Zf__zYRUtOatPFDZLkQ@mail.gmail.com>
	<CAFm4XO0q2BgFF3otmogGMnwHJnUX6iQx9KFMZ6KzsAJ5xSKCpQ@mail.gmail.com>
	<CA+gWKMCPyuZtHni3ZsyVP0O3VaDSrsdRWJ+XeEFxg2s=ek=GZg@mail.gmail.com>
	<CAFdSV9t9wjfzzoNTDhK_9GJHbmx_mSoFoW+=pXqmPsz1XTmiYQ@mail.gmail.com>
	<CA+gWKMBtJpn41Cx_zCOP8Z7T6zZem4yGAt8uUXbzLEp3-CENBA@mail.gmail.com>
	<CAFdSV9vR5XdBSGo=d_h7_SfaTAz=xDwAQ3qiSUAJH3VZimNxpg@mail.gmail.com>
	<CAFdSV9sDNVXo=SOca8VMNJT_qPPEci=0jJO_im3aEqEYN-H6wg@mail.gmail.com>
	<CAFdSV9tMW3f5JBdM-is30fC-azCLa43fj7XtjZ0uDVoDA975mQ@mail.gmail.com>
	<CAFdSV9twvXxAUWhUXj1KFz7iHGR6FAka-RM3cd2BCBJ5j5HmHg@mail.gmail.com>
	<CAFdSV9tNx9sOqfNNGfwyYHCrAX2=-01V86XFrXkTQYrZ86Z4vg@mail.gmail.com>
Message-ID: <CAFdSV9uoU74VfjCOFRdr5swrivxzAvMs-cb80GPLmw1Ad__9vg@mail.gmail.com>

Also, does anyone know if creating symlinks via sftp works against the doc
server?


On Fri, Jul 8, 2016 at 10:16 AM Steve Ebersole <steve at hibernate.org> wrote:

> Reviving this to finish the discussion about creation of the `current`
> symlink...
>
> I think we can actually script this update to the `current` symlink.  We'd
> simply limit the creation (and thus transfer) of the symlink when we do a
> release that ends in "0.Final" (maybe for CR releases too).  For example: 5.2.0.Final,
> 6.0.0.Final, 6.1.0.Final, etc.
>
> WDYT?
>
>
> On Wed, Feb 10, 2016 at 4:25 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Maybe the better option is to have the build simply upload to the
>> versioned docs dir (orm/5.0, orm/5.1, etc) and to manage the `current`
>> symlink by hand.  That really only needs to change when the next feature
>> release becomes stable.
>>
>>
>> On Wed, Feb 10, 2016 at 1:40 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> I fixed the symlinks on the doc server as follows:
>>>
>>>    1. created a `/orm/current` symlink pointing to `/orm/5.1`
>>>    2. updated `/stable/orm` to point to `/orm/current`
>>>    3. updated `/stable/core` to point to `/stable/orm` (I could not
>>>    remember what it pointed to previously).
>>>
>>>
>>> So as of right now, all of the following urls point to orm/5.1...
>>>
>>>    1. http://docs.jboss.org/hibernate/orm/current/
>>>    2. http://docs.jboss.org/hibernate/stable/orm
>>>    3. http://docs.jboss.org/hibernate/stable/core
>>>
>>>
>>> We will need to update all of the release builds that we still run.
>>> That includes:
>>>
>>>    1. 5.1
>>>    2. 5.0
>>>    3. 4.3 (?)
>>>    4. 4.2 (?)
>>>
>>> Gail, am I correct that you still run 4.2 and 4.3 as part of Red Hat
>>> productization?  To be honest, I am not even sure those builds (and maybe
>>> even 5.0 at this point) should be updating the doc server.
>>>
>>>
>>>
>>> On Wed, Feb 10, 2016 at 1:09 PM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> I need to deal with the new link ontology we decided on for the doc
>>>> server anyway
>>>>
>>>> On Wed, Feb 10, 2016 at 1:08 PM Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> no, I'll do it
>>>>>
>>>>> On Wed, Feb 10, 2016 at 1:05 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I haven't changed the current build process. I'll have to investigate
>>>>>> where to make the change.
>>>>>>
>>>>>> On Wed, Feb 10, 2016 at 9:01 PM, Steve Ebersole <steve at hibernate.org>
>>>>>> wrote:
>>>>>>
>>>>>>> I thought you had updated the documentation build to build this?
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Feb 10, 2016 at 12:31 PM Vlad Mihalcea <
>>>>>>> mihalcea.vlad at gmail.com> wrote:
>>>>>>>
>>>>>>>> Congrats! I checked the docs but the User Guide is still the old
>>>>>>>> one:
>>>>>>>>
>>>>>>>> http://docs.jboss.org/hibernate/orm/5.1/userGuide/en-US/html_single/
>>>>>>>>
>>>>>>>> Should we make the switch in a future release?
>>>>>>>>
>>>>>>>> On Wed, Feb 10, 2016 at 8:20 PM, Sanne Grinovero <
>>>>>>>> sanne at hibernate.org> wrote:
>>>>>>>>
>>>>>>>>> Congratulations!!
>>>>>>>>>
>>>>>>>>> On 10 February 2016 at 18:16, Steve Ebersole <steve at hibernate.org>
>>>>>>>>> wrote:
>>>>>>>>> > The release build is done.  Push away!
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > On Wed, Feb 10, 2016 at 11:14 AM Steve Ebersole <
>>>>>>>>> steve at hibernate.org> wrote:
>>>>>>>>> >
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> > _______________________________________________
>>>>>>>>> > hibernate-dev mailing list
>>>>>>>>> > hibernate-dev at lists.jboss.org
>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>> _______________________________________________
>>>>>>>>> hibernate-dev mailing list
>>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>

From sanne at hibernate.org  Mon Jul 11 04:19:09 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 11 Jul 2016 09:19:09 +0100
Subject: [hibernate-dev] Restrictions on `production` branch for website
	repositories
Message-ID: <CAFm4XO3hOc6DVP0ABWchMD_paQAe4zCt85=dGgbUcJq5QE4swQ@mail.gmail.com>

Hi all,
I've enabled github's new feature to restrict pushing to the
`production` branch of:
 - https://github.com/hibernate/hibernate.org
 - https://github.com/hibernate/in.relation.to

It will not allow pushing with "force" on the reference branch.

A general reminder: if you think you need to push with the git option
"--force" on this branches, you are very likely doing something wrong.

In case of real need the restriction can be [temporarily] disabled
from the repository settings on github, but before doing so please get
some peer over email/chat to help you figure out if there are better
alternatives, as it usually boils down to human mistakes ;)

Thanks,
Sanne

From daltodavide at gmail.com  Mon Jul 11 04:49:28 2016
From: daltodavide at gmail.com (Davide D'Alto)
Date: Mon, 11 Jul 2016 09:49:28 +0100
Subject: [hibernate-dev] Restrictions on `production` branch for website
	repositories
In-Reply-To: <CAFm4XO3hOc6DVP0ABWchMD_paQAe4zCt85=dGgbUcJq5QE4swQ@mail.gmail.com>
References: <CAFm4XO3hOc6DVP0ABWchMD_paQAe4zCt85=dGgbUcJq5QE4swQ@mail.gmail.com>
Message-ID: <CANoTJYPaMHXL-pU6k4qtZ=Oa4eQBRjfcRWpSKcq8t6Y4HwGTUA@mail.gmail.com>

+1

On Mon, Jul 11, 2016 at 9:19 AM, Sanne Grinovero <sanne at hibernate.org> wrote:
> Hi all,
> I've enabled github's new feature to restrict pushing to the
> `production` branch of:
>  - https://github.com/hibernate/hibernate.org
>  - https://github.com/hibernate/in.relation.to
>
> It will not allow pushing with "force" on the reference branch.
>
> A general reminder: if you think you need to push with the git option
> "--force" on this branches, you are very likely doing something wrong.
>
> In case of real need the restriction can be [temporarily] disabled
> from the repository settings on github, but before doing so please get
> some peer over email/chat to help you figure out if there are better
> alternatives, as it usually boils down to human mistakes ;)
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gbadner at redhat.com  Mon Jul 11 18:21:31 2016
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 11 Jul 2016 15:21:31 -0700
Subject: [hibernate-dev] Can an attribute annotated with
	@PrimaryKeyJoinColumn be optional?
Message-ID: <CAFDzhiSYHJoq=4rHp7Ukr=tYCOjrDFaBFBRdCY-yo5QCVEE_OA@mail.gmail.com>

I know that a simple ID cannot be optional. Can attributes making up a
composite ID be optional?

HHH-10929 concerns an optional attribute annotated with
@PrimaryKeyJoinColumn. Is this a valid use case?

Thanks,
Gail

From steve at hibernate.org  Mon Jul 11 18:46:35 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 11 Jul 2016 22:46:35 +0000
Subject: [hibernate-dev] Can an attribute annotated with
 @PrimaryKeyJoinColumn be optional?
In-Reply-To: <CAFDzhiSYHJoq=4rHp7Ukr=tYCOjrDFaBFBRdCY-yo5QCVEE_OA@mail.gmail.com>
References: <CAFDzhiSYHJoq=4rHp7Ukr=tYCOjrDFaBFBRdCY-yo5QCVEE_OA@mail.gmail.com>
Message-ID: <CAFdSV9vud4zXM+8udSAXq6fq-3VDJ7ADwrwW0S84+qvkSHLaMA@mail.gmail.com>

You mean nullable?  If so, no.

On Mon, Jul 11, 2016 at 5:21 PM Gail Badner <gbadner at redhat.com> wrote:

> I know that a simple ID cannot be optional. Can attributes making up a
> composite ID be optional?
>
> HHH-10929 concerns an optional attribute annotated with
> @PrimaryKeyJoinColumn. Is this a valid use case?
>
> Thanks,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Tue Jul 12 05:55:06 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 12 Jul 2016 10:55:06 +0100
Subject: [hibernate-dev] [OGM] Mapping of component types in document stores
Message-ID: <CADGJaX_TPTJhGje1uXrh859=+ZrmbCLbD=9gtK6iUbkFJXXcrw@mail.gmail.com>

Hi,

We had an interesting discussion on how to map element collections of
component types with a single column to document stores such as MongoDB.

E.g. assume we have

    @Entity
    public class Person {

        public String name;

        @ElementCollection
        public List<Status> statusHistory;
    }

    @Embeddable
    public class Status {
        public String name;
    }


Currently, that's mapped to documents like this:

    {
        "name"  : "Bob";
        "statusHistory" : [
            "great",
            "mediocre",
            "splendid"
        ]
    }

I.e. if the component type has a single column, we omit the field name in
the persistent structure. Whereas if there are multiple columns, it's added
so we can properly read back such documents:


    {
        "name"  : "Bob";
        "statusHistory" : [
            { "name" : "great", "date" : "22.06.2016" },
            { "name" : "mediocre", "date" : "15.05.2016" },
            { "name" : "splendid", "date" : "12.04.2016" }
        ]
    }

The question now is, should we also create such array of sub-documents,
each containing the field name, in the case where there only is a single
column. As far as I remember, the current structure has been chosen for the
sake of efficiency but also simplicity (why deal with sub-documents if
there only is a single field?).

Guillaume is questioning the sanity of that, arguing that mapping this as
an element collection of a component type rather than string should mandate
the persistent structure to always contain the field name.

We cannot change the default as we are committed to the MongoDB format, but
if there is agreement that it's useful, we could add an option to enable
this mapping.

I kind of see how this format simplifies migration (in case another field
is added after a while), but personally I still like the more compact looks
of the current approach. Having an option for it works for me.

Any thoughts?

--Gunnar

From sanne at hibernate.org  Tue Jul 12 06:06:54 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 12 Jul 2016 11:06:54 +0100
Subject: [hibernate-dev] [OGM] Mapping of component types in document
	stores
In-Reply-To: <CADGJaX_TPTJhGje1uXrh859=+ZrmbCLbD=9gtK6iUbkFJXXcrw@mail.gmail.com>
References: <CADGJaX_TPTJhGje1uXrh859=+ZrmbCLbD=9gtK6iUbkFJXXcrw@mail.gmail.com>
Message-ID: <CAFm4XO0Q=MgfBsG6moVpxDAtDomKsS3Xf1E2fsytNqfYb1VyuQ@mail.gmail.com>

On 12 July 2016 at 10:55, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> We had an interesting discussion on how to map element collections of
> component types with a single column to document stores such as MongoDB.
>
> E.g. assume we have
>
>     @Entity
>     public class Person {
>
>         public String name;
>
>         @ElementCollection
>         public List<Status> statusHistory;
>     }
>
>     @Embeddable
>     public class Status {
>         public String name;
>     }
>
>
> Currently, that's mapped to documents like this:
>
>     {
>         "name"  : "Bob";
>         "statusHistory" : [
>             "great",
>             "mediocre",
>             "splendid"
>         ]
>     }

"great", "mediocre", etc.. are values of the `name` property?

>
> I.e. if the component type has a single column, we omit the field name in
> the persistent structure. Whereas if there are multiple columns, it's added
> so we can properly read back such documents:
>
>
>     {
>         "name"  : "Bob";
>         "statusHistory" : [
>             { "name" : "great", "date" : "22.06.2016" },
>             { "name" : "mediocre", "date" : "15.05.2016" },
>             { "name" : "splendid", "date" : "12.04.2016" }
>         ]
>     }
>
> The question now is, should we also create such array of sub-documents,
> each containing the field name, in the case where there only is a single
> column. As far as I remember, the current structure has been chosen for the
> sake of efficiency but also simplicity (why deal with sub-documents if
> there only is a single field?).
>
> Guillaume is questioning the sanity of that, arguing that mapping this as
> an element collection of a component type rather than string should mandate
> the persistent structure to always contain the field name.

I agree, but maybe for other reasons.
I'd be concerned about schema evolution: if I add a new attribute to
the `Status` class, say a "long timestampOfChance" for the sake of the
example,
as a developer I might want to consider this a nullable value as I'm
aware that my existing database didn't define this property so far.

I wouldn't be happy to see failures on loading existing stored values
for Status#name : such mapping choices have to be very consistent.

>
> We cannot change the default as we are committed to the MongoDB format, but
> if there is agreement that it's useful, we could add an option to enable
> this mapping.

So many mapping options :-/

I'd see more value in making this the default, and have an "higher
level" configuration property which is like "read like OGM 5.0 used to
store it".
Even better, we'd provide tooling which migrates an existing database.

>
> I kind of see how this format simplifies migration (in case another field
> is added after a while), but personally I still like the more compact looks
> of the current approach. Having an option for it works for me.
>
> Any thoughts?
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Tue Jul 12 06:13:53 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 12 Jul 2016 11:13:53 +0100
Subject: [hibernate-dev] [OGM] Mapping of component types in document
	stores
In-Reply-To: <CAFm4XO0Q=MgfBsG6moVpxDAtDomKsS3Xf1E2fsytNqfYb1VyuQ@mail.gmail.com>
References: <CADGJaX_TPTJhGje1uXrh859=+ZrmbCLbD=9gtK6iUbkFJXXcrw@mail.gmail.com>
	<CAFm4XO0Q=MgfBsG6moVpxDAtDomKsS3Xf1E2fsytNqfYb1VyuQ@mail.gmail.com>
Message-ID: <CADGJaX9QL_wGC1V3ey-=YcYsBdgf1wkR+fg-f1q90S8atfWghg@mail.gmail.com>

> I'd be concerned about schema evolution:

Yes, that's the main argument; as said, I can see that.

> I'd see more value in making this the default, and have an "higher
> level" configuration property which is like "read like OGM 5.0 used to
> store it".

I wouldn't like changing such default in a 5.x release. For 6, ok, why not,
if you all think that's better.

> Even better, we'd provide tooling which migrates an existing database.

Sure, migration support is on the roadmap ;)





2016-07-12 11:06 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> On 12 July 2016 at 10:55, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Hi,
> >
> > We had an interesting discussion on how to map element collections of
> > component types with a single column to document stores such as MongoDB.
> >
> > E.g. assume we have
> >
> >     @Entity
> >     public class Person {
> >
> >         public String name;
> >
> >         @ElementCollection
> >         public List<Status> statusHistory;
> >     }
> >
> >     @Embeddable
> >     public class Status {
> >         public String name;
> >     }
> >
> >
> > Currently, that's mapped to documents like this:
> >
> >     {
> >         "name"  : "Bob";
> >         "statusHistory" : [
> >             "great",
> >             "mediocre",
> >             "splendid"
> >         ]
> >     }
>
> "great", "mediocre", etc.. are values of the `name` property?
>
> >
> > I.e. if the component type has a single column, we omit the field name in
> > the persistent structure. Whereas if there are multiple columns, it's
> added
> > so we can properly read back such documents:
> >
> >
> >     {
> >         "name"  : "Bob";
> >         "statusHistory" : [
> >             { "name" : "great", "date" : "22.06.2016" },
> >             { "name" : "mediocre", "date" : "15.05.2016" },
> >             { "name" : "splendid", "date" : "12.04.2016" }
> >         ]
> >     }
> >
> > The question now is, should we also create such array of sub-documents,
> > each containing the field name, in the case where there only is a single
> > column. As far as I remember, the current structure has been chosen for
> the
> > sake of efficiency but also simplicity (why deal with sub-documents if
> > there only is a single field?).
> >
> > Guillaume is questioning the sanity of that, arguing that mapping this as
> > an element collection of a component type rather than string should
> mandate
> > the persistent structure to always contain the field name.
>
> I agree, but maybe for other reasons.
> I'd be concerned about schema evolution: if I add a new attribute to
> the `Status` class, say a "long timestampOfChance" for the sake of the
> example,
> as a developer I might want to consider this a nullable value as I'm
> aware that my existing database didn't define this property so far.
>
> I wouldn't be happy to see failures on loading existing stored values
> for Status#name : such mapping choices have to be very consistent.
>
> >
> > We cannot change the default as we are committed to the MongoDB format,
> but
> > if there is agreement that it's useful, we could add an option to enable
> > this mapping.
>
> So many mapping options :-/
>
> I'd see more value in making this the default, and have an "higher
> level" configuration property which is like "read like OGM 5.0 used to
> store it".
> Even better, we'd provide tooling which migrates an existing database.
>
> >
> > I kind of see how this format simplifies migration (in case another field
> > is added after a while), but personally I still like the more compact
> looks
> > of the current approach. Having an option for it works for me.
> >
> > Any thoughts?
> >
> > --Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Tue Jul 12 06:18:06 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 12 Jul 2016 11:18:06 +0100
Subject: [hibernate-dev] [OGM] Mapping of component types in document
	stores
In-Reply-To: <CADGJaX9QL_wGC1V3ey-=YcYsBdgf1wkR+fg-f1q90S8atfWghg@mail.gmail.com>
References: <CADGJaX_TPTJhGje1uXrh859=+ZrmbCLbD=9gtK6iUbkFJXXcrw@mail.gmail.com>
	<CAFm4XO0Q=MgfBsG6moVpxDAtDomKsS3Xf1E2fsytNqfYb1VyuQ@mail.gmail.com>
	<CADGJaX9QL_wGC1V3ey-=YcYsBdgf1wkR+fg-f1q90S8atfWghg@mail.gmail.com>
Message-ID: <CAFm4XO0=uZGyAJhXJO_nu+pZgFk4kKjc=V=mYacFyaHmUPprLA@mail.gmail.com>

On 12 July 2016 at 11:13, Gunnar Morling <gunnar at hibernate.org> wrote:
>> I'd be concerned about schema evolution:
>
> Yes, that's the main argument; as said, I can see that.
>
>> I'd see more value in making this the default, and have an "higher
>> level" configuration property which is like "read like OGM 5.0 used to
>> store it".
>
> I wouldn't like changing such default in a 5.x release. For 6, ok, why not,
> if you all think that's better.

ok

>
>> Even better, we'd provide tooling which migrates an existing database.
>
> Sure, migration support is on the roadmap ;)
>
>
>
>
>
> 2016-07-12 11:06 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> On 12 July 2016 at 10:55, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > Hi,
>> >
>> > We had an interesting discussion on how to map element collections of
>> > component types with a single column to document stores such as MongoDB.
>> >
>> > E.g. assume we have
>> >
>> >     @Entity
>> >     public class Person {
>> >
>> >         public String name;
>> >
>> >         @ElementCollection
>> >         public List<Status> statusHistory;
>> >     }
>> >
>> >     @Embeddable
>> >     public class Status {
>> >         public String name;
>> >     }
>> >
>> >
>> > Currently, that's mapped to documents like this:
>> >
>> >     {
>> >         "name"  : "Bob";
>> >         "statusHistory" : [
>> >             "great",
>> >             "mediocre",
>> >             "splendid"
>> >         ]
>> >     }
>>
>> "great", "mediocre", etc.. are values of the `name` property?
>>
>> >
>> > I.e. if the component type has a single column, we omit the field name
>> > in
>> > the persistent structure. Whereas if there are multiple columns, it's
>> > added
>> > so we can properly read back such documents:
>> >
>> >
>> >     {
>> >         "name"  : "Bob";
>> >         "statusHistory" : [
>> >             { "name" : "great", "date" : "22.06.2016" },
>> >             { "name" : "mediocre", "date" : "15.05.2016" },
>> >             { "name" : "splendid", "date" : "12.04.2016" }
>> >         ]
>> >     }
>> >
>> > The question now is, should we also create such array of sub-documents,
>> > each containing the field name, in the case where there only is a single
>> > column. As far as I remember, the current structure has been chosen for
>> > the
>> > sake of efficiency but also simplicity (why deal with sub-documents if
>> > there only is a single field?).
>> >
>> > Guillaume is questioning the sanity of that, arguing that mapping this
>> > as
>> > an element collection of a component type rather than string should
>> > mandate
>> > the persistent structure to always contain the field name.
>>
>> I agree, but maybe for other reasons.
>> I'd be concerned about schema evolution: if I add a new attribute to
>> the `Status` class, say a "long timestampOfChance" for the sake of the
>> example,
>> as a developer I might want to consider this a nullable value as I'm
>> aware that my existing database didn't define this property so far.
>>
>> I wouldn't be happy to see failures on loading existing stored values
>> for Status#name : such mapping choices have to be very consistent.
>>
>> >
>> > We cannot change the default as we are committed to the MongoDB format,
>> > but
>> > if there is agreement that it's useful, we could add an option to enable
>> > this mapping.
>>
>> So many mapping options :-/
>>
>> I'd see more value in making this the default, and have an "higher
>> level" configuration property which is like "read like OGM 5.0 used to
>> store it".
>> Even better, we'd provide tooling which migrates an existing database.
>>
>> >
>> > I kind of see how this format simplifies migration (in case another
>> > field
>> > is added after a while), but personally I still like the more compact
>> > looks
>> > of the current approach. Having an option for it works for me.
>> >
>> > Any thoughts?
>> >
>> > --Gunnar
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From guillaume.smet at gmail.com  Tue Jul 12 07:35:16 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 12 Jul 2016 13:35:16 +0200
Subject: [hibernate-dev] [OGM] Mapping of component types in document
	stores
In-Reply-To: <CAFm4XO0=uZGyAJhXJO_nu+pZgFk4kKjc=V=mYacFyaHmUPprLA@mail.gmail.com>
References: <CADGJaX_TPTJhGje1uXrh859=+ZrmbCLbD=9gtK6iUbkFJXXcrw@mail.gmail.com>
	<CAFm4XO0Q=MgfBsG6moVpxDAtDomKsS3Xf1E2fsytNqfYb1VyuQ@mail.gmail.com>
	<CADGJaX9QL_wGC1V3ey-=YcYsBdgf1wkR+fg-f1q90S8atfWghg@mail.gmail.com>
	<CAFm4XO0=uZGyAJhXJO_nu+pZgFk4kKjc=V=mYacFyaHmUPprLA@mail.gmail.com>
Message-ID: <CALt0+o85Evn01G9-BQGpL10ZDzSYsJdezqKDMxG+TwB1emCgRA@mail.gmail.com>

Hi,

For the sake of completeness, here is the mapping obtained with Morphia:
{ "_id" : ObjectId("5784ca2612d0226cb309666d"), "className" :
"TestEntity", "embeddeds" : [ { "singleProperty" : "value1" }, {
"singleProperty" : "value2" } ], "embedded" : { "singleProperty" :
"value" }, "collectionOfStrings" : [ "string1", "string2" ] }
They are basically following the POLA and follow the Java mapping for
the MongoDB one.

Btw, to be complete, here are the reasons why I would like to change
it (I agree we have to maintain compatibility with older databases
but, as Sanne, I think it should be the new default):
1/ POLA: I would expect my datastore mapping to follow my Java mapping
2/ related to 1/: I wouldn't expect to have to migrate my data when I
simply add a property to an existing embeddable
3/ remove special cases in our code, especially special cases present
in the dialects
4/ I don't think we are completely consistent with this behavior.
Typically, if I take StoryGame from our tests and remove all the
properties but one from OptionalStoryBranch, I end up with the
following:
- in the datastore: "chaoticBranches" : [ "[VENDETTA] assassinate the
leader of the party", "[ARTIFACT] Search for the evil artifact" ] -
this is what we expect, only one property, we remove the property
level
- in the native query generated by our JPA query "FROM StoryGame story
JOIN story.chaoticBranches c WHERE c.evilText = '[ARTIFACT] Search for
the evil artifact'": where={ "chaoticBranches.evilText" : "[ARTIFACT]
Search for the evil artifact"}
-> so our JPQL queries don't work if we only have one property in the
embedded. We might also want to special case this but I really don't
think it's a good idea.

While this discussion might seem to come out of the blue, it's in fact
related to OGM-893 and another special casing we do. See my comment
here: https://hibernate.atlassian.net/browse/OGM-893?focusedCommentId=79245&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-79245
. The mapping is changing when we add a @Column with a name for a
property of an embedded in a collection element.

-- 
Guillaume

On Tue, Jul 12, 2016 at 12:18 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> On 12 July 2016 at 11:13, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> I'd be concerned about schema evolution:
>>
>> Yes, that's the main argument; as said, I can see that.
>>
>>> I'd see more value in making this the default, and have an "higher
>>> level" configuration property which is like "read like OGM 5.0 used to
>>> store it".
>>
>> I wouldn't like changing such default in a 5.x release. For 6, ok, why not,
>> if you all think that's better.
>
> ok
>
>>
>>> Even better, we'd provide tooling which migrates an existing database.
>>
>> Sure, migration support is on the roadmap ;)
>>
>>
>>
>>
>>
>> 2016-07-12 11:06 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>>
>>> On 12 July 2016 at 10:55, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> > Hi,
>>> >
>>> > We had an interesting discussion on how to map element collections of
>>> > component types with a single column to document stores such as MongoDB.
>>> >
>>> > E.g. assume we have
>>> >
>>> >     @Entity
>>> >     public class Person {
>>> >
>>> >         public String name;
>>> >
>>> >         @ElementCollection
>>> >         public List<Status> statusHistory;
>>> >     }
>>> >
>>> >     @Embeddable
>>> >     public class Status {
>>> >         public String name;
>>> >     }
>>> >
>>> >
>>> > Currently, that's mapped to documents like this:
>>> >
>>> >     {
>>> >         "name"  : "Bob";
>>> >         "statusHistory" : [
>>> >             "great",
>>> >             "mediocre",
>>> >             "splendid"
>>> >         ]
>>> >     }
>>>
>>> "great", "mediocre", etc.. are values of the `name` property?
>>>
>>> >
>>> > I.e. if the component type has a single column, we omit the field name
>>> > in
>>> > the persistent structure. Whereas if there are multiple columns, it's
>>> > added
>>> > so we can properly read back such documents:
>>> >
>>> >
>>> >     {
>>> >         "name"  : "Bob";
>>> >         "statusHistory" : [
>>> >             { "name" : "great", "date" : "22.06.2016" },
>>> >             { "name" : "mediocre", "date" : "15.05.2016" },
>>> >             { "name" : "splendid", "date" : "12.04.2016" }
>>> >         ]
>>> >     }
>>> >
>>> > The question now is, should we also create such array of sub-documents,
>>> > each containing the field name, in the case where there only is a single
>>> > column. As far as I remember, the current structure has been chosen for
>>> > the
>>> > sake of efficiency but also simplicity (why deal with sub-documents if
>>> > there only is a single field?).
>>> >
>>> > Guillaume is questioning the sanity of that, arguing that mapping this
>>> > as
>>> > an element collection of a component type rather than string should
>>> > mandate
>>> > the persistent structure to always contain the field name.
>>>
>>> I agree, but maybe for other reasons.
>>> I'd be concerned about schema evolution: if I add a new attribute to
>>> the `Status` class, say a "long timestampOfChance" for the sake of the
>>> example,
>>> as a developer I might want to consider this a nullable value as I'm
>>> aware that my existing database didn't define this property so far.
>>>
>>> I wouldn't be happy to see failures on loading existing stored values
>>> for Status#name : such mapping choices have to be very consistent.
>>>
>>> >
>>> > We cannot change the default as we are committed to the MongoDB format,
>>> > but
>>> > if there is agreement that it's useful, we could add an option to enable
>>> > this mapping.
>>>
>>> So many mapping options :-/
>>>
>>> I'd see more value in making this the default, and have an "higher
>>> level" configuration property which is like "read like OGM 5.0 used to
>>> store it".
>>> Even better, we'd provide tooling which migrates an existing database.
>>>
>>> >
>>> > I kind of see how this format simplifies migration (in case another
>>> > field
>>> > is added after a while), but personally I still like the more compact
>>> > looks
>>> > of the current approach. Having an option for it works for me.
>>> >
>>> > Any thoughts?
>>> >
>>> > --Gunnar
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at gmail.com  Wed Jul 13 08:39:31 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 13 Jul 2016 14:39:31 +0200
Subject: [hibernate-dev] [OGM] Mapping of embedded
Message-ID: <CALt0+o9xuwqS+ZxkYFVxJ9Vdh1xXimS1ouHnmRUpybdR=sWvwQ@mail.gmail.com>

Hi,

This is a followup of:

From guillaume.smet at gmail.com  Wed Jul 13 09:22:51 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 13 Jul 2016 15:22:51 +0200
Subject: [hibernate-dev] [OGM] Mapping of embedded
In-Reply-To: <CALt0+o9xuwqS+ZxkYFVxJ9Vdh1xXimS1ouHnmRUpybdR=sWvwQ@mail.gmail.com>
References: <CALt0+o9xuwqS+ZxkYFVxJ9Vdh1xXimS1ouHnmRUpybdR=sWvwQ@mail.gmail.com>
Message-ID: <CALt0+o83WZj29NCw-HTyaNAdTyU1tjsrRmaitZnLeRU9DkGW+A@mail.gmail.com>

So this is a followup of my previous email (looks like I found out the
Send shortcut on GMail...)... which was supposed to be a followup of:
 * https://hibernate.atlassian.net/browse/OGM-893
 * https://github.com/hibernate/hibernate-ogm/pull/728
 * and a discussion we had yesterday with Davide.

Taking MongoDB as the reference implementation here.

Current situation
=================

1/ for a simple embedded Address (property: homeAddress) with one of
the property having a @Column(name = "postal_code"), we end up with
the following mapping:
{
    [...],
    'homeAddress' : {
        'city' : 'Paris',
        'country' : 'France',
        'street1' : '1 avenue des Champs Elysees',
        'type' : {
            'name' : 'main'
        }
    },
    'postal_code' : '75007',
    [...]
}
As you can see, postal_code is stored outside of the nested structure.
This is in line with the ORM behavior where you end up having the
columns homeAddress_city and postal_code.

Of course, this is a bit weird when we are considering nested documents.

See EmbeddableMappingTest for reference.

2/ now suppose that we have a List<Address>, the current mapping is
the following:
{
    [...],
    "addresses": [
       {
           "addresses": {
               "country": "Germany",
               "city": "Paris",
               "street1": "1 avenue des Champs Elysees"
           },
            "postal_code": "75007"
       },
       {
           "addresses": {
               "city": "Rome",
               "street1": "Piazza del Colosseo, 1",
               "type": {
                   "name": "primary"
               }
           },
            "postal_code": "00184"
       }
    ],
    [...]
}

Note the fact that addresses is nested twice.

This is discussed at length in https://hibernate.atlassian.net/browse/OGM-893.

What does PR 728 change?
========================

After the work we did with Steve on ORM and the followup of Davide on
OGM, we end up with the following situation:

1/ Same as before. postal_code is outside of the nested document.

2/ This is where the behavior has changed, we now have the following mapping:
{
    "addresses": [
       {
           "country": "Germany",
           "city": "Paris",
           "street1": "1 avenue des Champs Elysees",
           "postal_code": "75007"
       },
       {
           "city": "Rome",
           "street1": "Piazza del Colosseo, 1",
           "type": {
               "name": "primary"
           },
           "postal_code": "00184"
       }
    ],
}

Note that postal_code and city are now at the same level.

See this future test executed on top of pr/728:
https://gist.github.com/gsmet/0652294523b2c48efe72668ccc0a6e1c

Conclusion
==========

So as you can see, the mapping is quite different between a simple
embedded and a list of embedded. I was not very happy with the
behavior of 2/ before, especially because if you remove the @Column,
you lose the data stored. Same if you didn't have one before and you
add one to your embeddable.

But I'm also not convinced having a different behavior between 1/ and
2/ is the way to go. Note that, from what I've seen, I don't think
changing 1/ to move postal_code in the nested document will be easy
(or even feasible).

Opinions? Thoughts?

-- 
Guillaume

From mihalcea.vlad at gmail.com  Fri Jul 15 03:29:57 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 15 Jul 2016 10:29:57 +0300
Subject: [hibernate-dev] DISTINCT keyword in JPQL
Message-ID: <CA+gWKMCUYtQ8c5bzR6kjrzTqU1appGrz=fR6zp72B_Wz4jdu3Q@mail.gmail.com>

Hi,

In JPQL/HQL, the DISTINCT keyword is meant to avoid returning the same
parent entities when JOIN FETCHING parents with child associations.
JPA backs it up too:

"The DISTINCT keyword is used to specify that duplicate values must be
eliminated from the query result."

However, I see that the DISTINCT is applied on the SQL statement as well.

Why is it so? Is there any reason why we would want such a behaviour?
The problem is that an unnecessary DISTINCT might affect the execution plan:

http://use-the-index-luke.com/sql/join/nested-loops-join-n1-problem?langtype=java#orm-join

"The distinct keyword in the SQL query is alarming because most databases
will actually filter duplicate records. Only a few databases recognize that
the primary keys guarantees uniqueness in that case anyway."

Should we provide a Query hint like HINT_DISTINCT_SQL which when explicitly
set, the JPQL DISTINCT keyword generates a DISTINCT keyword on the SQL
statement-level as well.
Without the hint set explicitly, we should not pass the DISTINCT to the SQL
statement.

What do you think?

Vlad

From steve at hibernate.org  Sat Jul 16 08:55:06 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 16 Jul 2016 12:55:06 +0000
Subject: [hibernate-dev] 6.0 persister redesign
Message-ID: <CAFdSV9u9h=z+JoC2U2Qw6upKsh1MN8ap0YgAKBkCqWc=fpAXRw@mail.gmail.com>

Along with the Type redesign in 6.0 we will need to do some redesigning of
the persister contracts.  I'd like to start collaborating on those changes
with the ongoing 6.0 wip work.  I plan on having a design meeting in the
"Hibernate ORM" HipcHat room on Monday around 12 pm Central US time for
anyone that would like to participate.

From steve at hibernate.org  Sun Jul 17 10:54:38 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 17 Jul 2016 14:54:38 +0000
Subject: [hibernate-dev] "Awaiting Testcase" transition
Message-ID: <CAFdSV9suTBTG+ZzMUvFkZ9Pb6Mg_o2gjDGrop+q+rGRqBFhzvA@mail.gmail.com>

I see folks using a generic "template" for the comment added to an issue
when they transition it to the "Awaiting Testcase" status.  If we all
agree, we could make that a post-function of the transition - meaning that
comment would be added automatically.

From steve at hibernate.org  Sun Jul 17 10:56:19 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 17 Jul 2016 14:56:19 +0000
Subject: [hibernate-dev] 6.0 persister redesign
In-Reply-To: <CAFdSV9u9h=z+JoC2U2Qw6upKsh1MN8ap0YgAKBkCqWc=fpAXRw@mail.gmail.com>
References: <CAFdSV9u9h=z+JoC2U2Qw6upKsh1MN8ap0YgAKBkCqWc=fpAXRw@mail.gmail.com>
Message-ID: <CAFdSV9vk6Oh-=XqQParThrLYQC0sxD8uwKPhJ6SiFbLopemK2A@mail.gmail.com>

BTW, I started a design proposal wiki for this work:
https://github.com/hibernate/hibernate-orm/wiki/6.0-persister-redesign

ATM this is very basic initial thoughts.

On Sat, Jul 16, 2016 at 7:55 AM Steve Ebersole <steve at hibernate.org> wrote:

> Along with the Type redesign in 6.0 we will need to do some redesigning of
> the persister contracts.  I'd like to start collaborating on those changes
> with the ongoing 6.0 wip work.  I plan on having a design meeting in the
> "Hibernate ORM" HipcHat room on Monday around 12 pm Central US time for
> anyone that would like to participate.
>

From brett at hibernate.org  Sun Jul 17 18:52:28 2016
From: brett at hibernate.org (Brett Meyer)
Date: Sun, 17 Jul 2016 18:52:28 -0400
Subject: [hibernate-dev] "Awaiting Testcase" transition
In-Reply-To: <CAFdSV9suTBTG+ZzMUvFkZ9Pb6Mg_o2gjDGrop+q+rGRqBFhzvA@mail.gmail.com>
References: <CAFdSV9suTBTG+ZzMUvFkZ9Pb6Mg_o2gjDGrop+q+rGRqBFhzvA@mail.gmail.com>
Message-ID: <578C0C2C.7070702@hibernate.org>

+1!

On 07/17/2016 10:54 AM, Steve Ebersole wrote:
> I see folks using a generic "template" for the comment added to an issue
> when they transition it to the "Awaiting Testcase" status.  If we all
> agree, we could make that a post-function of the transition - meaning that
> comment would be added automatically.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From chris at hibernate.org  Sun Jul 17 22:27:06 2016
From: chris at hibernate.org (Chris Cranford)
Date: Sun, 17 Jul 2016 21:27:06 -0500
Subject: [hibernate-dev] "Awaiting Testcase" transition
In-Reply-To: <578C0C2C.7070702@hibernate.org>
References: <CAFdSV9suTBTG+ZzMUvFkZ9Pb6Mg_o2gjDGrop+q+rGRqBFhzvA@mail.gmail.com>
	<578C0C2C.7070702@hibernate.org>
Message-ID: <d21092b1-65eb-1a3e-65fa-df6297fa0fab@hibernate.org>

+1
On 07/17/2016 05:52 PM, Brett Meyer wrote:
> +1!
>
> On 07/17/2016 10:54 AM, Steve Ebersole wrote:
>> I see folks using a generic "template" for the comment added to an issue
>> when they transition it to the "Awaiting Testcase" status.  If we all
>> agree, we could make that a post-function of the transition - meaning that
>> comment would be added automatically.
>> _______________________________________________
>> 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  Mon Jul 18 06:10:36 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 18 Jul 2016 13:10:36 +0300
Subject: [hibernate-dev] Second-level cache and Inheritance
Message-ID: <CA+gWKMB6JB_VRna2CeZH=1RPBWMsWARNxE7RWHN5HzzMDThpcw@mail.gmail.com>

Hi,

I bumped into this question on our forum:

https://forum.hibernate.org/viewtopic.php?f=1&t=1043470

And after I tried an example using the latest Hibernate version I see that,
for inheritance, all subentities share the parent region name.
This can  be found in org.hibernate.internal.CacheImpl

final String cacheRegionName = cacheRegionPrefix +
model.getRootClass().getCacheRegionName();


As you can see, we take the rootClass when constructing the region name.
For this reason, we cannot use different CacheConcurrencyStartegy with
different subclass types.

Is there any reason for this, or should we consider adding support for this
feature?

Vlad

From sanne at hibernate.org  Mon Jul 18 07:03:54 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 18 Jul 2016 12:03:54 +0100
Subject: [hibernate-dev] Second-level cache and Inheritance
In-Reply-To: <CA+gWKMB6JB_VRna2CeZH=1RPBWMsWARNxE7RWHN5HzzMDThpcw@mail.gmail.com>
References: <CA+gWKMB6JB_VRna2CeZH=1RPBWMsWARNxE7RWHN5HzzMDThpcw@mail.gmail.com>
Message-ID: <CAFm4XO0FqcbacpUxUKH6aCxUop20SKUuJRVxnt+oedOcYVK6BA@mail.gmail.com>

Hi Vlad,

I think that might be quite tricky to implement, as it might not
always be clear into which region we'd need to lookup from, or
invalidate, not least locks might need to cross multiple regions.
Think for example when a type A is removed with ID=1, and then a type
B with the same ID is being re-inserted as a replacement, but
"upgrading" the type, e.g. B extends A so it's similar to the original
value but adds some more fields.

Not that I'd ever recommend doing such weird things, but we obviously
need to be correct to deal with such scenarios.

If you then also throw in the fact that multiple such regions which
need to be treated correctly from a concurrency point of view, as a
combination of multiple different possible concurrency strategies,
then the code complexity explodes even further and there are many
details to take into account..
Assuming even that someone was up to the challenge to implement this
(and get it right?!), you'd pay a significant price in terms of
runtime performance due to this complexity.

-- Sanne





On 18 July 2016 at 11:10, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Hi,
>
> I bumped into this question on our forum:
>
> https://forum.hibernate.org/viewtopic.php?f=1&t=1043470
>
> And after I tried an example using the latest Hibernate version I see that,
> for inheritance, all subentities share the parent region name.
> This can  be found in org.hibernate.internal.CacheImpl
>
> final String cacheRegionName = cacheRegionPrefix +
> model.getRootClass().getCacheRegionName();
>
>
> As you can see, we take the rootClass when constructing the region name.
> For this reason, we cannot use different CacheConcurrencyStartegy with
> different subclass types.
>
> Is there any reason for this, or should we consider adding support for this
> feature?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Mon Jul 18 07:24:11 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 18 Jul 2016 12:24:11 +0100
Subject: [hibernate-dev] 6.0 persister redesign
In-Reply-To: <CAFdSV9vk6Oh-=XqQParThrLYQC0sxD8uwKPhJ6SiFbLopemK2A@mail.gmail.com>
References: <CAFdSV9u9h=z+JoC2U2Qw6upKsh1MN8ap0YgAKBkCqWc=fpAXRw@mail.gmail.com>
	<CAFdSV9vk6Oh-=XqQParThrLYQC0sxD8uwKPhJ6SiFbLopemK2A@mail.gmail.com>
Message-ID: <CAFm4XO1801D_nG-3f5HDXmdXLNKs+0KSrtWjh4WWr7y4fRmMKg@mail.gmail.com>

Hi Steve,

a (long) while back we had a "design chat" session which might be
related; I was then asking if it was possible to break up the
persistence context, which is today essentially one map containing all
entries even for different types, and break that up into multiple
smaller maps, one per Persister.

I'd love we could try this, as I expect this to bring both performance
improvements and some simpler code.

I believe you thought this could be feasible, although obviously the
devil is in the details so this might need a little prototyping.
Thanks for the meeting heads up, I'll be there.

Thanks,
Sanne

On 17 July 2016 at 15:56, Steve Ebersole <steve at hibernate.org> wrote:
> BTW, I started a design proposal wiki for this work:
> https://github.com/hibernate/hibernate-orm/wiki/6.0-persister-redesign
>
> ATM this is very basic initial thoughts.
>
> On Sat, Jul 16, 2016 at 7:55 AM Steve Ebersole <steve at hibernate.org> wrote:
>
>> Along with the Type redesign in 6.0 we will need to do some redesigning of
>> the persister contracts.  I'd like to start collaborating on those changes
>> with the ongoing 6.0 wip work.  I plan on having a design meeting in the
>> "Hibernate ORM" HipcHat room on Monday around 12 pm Central US time for
>> anyone that would like to participate.
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Mon Jul 18 09:25:17 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 18 Jul 2016 13:25:17 +0000
Subject: [hibernate-dev] "Awaiting Testcase" transition
In-Reply-To: <d21092b1-65eb-1a3e-65fa-df6297fa0fab@hibernate.org>
References: <CAFdSV9suTBTG+ZzMUvFkZ9Pb6Mg_o2gjDGrop+q+rGRqBFhzvA@mail.gmail.com>
	<578C0C2C.7070702@hibernate.org>
	<d21092b1-65eb-1a3e-65fa-df6297fa0fab@hibernate.org>
Message-ID: <CAFdSV9s84Dg4RDMr4V-qM861KZTycsNun3e_ifzSvmM7nEyszg@mail.gmail.com>

This is the comment that will now be added to an issue whenever an issue is
transitioned to "Awaiting Test Case":

Please attach a short but complete [test case|
https://github.com/hibernate/hibernate-orm/wiki/Test-Case-Guide] that
reproduces the reported bug.

* That Test Case Guide is something I just wrote.


On Sun, Jul 17, 2016 at 9:27 PM Chris Cranford <chris at hibernate.org> wrote:

> +1
> On 07/17/2016 05:52 PM, Brett Meyer wrote:
> > +1!
> >
> > On 07/17/2016 10:54 AM, Steve Ebersole wrote:
> >> I see folks using a generic "template" for the comment added to an issue
> >> when they transition it to the "Awaiting Testcase" status.  If we all
> >> agree, we could make that a post-function of the transition - meaning
> that
> >> comment would be added automatically.
> >> _______________________________________________
> >> 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  Mon Jul 18 21:47:43 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 19 Jul 2016 01:47:43 +0000
Subject: [hibernate-dev] 6.0 persister redesign
In-Reply-To: <CAFm4XO1801D_nG-3f5HDXmdXLNKs+0KSrtWjh4WWr7y4fRmMKg@mail.gmail.com>
References: <CAFdSV9u9h=z+JoC2U2Qw6upKsh1MN8ap0YgAKBkCqWc=fpAXRw@mail.gmail.com>
	<CAFdSV9vk6Oh-=XqQParThrLYQC0sxD8uwKPhJ6SiFbLopemK2A@mail.gmail.com>
	<CAFm4XO1801D_nG-3f5HDXmdXLNKs+0KSrtWjh4WWr7y4fRmMKg@mail.gmail.com>
Message-ID: <CAFdSV9vCLKDDsEvZLR2ZP21xqy9BYeocOt_gJ1p9nBUBCYR_og@mail.gmail.com>

After thinking about our discussions some more, I wonder if it is not
better to simply have the persister and Type be the same for entity,
collection and embeddable.  Assuming we do not separate "persister" and
"metadata" I think this is the way to go.

Thoughts?


On Mon, Jul 18, 2016 at 6:24 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Steve,
>
> a (long) while back we had a "design chat" session which might be
> related; I was then asking if it was possible to break up the
> persistence context, which is today essentially one map containing all
> entries even for different types, and break that up into multiple
> smaller maps, one per Persister.
>
> I'd love we could try this, as I expect this to bring both performance
> improvements and some simpler code.
>
> I believe you thought this could be feasible, although obviously the
> devil is in the details so this might need a little prototyping.
> Thanks for the meeting heads up, I'll be there.
>
> Thanks,
> Sanne
>
> On 17 July 2016 at 15:56, Steve Ebersole <steve at hibernate.org> wrote:
> > BTW, I started a design proposal wiki for this work:
> > https://github.com/hibernate/hibernate-orm/wiki/6.0-persister-redesign
> >
> > ATM this is very basic initial thoughts.
> >
> > On Sat, Jul 16, 2016 at 7:55 AM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> Along with the Type redesign in 6.0 we will need to do some redesigning
> of
> >> the persister contracts.  I'd like to start collaborating on those
> changes
> >> with the ongoing 6.0 wip work.  I plan on having a design meeting in the
> >> "Hibernate ORM" HipcHat room on Monday around 12 pm Central US time for
> >> anyone that would like to participate.
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From guillaume.smet at gmail.com  Tue Jul 19 08:24:58 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 19 Jul 2016 14:24:58 +0200
Subject: [hibernate-dev] People can't find our docs
Message-ID: <CALt0+o897FpJGR259OJaokyDmc0R6-rH5Fd=VUBBZtryeAUoEw@mail.gmail.com>

Hi,

When we search for Hibernate/Hibernate Search issues, Google send
people to *very* outdated docs.

For instance, searching for %1$s gets me to %2$s:
- hibernate collection element ->
https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/collections.html
(yes, *3.3*)
- hibernate search facet ->
https://docs.jboss.org/hibernate/search/4.5/reference/en-US/html/search-query.html

These versions of our docs are very well indexed by Google as they
come up before stack overflow but it's really a bad thing to get
people directed to very old versions of our documentation.

Do we have people at RH working on this sort of things who could help
us defining a good strategy to improve that? Did anyone already take a
look at this?

When I was contributing to PostgreSQL, the subject was discussed at
length and they didn't find a good solution at the time to get Google
to preferably link to the last version. Using canonical urls for
instance requires you to regenerate all the old docs when you have to
point to another URL.

They finally decided to integrate links to all versions at the top of
each doc page: https://www.postgresql.org/docs/9.5/static/sql-syntax.html
.


>From my point of view, here are a few things that might help mitigate the issue:
- have a version of the doc labelled as /current/ (or /stable/) on
hibernate.org. From what I've seen, ORM has a /current/ symlink but
it's currently pointing to the 5.1 documentation and is not used on
the website. We should use this link every time we link to the
documentation (especially on SO).

- Maybe we could try to map the old URLs to the new ones by doing
something similar to what PostgreSQL does but dynamically with jQuery.
We could inject it in the old documentation with something like
http://httpd.apache.org/docs/2.2/mod/mod_substitute.html if we can get
this enabled on docs.jboss.org.

- our doc URLs are now named chNN.html which is not very future proof.
Did we have issues keeping the semantic ones? I suppose it's related
to the asciidoc migration? It would be a good way to keep more stable
URL.

- btw, is there a reason why we only generate the html_single output
for Hibernate ORM?

Thoughts, opinions, ideas?

-- 
Guillaume

From sanne at hibernate.org  Tue Jul 19 08:39:13 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 19 Jul 2016 13:39:13 +0100
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <CALt0+o897FpJGR259OJaokyDmc0R6-rH5Fd=VUBBZtryeAUoEw@mail.gmail.com>
References: <CALt0+o897FpJGR259OJaokyDmc0R6-rH5Fd=VUBBZtryeAUoEw@mail.gmail.com>
Message-ID: <CAFm4XO01pFxt6CTjmgDZOMjG+h77VhDFmaeZVNiKVscgJvoiXw@mail.gmail.com>

Hi Guillaume,

yes I'm aware of the issue; we discussed it before, I think on this
same mailing list but maybe it was during our last meeting.

We really need to fix that metadata; Stefania (my partner) is an SEO
consultant and is shocked at how bad we do with this; apparently we
are a funny example in her office but at least we're not the worst :)

The problem is we can't change the headers as we don't control the
Apache httpd configuraion on the documentation server, so the
alternative is we'd need to rsync those docs locally, insert the right
changes in the static files of the docs, and push them back.

Needs a volunteer to find some time for this.

Also related to SEO I recently opened some issues on our WEBSITE
project, these should be easier to fix as it's directly under our
control:
 - https://hibernate.atlassian.net/browse/WEBSITE-461
 - https://hibernate.atlassian.net/browse/WEBSITE-460
 - https://hibernate.atlassian.net/browse/WEBSITE-459

I've assigned them to Davide as he's usually quick with such things
but anyone is welcome to take some.

The metadata issue on the docs server is probably the most urgent /
valuable though.

Thanks,
Sanne


On 19 July 2016 at 13:24, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi,
>
> When we search for Hibernate/Hibernate Search issues, Google send
> people to *very* outdated docs.
>
> For instance, searching for %1$s gets me to %2$s:
> - hibernate collection element ->
> https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/collections.html
> (yes, *3.3*)
> - hibernate search facet ->
> https://docs.jboss.org/hibernate/search/4.5/reference/en-US/html/search-query.html
>
> These versions of our docs are very well indexed by Google as they
> come up before stack overflow but it's really a bad thing to get
> people directed to very old versions of our documentation.
>
> Do we have people at RH working on this sort of things who could help
> us defining a good strategy to improve that? Did anyone already take a
> look at this?
>
> When I was contributing to PostgreSQL, the subject was discussed at
> length and they didn't find a good solution at the time to get Google
> to preferably link to the last version. Using canonical urls for
> instance requires you to regenerate all the old docs when you have to
> point to another URL.
>
> They finally decided to integrate links to all versions at the top of
> each doc page: https://www.postgresql.org/docs/9.5/static/sql-syntax.html
> .
>
>
> >From my point of view, here are a few things that might help mitigate the issue:
> - have a version of the doc labelled as /current/ (or /stable/) on
> hibernate.org. From what I've seen, ORM has a /current/ symlink but
> it's currently pointing to the 5.1 documentation and is not used on
> the website. We should use this link every time we link to the
> documentation (especially on SO).
>
> - Maybe we could try to map the old URLs to the new ones by doing
> something similar to what PostgreSQL does but dynamically with jQuery.
> We could inject it in the old documentation with something like
> http://httpd.apache.org/docs/2.2/mod/mod_substitute.html if we can get
> this enabled on docs.jboss.org.
>
> - our doc URLs are now named chNN.html which is not very future proof.
> Did we have issues keeping the semantic ones? I suppose it's related
> to the asciidoc migration? It would be a good way to keep more stable
> URL.
>
> - btw, is there a reason why we only generate the html_single output
> for Hibernate ORM?
>
> Thoughts, opinions, ideas?
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From emmanuel at hibernate.org  Tue Jul 19 13:14:54 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 19 Jul 2016 19:14:54 +0200
Subject: [hibernate-dev] [OGM] Mapping of component types in document
 stores
In-Reply-To: <CALt0+o85Evn01G9-BQGpL10ZDzSYsJdezqKDMxG+TwB1emCgRA@mail.gmail.com>
References: <CADGJaX_TPTJhGje1uXrh859=+ZrmbCLbD=9gtK6iUbkFJXXcrw@mail.gmail.com>
	<CAFm4XO0Q=MgfBsG6moVpxDAtDomKsS3Xf1E2fsytNqfYb1VyuQ@mail.gmail.com>
	<CADGJaX9QL_wGC1V3ey-=YcYsBdgf1wkR+fg-f1q90S8atfWghg@mail.gmail.com>
	<CAFm4XO0=uZGyAJhXJO_nu+pZgFk4kKjc=V=mYacFyaHmUPprLA@mail.gmail.com>
	<CALt0+o85Evn01G9-BQGpL10ZDzSYsJdezqKDMxG+TwB1emCgRA@mail.gmail.com>
Message-ID: <20160719171454.GC2145@hibernate.org>

Assuming we switch to the new mapping approach by default in 6.
Is there a way via mapping to use the old approach? Or would that
require some new annotation?

I understand the evolution arguments but frankly in a plain mongodb
document, I would have skipped the single property name. It's forced
upon me by Java here (at least the Enum case).

On Tue 2016-07-12 13:35, Guillaume Smet wrote:
> Hi,
> 
> For the sake of completeness, here is the mapping obtained with Morphia:
> { "_id" : ObjectId("5784ca2612d0226cb309666d"), "className" :
> "TestEntity", "embeddeds" : [ { "singleProperty" : "value1" }, {
> "singleProperty" : "value2" } ], "embedded" : { "singleProperty" :
> "value" }, "collectionOfStrings" : [ "string1", "string2" ] }
> They are basically following the POLA and follow the Java mapping for
> the MongoDB one.
> 
> Btw, to be complete, here are the reasons why I would like to change
> it (I agree we have to maintain compatibility with older databases
> but, as Sanne, I think it should be the new default):
> 1/ POLA: I would expect my datastore mapping to follow my Java mapping
> 2/ related to 1/: I wouldn't expect to have to migrate my data when I
> simply add a property to an existing embeddable
> 3/ remove special cases in our code, especially special cases present
> in the dialects
> 4/ I don't think we are completely consistent with this behavior.
> Typically, if I take StoryGame from our tests and remove all the
> properties but one from OptionalStoryBranch, I end up with the
> following:
> - in the datastore: "chaoticBranches" : [ "[VENDETTA] assassinate the
> leader of the party", "[ARTIFACT] Search for the evil artifact" ] -
> this is what we expect, only one property, we remove the property
> level
> - in the native query generated by our JPA query "FROM StoryGame story
> JOIN story.chaoticBranches c WHERE c.evilText = '[ARTIFACT] Search for
> the evil artifact'": where={ "chaoticBranches.evilText" : "[ARTIFACT]
> Search for the evil artifact"}
> -> so our JPQL queries don't work if we only have one property in the
> embedded. We might also want to special case this but I really don't
> think it's a good idea.
> 
> While this discussion might seem to come out of the blue, it's in fact
> related to OGM-893 and another special casing we do. See my comment
> here: https://hibernate.atlassian.net/browse/OGM-893?focusedCommentId=79245&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-79245
> . The mapping is changing when we add a @Column with a name for a
> property of an embedded in a collection element.
> 
> -- 
> Guillaume
> 
> On Tue, Jul 12, 2016 at 12:18 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> > On 12 July 2016 at 11:13, Gunnar Morling <gunnar at hibernate.org> wrote:
> >>> I'd be concerned about schema evolution:
> >>
> >> Yes, that's the main argument; as said, I can see that.
> >>
> >>> I'd see more value in making this the default, and have an "higher
> >>> level" configuration property which is like "read like OGM 5.0 used to
> >>> store it".
> >>
> >> I wouldn't like changing such default in a 5.x release. For 6, ok, why not,
> >> if you all think that's better.
> >
> > ok
> >
> >>
> >>> Even better, we'd provide tooling which migrates an existing database.
> >>
> >> Sure, migration support is on the roadmap ;)
> >>
> >>
> >>
> >>
> >>
> >> 2016-07-12 11:06 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>>
> >>> On 12 July 2016 at 10:55, Gunnar Morling <gunnar at hibernate.org> wrote:
> >>> > Hi,
> >>> >
> >>> > We had an interesting discussion on how to map element collections of
> >>> > component types with a single column to document stores such as MongoDB.
> >>> >
> >>> > E.g. assume we have
> >>> >
> >>> >     @Entity
> >>> >     public class Person {
> >>> >
> >>> >         public String name;
> >>> >
> >>> >         @ElementCollection
> >>> >         public List<Status> statusHistory;
> >>> >     }
> >>> >
> >>> >     @Embeddable
> >>> >     public class Status {
> >>> >         public String name;
> >>> >     }
> >>> >
> >>> >
> >>> > Currently, that's mapped to documents like this:
> >>> >
> >>> >     {
> >>> >         "name"  : "Bob";
> >>> >         "statusHistory" : [
> >>> >             "great",
> >>> >             "mediocre",
> >>> >             "splendid"
> >>> >         ]
> >>> >     }
> >>>
> >>> "great", "mediocre", etc.. are values of the `name` property?
> >>>
> >>> >
> >>> > I.e. if the component type has a single column, we omit the field name
> >>> > in
> >>> > the persistent structure. Whereas if there are multiple columns, it's
> >>> > added
> >>> > so we can properly read back such documents:
> >>> >
> >>> >
> >>> >     {
> >>> >         "name"  : "Bob";
> >>> >         "statusHistory" : [
> >>> >             { "name" : "great", "date" : "22.06.2016" },
> >>> >             { "name" : "mediocre", "date" : "15.05.2016" },
> >>> >             { "name" : "splendid", "date" : "12.04.2016" }
> >>> >         ]
> >>> >     }
> >>> >
> >>> > The question now is, should we also create such array of sub-documents,
> >>> > each containing the field name, in the case where there only is a single
> >>> > column. As far as I remember, the current structure has been chosen for
> >>> > the
> >>> > sake of efficiency but also simplicity (why deal with sub-documents if
> >>> > there only is a single field?).
> >>> >
> >>> > Guillaume is questioning the sanity of that, arguing that mapping this
> >>> > as
> >>> > an element collection of a component type rather than string should
> >>> > mandate
> >>> > the persistent structure to always contain the field name.
> >>>
> >>> I agree, but maybe for other reasons.
> >>> I'd be concerned about schema evolution: if I add a new attribute to
> >>> the `Status` class, say a "long timestampOfChance" for the sake of the
> >>> example,
> >>> as a developer I might want to consider this a nullable value as I'm
> >>> aware that my existing database didn't define this property so far.
> >>>
> >>> I wouldn't be happy to see failures on loading existing stored values
> >>> for Status#name : such mapping choices have to be very consistent.
> >>>
> >>> >
> >>> > We cannot change the default as we are committed to the MongoDB format,
> >>> > but
> >>> > if there is agreement that it's useful, we could add an option to enable
> >>> > this mapping.
> >>>
> >>> So many mapping options :-/
> >>>
> >>> I'd see more value in making this the default, and have an "higher
> >>> level" configuration property which is like "read like OGM 5.0 used to
> >>> store it".
> >>> Even better, we'd provide tooling which migrates an existing database.
> >>>
> >>> >
> >>> > I kind of see how this format simplifies migration (in case another
> >>> > field
> >>> > is added after a while), but personally I still like the more compact
> >>> > looks
> >>> > of the current approach. Having an option for it works for me.
> >>> >
> >>> > Any thoughts?
> >>> >
> >>> > --Gunnar
> >>> > _______________________________________________
> >>> > 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 sanne at hibernate.org  Tue Jul 19 13:27:32 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 19 Jul 2016 18:27:32 +0100
Subject: [hibernate-dev] [OGM] Mapping of component types in document
	stores
In-Reply-To: <20160719171454.GC2145@hibernate.org>
References: <CADGJaX_TPTJhGje1uXrh859=+ZrmbCLbD=9gtK6iUbkFJXXcrw@mail.gmail.com>
	<CAFm4XO0Q=MgfBsG6moVpxDAtDomKsS3Xf1E2fsytNqfYb1VyuQ@mail.gmail.com>
	<CADGJaX9QL_wGC1V3ey-=YcYsBdgf1wkR+fg-f1q90S8atfWghg@mail.gmail.com>
	<CAFm4XO0=uZGyAJhXJO_nu+pZgFk4kKjc=V=mYacFyaHmUPprLA@mail.gmail.com>
	<CALt0+o85Evn01G9-BQGpL10ZDzSYsJdezqKDMxG+TwB1emCgRA@mail.gmail.com>
	<20160719171454.GC2145@hibernate.org>
Message-ID: <CAFm4XO06Oyd_R6wB23zNG8Y_vHRVE8S7iTVybR0EaJONO4Qnow@mail.gmail.com>

On 19 July 2016 at 18:14, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> Assuming we switch to the new mapping approach by default in 6.
> Is there a way via mapping to use the old approach? Or would that
> require some new annotation?
>
> I understand the evolution arguments but frankly in a plain mongodb
> document, I would have skipped the single property name. It's forced
> upon me by Java here (at least the Enum case).

Good point, I guess I would have as well.

So the problem is not the mapping in se, but the fact that OGM takes
its own decisions and doesn't "see" the evolution of the schema over
time.

When a developer makes this choice explicitly, and later figures he
needs to add new properties, he has nobody else to blame than himself
and will have to deal with his own problem. The problem here is that
the might not be aware of the problem.

Rails applications have always encouraged to deal with app evolution
explicitly, adding schema migrations to the app changesets in version
control (and helping to apply them as needed). Wondering if Hibernate
should help more with this too, and consequentially be able to
automatically do something smarter in situations like this one.

Schema evolution is concerning me a bit with the Hot Rod dialect as
well: we're generating a protobuf schema automatically, however really
the strong point of protobuf is evolution, so my "protobuf generator"
feels naive as it doesn't take a pre-existing schema into account.

-- Sanne


>
> On Tue 2016-07-12 13:35, Guillaume Smet wrote:
>> Hi,
>>
>> For the sake of completeness, here is the mapping obtained with Morphia:
>> { "_id" : ObjectId("5784ca2612d0226cb309666d"), "className" :
>> "TestEntity", "embeddeds" : [ { "singleProperty" : "value1" }, {
>> "singleProperty" : "value2" } ], "embedded" : { "singleProperty" :
>> "value" }, "collectionOfStrings" : [ "string1", "string2" ] }
>> They are basically following the POLA and follow the Java mapping for
>> the MongoDB one.
>>
>> Btw, to be complete, here are the reasons why I would like to change
>> it (I agree we have to maintain compatibility with older databases
>> but, as Sanne, I think it should be the new default):
>> 1/ POLA: I would expect my datastore mapping to follow my Java mapping
>> 2/ related to 1/: I wouldn't expect to have to migrate my data when I
>> simply add a property to an existing embeddable
>> 3/ remove special cases in our code, especially special cases present
>> in the dialects
>> 4/ I don't think we are completely consistent with this behavior.
>> Typically, if I take StoryGame from our tests and remove all the
>> properties but one from OptionalStoryBranch, I end up with the
>> following:
>> - in the datastore: "chaoticBranches" : [ "[VENDETTA] assassinate the
>> leader of the party", "[ARTIFACT] Search for the evil artifact" ] -
>> this is what we expect, only one property, we remove the property
>> level
>> - in the native query generated by our JPA query "FROM StoryGame story
>> JOIN story.chaoticBranches c WHERE c.evilText = '[ARTIFACT] Search for
>> the evil artifact'": where={ "chaoticBranches.evilText" : "[ARTIFACT]
>> Search for the evil artifact"}
>> -> so our JPQL queries don't work if we only have one property in the
>> embedded. We might also want to special case this but I really don't
>> think it's a good idea.
>>
>> While this discussion might seem to come out of the blue, it's in fact
>> related to OGM-893 and another special casing we do. See my comment
>> here: https://hibernate.atlassian.net/browse/OGM-893?focusedCommentId=79245&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-79245
>> . The mapping is changing when we add a @Column with a name for a
>> property of an embedded in a collection element.
>>
>> --
>> Guillaume
>>
>> On Tue, Jul 12, 2016 at 12:18 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>> > On 12 July 2016 at 11:13, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >>> I'd be concerned about schema evolution:
>> >>
>> >> Yes, that's the main argument; as said, I can see that.
>> >>
>> >>> I'd see more value in making this the default, and have an "higher
>> >>> level" configuration property which is like "read like OGM 5.0 used to
>> >>> store it".
>> >>
>> >> I wouldn't like changing such default in a 5.x release. For 6, ok, why not,
>> >> if you all think that's better.
>> >
>> > ok
>> >
>> >>
>> >>> Even better, we'd provide tooling which migrates an existing database.
>> >>
>> >> Sure, migration support is on the roadmap ;)
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> 2016-07-12 11:06 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>>
>> >>> On 12 July 2016 at 10:55, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >>> > Hi,
>> >>> >
>> >>> > We had an interesting discussion on how to map element collections of
>> >>> > component types with a single column to document stores such as MongoDB.
>> >>> >
>> >>> > E.g. assume we have
>> >>> >
>> >>> >     @Entity
>> >>> >     public class Person {
>> >>> >
>> >>> >         public String name;
>> >>> >
>> >>> >         @ElementCollection
>> >>> >         public List<Status> statusHistory;
>> >>> >     }
>> >>> >
>> >>> >     @Embeddable
>> >>> >     public class Status {
>> >>> >         public String name;
>> >>> >     }
>> >>> >
>> >>> >
>> >>> > Currently, that's mapped to documents like this:
>> >>> >
>> >>> >     {
>> >>> >         "name"  : "Bob";
>> >>> >         "statusHistory" : [
>> >>> >             "great",
>> >>> >             "mediocre",
>> >>> >             "splendid"
>> >>> >         ]
>> >>> >     }
>> >>>
>> >>> "great", "mediocre", etc.. are values of the `name` property?
>> >>>
>> >>> >
>> >>> > I.e. if the component type has a single column, we omit the field name
>> >>> > in
>> >>> > the persistent structure. Whereas if there are multiple columns, it's
>> >>> > added
>> >>> > so we can properly read back such documents:
>> >>> >
>> >>> >
>> >>> >     {
>> >>> >         "name"  : "Bob";
>> >>> >         "statusHistory" : [
>> >>> >             { "name" : "great", "date" : "22.06.2016" },
>> >>> >             { "name" : "mediocre", "date" : "15.05.2016" },
>> >>> >             { "name" : "splendid", "date" : "12.04.2016" }
>> >>> >         ]
>> >>> >     }
>> >>> >
>> >>> > The question now is, should we also create such array of sub-documents,
>> >>> > each containing the field name, in the case where there only is a single
>> >>> > column. As far as I remember, the current structure has been chosen for
>> >>> > the
>> >>> > sake of efficiency but also simplicity (why deal with sub-documents if
>> >>> > there only is a single field?).
>> >>> >
>> >>> > Guillaume is questioning the sanity of that, arguing that mapping this
>> >>> > as
>> >>> > an element collection of a component type rather than string should
>> >>> > mandate
>> >>> > the persistent structure to always contain the field name.
>> >>>
>> >>> I agree, but maybe for other reasons.
>> >>> I'd be concerned about schema evolution: if I add a new attribute to
>> >>> the `Status` class, say a "long timestampOfChance" for the sake of the
>> >>> example,
>> >>> as a developer I might want to consider this a nullable value as I'm
>> >>> aware that my existing database didn't define this property so far.
>> >>>
>> >>> I wouldn't be happy to see failures on loading existing stored values
>> >>> for Status#name : such mapping choices have to be very consistent.
>> >>>
>> >>> >
>> >>> > We cannot change the default as we are committed to the MongoDB format,
>> >>> > but
>> >>> > if there is agreement that it's useful, we could add an option to enable
>> >>> > this mapping.
>> >>>
>> >>> So many mapping options :-/
>> >>>
>> >>> I'd see more value in making this the default, and have an "higher
>> >>> level" configuration property which is like "read like OGM 5.0 used to
>> >>> store it".
>> >>> Even better, we'd provide tooling which migrates an existing database.
>> >>>
>> >>> >
>> >>> > I kind of see how this format simplifies migration (in case another
>> >>> > field
>> >>> > is added after a while), but personally I still like the more compact
>> >>> > looks
>> >>> > of the current approach. Having an option for it works for me.
>> >>> >
>> >>> > Any thoughts?
>> >>> >
>> >>> > --Gunnar
>> >>> > _______________________________________________
>> >>> > 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 guillaume.smet at gmail.com  Tue Jul 19 18:50:51 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 20 Jul 2016 00:50:51 +0200
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <CAFm4XO01pFxt6CTjmgDZOMjG+h77VhDFmaeZVNiKVscgJvoiXw@mail.gmail.com>
References: <CALt0+o897FpJGR259OJaokyDmc0R6-rH5Fd=VUBBZtryeAUoEw@mail.gmail.com>
	<CAFm4XO01pFxt6CTjmgDZOMjG+h77VhDFmaeZVNiKVscgJvoiXw@mail.gmail.com>
Message-ID: <CALt0+o_eJ=YhrSi=JZdA0i7aLFOEkTFYTao+Yc54-oVT0Q0j2w@mail.gmail.com>

Hi Sanne,

Thanks for your feedback. I was pretty sure I hadn't all the history!

Getting Google to prioritize our latest doc is probably a long time goal.

I played a bit with jQuery to suggest to the user to go to the latest
stable. Note that I only took into consideration the page for the time
being and didn't consider the anchor but it should be easy to add it
if we think it's worth it (it's a lot more work on the json descriptor
though).

The following command for each version is all that is needed:
sed -i 's@</body>@<script
src="http://code.jquery.com/jquery-3.1.0.min.js"
integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
crossorigin="anonymous"></script><script
src="/hibernate/search/outdated-version.js"></script></body>@' *.html
(or a find -exec to do it on all the versions at once)

I attached the global json descriptor and the js file. Both should be
added to /hibernate/search/. Note that I only did the work for version
4.5 in the json descriptor. The work for other versions would mostly
be a copy/paste.

I also attached a screenshot of how it looks like. Nothing fancy but
we can do whatever we want.

Note that I only targeted the multi page HTML output as it was the
most interesting to prototype.

When we release a new version, we would have to update the descriptor file.

Comments?

-- 
Guillaume

On Tue, Jul 19, 2016 at 2:39 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> Hi Guillaume,
>
> yes I'm aware of the issue; we discussed it before, I think on this
> same mailing list but maybe it was during our last meeting.
>
> We really need to fix that metadata; Stefania (my partner) is an SEO
> consultant and is shocked at how bad we do with this; apparently we
> are a funny example in her office but at least we're not the worst :)
>
> The problem is we can't change the headers as we don't control the
> Apache httpd configuraion on the documentation server, so the
> alternative is we'd need to rsync those docs locally, insert the right
> changes in the static files of the docs, and push them back.
>
> Needs a volunteer to find some time for this.
>
> Also related to SEO I recently opened some issues on our WEBSITE
> project, these should be easier to fix as it's directly under our
> control:
>  - https://hibernate.atlassian.net/browse/WEBSITE-461
>  - https://hibernate.atlassian.net/browse/WEBSITE-460
>  - https://hibernate.atlassian.net/browse/WEBSITE-459
>
> I've assigned them to Davide as he's usually quick with such things
> but anyone is welcome to take some.
>
> The metadata issue on the docs server is probably the most urgent /
> valuable though.
>
> Thanks,
> Sanne

From guillaume.smet at gmail.com  Tue Jul 19 18:53:27 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 20 Jul 2016 00:53:27 +0200
Subject: [hibernate-dev] People can't find our docs
Message-ID: <CALt0+o9hA+aQ1feyLVf=+aB=4NMtJe8E2tGCjDJOae63MRS5AA@mail.gmail.com>

Hi Sanne,

Thanks for your feedback. I was pretty sure I hadn't all the history!

Getting Google to prioritize our latest doc is probably a long time goal.

I played a bit with jQuery to suggest to the user to go to the latest
stable. Note that I only took into consideration the page for the time
being and didn't consider the anchor but it should be easy to add it
if we think it's worth it (it's a lot more work on the json descriptor
though).

The following command for each version is all that is needed:
sed -i 's@</body>@<script
src="http://code.jquery.com/jquery-3.1.0.min.js"
integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
crossorigin="anonymous"></script><script
src="/hibernate/search/outdated-version.js"></script></body>@' *.html
(or a find -exec to do it on all the versions at once)

I attached the global json descriptor and the js file (with a .txt
extension as it didn't pass the mail filter). Both should be added to
/hibernate/search/. Note that I only did the work for version 4.5 in
the json descriptor. The work for other versions would mostly be a
copy/paste.

I also attached a screenshot of how it looks like. Nothing fancy but
we can do whatever we want.

Note that I only targeted the multi page HTML output as it was the
most interesting to prototype.

When we release a new version, we would have to update the descriptor file.

Comments?

--
Guillaume

On Tue, Jul 19, 2016 at 2:39 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> Hi Guillaume,
>
> yes I'm aware of the issue; we discussed it before, I think on this
> same mailing list but maybe it was during our last meeting.
>
> We really need to fix that metadata; Stefania (my partner) is an SEO
> consultant and is shocked at how bad we do with this; apparently we
> are a funny example in her office but at least we're not the worst :)
>
> The problem is we can't change the headers as we don't control the
> Apache httpd configuraion on the documentation server, so the
> alternative is we'd need to rsync those docs locally, insert the right
> changes in the static files of the docs, and push them back.
>
> Needs a volunteer to find some time for this.
>
> Also related to SEO I recently opened some issues on our WEBSITE
> project, these should be easier to fix as it's directly under our
> control:
>  - https://hibernate.atlassian.net/browse/WEBSITE-461
>  - https://hibernate.atlassian.net/browse/WEBSITE-460
>  - https://hibernate.atlassian.net/browse/WEBSITE-459
>
> I've assigned them to Davide as he's usually quick with such things
> but anyone is welcome to take some.
>
> The metadata issue on the docs server is probably the most urgent /
> valuable though.
>
> Thanks,
> Sanne
-------------- next part --------------
$(document).ready(function() {
	$.getJSON('/hibernate/search/documentation.json', function (json) {
		var currentUrl = window.location.pathname;
		var match = new RegExp('^' + json.pattern.replace('${version}', '([^/]+)').replace('${page}', '(.+\\.html)') + '$').exec(currentUrl);
		if (match.length != 3) {
			return;
		}
		var currentVersion = match[1];
		var currentPage = match[2];
		var currentHash = window.location.hash;
		
		if (currentVersion == json.stable || currentVersion == json.development || currentVersion == 'stable') {
			return;
		}
		
		var redirectPage;
		if (currentVersion in json.versions && currentPage in json.versions[currentVersion].redirects) {
			redirectPage = json.versions[currentVersion].redirects[currentPage];
		} else {
			redirectPage = '';
		}
		stableUrl = json.pattern.replace('${version}', json.stable).replace('${page}', redirectPage + currentHash);
		$('head').append('<style type="text/css">' +
			'.outdated-content {' +
			'	position: fixed;' +
			'	bottom: 0;' +
			'	left: 0;' +
			'	text-align:center;' +
			'	width:100%;' +
			'	padding: 20px;' +
			'	background-color: orange;' +
			'	background-color: #ffbc3b;' +
			'	border-top: 1px solid orange;' +
			'	font-weight: bold;' +
			'	font-size: 20px;' +
			'	color: white;' +
			'	text-shadow: 0 1px 1px rgba(85, 85, 85, 0.55)' +
			'}' +
			'a.version {' +
			'	border: 1px solid #AAA;' +
			'	border-radius: 4px;' +
			'	background-color: #BBB;' +
			'	padding: 3px 8px;' +
			'	color: white;' +
			'	text-shadow: 0 1px 1px rgba(85, 85, 85, 0.55);	' +
			'	text-decoration: none;' +
			'}' +
			'a.version:hover {' +
			'	background-color: #CCC;' +
			'}' +
		'</style>');
		$('body').append('<div class="outdated-content">This content refers to an outdated version of ' + json.project + '. Go to latest stable: <a href="' + stableUrl + '" class="version">version ' + json.stable +'</a>.</div>');
	})
});

From sanne at hibernate.org  Wed Jul 20 05:36:04 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 20 Jul 2016 10:36:04 +0100
Subject: [hibernate-dev] Needing and ORM 5.1.1.Final
Message-ID: <CAFm4XO1D2WeeQ_M4_U=ESDcOAPZRZ4QQueTHuqas5b_kgG7L_A@mail.gmail.com>

Hi all,
we're still needing a release of Hibernate ORM 5.1.1 for Hibernate OGM..

could we plan for one soon please?

Thanks,
Sanne

From davide at hibernate.org  Wed Jul 20 06:06:16 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 20 Jul 2016 11:06:16 +0100
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <CALt0+o9hA+aQ1feyLVf=+aB=4NMtJe8E2tGCjDJOae63MRS5AA@mail.gmail.com>
References: <CALt0+o9hA+aQ1feyLVf=+aB=4NMtJe8E2tGCjDJOae63MRS5AA@mail.gmail.com>
Message-ID: <CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>

I'll try to apply these changes on Friday.

Davide

On Tue, Jul 19, 2016 at 11:53 PM, Guillaume Smet
<guillaume.smet at gmail.com> wrote:
> Hi Sanne,
>
> Thanks for your feedback. I was pretty sure I hadn't all the history!
>
> Getting Google to prioritize our latest doc is probably a long time goal.
>
> I played a bit with jQuery to suggest to the user to go to the latest
> stable. Note that I only took into consideration the page for the time
> being and didn't consider the anchor but it should be easy to add it
> if we think it's worth it (it's a lot more work on the json descriptor
> though).
>
> The following command for each version is all that is needed:
> sed -i 's@</body>@<script
> src="http://code.jquery.com/jquery-3.1.0.min.js"
> integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
> crossorigin="anonymous"></script><script
> src="/hibernate/search/outdated-version.js"></script></body>@' *.html
> (or a find -exec to do it on all the versions at once)
>
> I attached the global json descriptor and the js file (with a .txt
> extension as it didn't pass the mail filter). Both should be added to
> /hibernate/search/. Note that I only did the work for version 4.5 in
> the json descriptor. The work for other versions would mostly be a
> copy/paste.
>
> I also attached a screenshot of how it looks like. Nothing fancy but
> we can do whatever we want.
>
> Note that I only targeted the multi page HTML output as it was the
> most interesting to prototype.
>
> When we release a new version, we would have to update the descriptor file.
>
> Comments?
>
> --
> Guillaume
>
> On Tue, Jul 19, 2016 at 2:39 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>> Hi Guillaume,
>>
>> yes I'm aware of the issue; we discussed it before, I think on this
>> same mailing list but maybe it was during our last meeting.
>>
>> We really need to fix that metadata; Stefania (my partner) is an SEO
>> consultant and is shocked at how bad we do with this; apparently we
>> are a funny example in her office but at least we're not the worst :)
>>
>> The problem is we can't change the headers as we don't control the
>> Apache httpd configuraion on the documentation server, so the
>> alternative is we'd need to rsync those docs locally, insert the right
>> changes in the static files of the docs, and push them back.
>>
>> Needs a volunteer to find some time for this.
>>
>> Also related to SEO I recently opened some issues on our WEBSITE
>> project, these should be easier to fix as it's directly under our
>> control:
>>  - https://hibernate.atlassian.net/browse/WEBSITE-461
>>  - https://hibernate.atlassian.net/browse/WEBSITE-460
>>  - https://hibernate.atlassian.net/browse/WEBSITE-459
>>
>> I've assigned them to Davide as he's usually quick with such things
>> but anyone is welcome to take some.
>>
>> The metadata issue on the docs server is probably the most urgent /
>> valuable though.
>>
>> Thanks,
>> Sanne
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From crancran at gmail.com  Wed Jul 20 11:05:49 2016
From: crancran at gmail.com (Chris Cranford)
Date: Wed, 20 Jul 2016 10:05:49 -0500
Subject: [hibernate-dev] Needing and ORM 5.1.1.Final
In-Reply-To: <CAFm4XO1D2WeeQ_M4_U=ESDcOAPZRZ4QQueTHuqas5b_kgG7L_A@mail.gmail.com>
References: <CAFm4XO1D2WeeQ_M4_U=ESDcOAPZRZ4QQueTHuqas5b_kgG7L_A@mail.gmail.com>
Message-ID: <7569820e-91ac-3daa-fbd6-7597e981660b@gmail.com>

Sanne -

I'm under the impression that Gail has plans to do a 5.0.10 / 5.1.1 late 
this week if all goes according to plan.

Chris


On 07/20/2016 04:36 AM, Sanne Grinovero wrote:
> Hi all,
> we're still needing a release of Hibernate ORM 5.1.1 for Hibernate OGM..
>
> could we plan for one soon please?
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From zerg2k at yahoo.com  Wed Jul 20 13:21:35 2016
From: zerg2k at yahoo.com (Noel Diaz)
Date: Wed, 20 Jul 2016 17:21:35 +0000 (UTC)
Subject: [hibernate-dev] [ORM] EhCache 3 and JCache
In-Reply-To: <CANjx1tVmq0k0oN_=THZ4u3Y9Q=+s6AtENrtAqdRaoNfj8kTH=w@mail.gmail.com>
References: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
	<CALt0+o-8qHLajz3FMju+oOm96Qd-+NLT0kOp=zz_p7SJDesMGg@mail.gmail.com>
	<CAFdSV9u=srQq8=hn3=1FKNHXgdODy1wa+qiycG9CrNRYA76UGQ@mail.gmail.com>
	<CANjx1tVwCkP3i205wu8Qwb2hL+UbGgNspQXHqmghARPCc7fhow@mail.gmail.com>
	<CAFdSV9uaN2gjbExuATEjkrb75C8th91x_Vu7Z19kTBC0mHQgag@mail.gmail.com>
	<CAFdSV9uCjJjQhtOrBA1ht5ccc3Q4HThtueF5BaLEjAtgDC=V3g@mail.gmail.com>
	<CANjx1tWeG4K8596QkBF90M-kNfeYVu7vuPiJYO2+9z+ocmybyQ@mail.gmail.com>
	<CAFdSV9sCc7SGUZ076rPBrOwJ21uP7XO4UhT0PcF0LJRXKD4m3A@mail.gmail.com>
	<574559AB.3010909@redhat.com>
	<CANjx1tVmq0k0oN_=THZ4u3Y9Q=+s6AtENrtAqdRaoNfj8kTH=w@mail.gmail.com>
Message-ID: <758567810.2557658.1469035295319.JavaMail.yahoo@mail.yahoo.com>

Hi Guys,
Is it possible to use EhCache 3.x with Hibernate 5.2 ??
Many Thanks,?
Noel
 

    On Wednesday, May 25, 2016 6:51 AM, Louis Jacomet <ljacomet at gmail.com> wrote:
 

 Hi,

I have opened the PR: https://github.com/hibernate/hibernate-orm/pull/1386

I'll be looking at the test referenced by Radim over the next days to see
what can be done.

Regards,
Louis

On Wed, May 25, 2016 at 9:52 AM Radim Vansa <rvansa at redhat.com> wrote:

> It would be very nice if different implemenations could share parts of
> the testsuite, no doubts about that.
>
> TCK (or functional tests) is useful to find out cases when the
> implementation does not adhere to specification (which is 'always return
> the same thing DB would' in the modes but nonstrict-rw). However, race
> conditions are different matter. From my experience a stress test that
> the developer runs for a couple of hours is more likely to hit race
> conditions, that won't show up in functional testsuite. It's possible
> that there would be less issues due to EhCache's locking nature of the
> implementation, though. And if the code is meant to be run in clustered
> environment, it has to be tested that way, as distributed systems tend
> to behave in unexpected manners.
>
> I've written a stress test [1] that covers the basic operations but
> don't take it as "passed => it's correct". I've tweaked the parameters
> (most notably NUM_FAMILIES) and probabilities of operations (e.g.
> removing the InvalidateCache as this breaks many transactions) to
> manifest different situations. Also, it's important to test with both H2
> 1.3 and H2 1.4 as these use different locking semantics, leading to
> races or deadlocks.
>
> It shouldn't be hard to reuse most of it - Infinispan specific code
> deals only with test setup and then introduces random failures in the
> operations (as RPC/locking timeouts or other errors happen in a
> distributed system). Trying to reuse the functional testsuite will be
> more time-demanding task.
>
> Radim
>
> [1]
>
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/stress/CorrectnessTestCase.java
>
> On 05/25/2016 01:24 AM, Steve Ebersole wrote:
> > Master is 5.2.? There was a previous discussion on this list detailing
> the
> > 5.2 changes.? Where possible we did not change APIs (though there were a
> > few cases where that was needed to avoid clashes with JPA method names).
> > We did change lots of SPIs though.
> >
> > If you are willing to commit to getting this to us early next week, I
> > commit to reviewing the PR.? I'd feel most comfortable if Sanne looked it
> > over as well.
> >
> > Also, I do think it would be worthwhile to investigate a "cache provider
> > tck".? Radio, thoughts?
> >
> > On Tue, May 24, 2016, 4:27 PM Louis Jacomet <ljacomet at gmail.com> wrote:
> >
> >> Hey Steve,
> >>
> >> That's a tough question.
> >> For tomorrow I don't see how ... Technically the code is out there. But
> it
> >> lacks documentation which is needed: how to select a specific provider
> and
> >> specify a URI which can be used as config source. That still needs to be
> >> added.
> >>
> >> In one week, more likely. I am willing to commit on having it all in
> >> proper shape.
> >>
> >> Which branch will 5.2 be cut from? Because when I last checked some
> >> changes happened in master that impacted api but seem to be identified
> as
> >> 6.0 related.
> >>
> >> What are the chances someone from the hibernate side can look at it in
> >> this timeframe? To make sure nothing dumb slips through.
> >>
> >> Regards,
> >> Louis
> >>
> >>
> >> On mar. 24 mai 2016 at 22:57, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>
> >>> https://hibernate.atlassian.net/browse/HHH-10770
> >>>
> >>> On Tue, May 24, 2016 at 3:51 PM Steve Ebersole <steve at hibernate.org>
> >>> wrote:
> >>>
> >>>> Hi Louis,
> >>>>
> >>>> In my opinion,
> >>>>
> >>>>? ? - Yes, of course :)
> >>>>? ? - The plan is to release 5.2 tomorrow.? So either this would have
> to
> >>>>? ? be done tomorrow or the release date pushed back in order for
> this to be
> >>>>? ? part of 5.2.? We could push 5.2 another week, but would the work
> for this
> >>>>? ? be done in a week?
> >>>>
> >>>>
> >>>> On Tue, May 24, 2016 at 3:39 PM Louis Jacomet <ljacomet at gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> I have a couple questions:
> >>>>> * Should there be an issue created to track this work?
> >>>>> * On which branch should this work based if we target a release with
> >>>>> 5.2?
> >>>>>
> >>>>> In parallel, I have been reading the pointers Vlad gave and I intend
> to
> >>>>> verify the current code actually works in all these cases :-) Any
> chance
> >>>>> there exist some kind of test suite for L2 caching providers?
> >>>>>
> >>>>> Regards,
> >>>>> Louis
> >>>>>
> >>>>> On Fri, May 20, 2016 at 3:41 PM Steve Ebersole <steve at hibernate.org>
> >>>>> wrote:
> >>>>>
> >>>>>> What we had decided before during a discussion with myself, Alex
> Snaps,
> >>>>>> Radim and Sanne was to develop a JCache-based L2 case module and
> that
> >>>>>> Ehcache 3 would be supported through that mechanism.? We'd continue
> >>>>>> support
> >>>>>> for the current Ehcahce 2 based hibernate-ehcache module for a short
> >>>>>> period
> >>>>>> of time.
> >>>>>>
> >>>>>> On Fri, May 20, 2016 at 7:48 AM Guillaume Smet <
> >>>>>> guillaume.smet at gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard <
> >>>>>> emmanuel at hibernate.org>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> 3. change the Ehcache module and move it from v2 to v3
> >>>>>>>>
> >>>>>>> Please don't do that.
> >>>>>>>
> >>>>>>> I'm pretty sure users will need to test Ehcache 3 before going live
> >>>>>> and it
> >>>>>>> shouldn't be tied to an Hibernate upgrade. Cache is a very sensible
> >>>>>> subject
> >>>>>>> and I'm pretty sure moving to Ehcache 3 will come with its
> >>>>>> challenges. We
> >>>>>>> should at least have 1 or 2 versions allowing both Ehcache 2 and 3.
> >>>>>>>
> >>>>>>> Moreover, last time I checked, there was no Jgroups replication yet
> >>>>>> in
> >>>>>>> Ehcache 3 (or it's not documented).
> >>>>>>>
> >>>>>>> --
> >>>>>>> Guillaume
> >>>>>>> _______________________________________________
> >>>>>>> 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
>
>
> --
> 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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


  

From emmanuel at hibernate.org  Wed Jul 20 13:49:51 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 20 Jul 2016 19:49:51 +0200
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
Message-ID: <4FC109C0-070E-4D20-9D24-AABEF7B9133C@hibernate.org>

I just read it. Some random remarks.

Small correction on the description of the legacy Type also offers a navigation on the cardinality and knowledge of the Hibernate structures like assocaitions (one to one etc), component, any etc and mutability. But that?s minor and all covered by your proposal.

BasicType does not handle multiple column and compositeType is the mebedded case. How would multi-column types would be handled?

Positional types only, not named columns: that is likely going to impact OGM and it needs to play well with that new approach. Guillaume or Davide, if you ahve 30 mins to spare, that might be interesting to check how the GridType could cope with positional parameters and not named columns for ?nullSafeSet / Get calls"

Why do you need to ?unscope" the TypeConfiguration? What do you gain from it? I?m trying to picture a reuse use case?

Methods of Type needing Session: I used to call them passing null in some old code and hoping for the best. Are the reasons for using Session still present? Would be nice to get rid of that.

On the genericization of Type, it would be extremely nice indeed for OGM, but it would require to genericize SqlTypeDescriptor and its methods essentially. Not necessarily super trivial.


> On 22 Jun 2016, at 18:54, Steve Ebersole <steve at hibernate.org> wrote:
> 
> I started a wiki discussing the proposal for the type system redesign.
> Let's get discussions about it starter sooner rather than later.  Thanks!
> 
> https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From ljacomet at gmail.com  Wed Jul 20 14:18:12 2016
From: ljacomet at gmail.com (Louis Jacomet)
Date: Wed, 20 Jul 2016 18:18:12 +0000
Subject: [hibernate-dev] [ORM] EhCache 3 and JCache
In-Reply-To: <758567810.2557658.1469035295319.JavaMail.yahoo@mail.yahoo.com>
References: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
	<CALt0+o-8qHLajz3FMju+oOm96Qd-+NLT0kOp=zz_p7SJDesMGg@mail.gmail.com>
	<CAFdSV9u=srQq8=hn3=1FKNHXgdODy1wa+qiycG9CrNRYA76UGQ@mail.gmail.com>
	<CANjx1tVwCkP3i205wu8Qwb2hL+UbGgNspQXHqmghARPCc7fhow@mail.gmail.com>
	<CAFdSV9uaN2gjbExuATEjkrb75C8th91x_Vu7Z19kTBC0mHQgag@mail.gmail.com>
	<CAFdSV9uCjJjQhtOrBA1ht5ccc3Q4HThtueF5BaLEjAtgDC=V3g@mail.gmail.com>
	<CANjx1tWeG4K8596QkBF90M-kNfeYVu7vuPiJYO2+9z+ocmybyQ@mail.gmail.com>
	<CAFdSV9sCc7SGUZ076rPBrOwJ21uP7XO4UhT0PcF0LJRXKD4m3A@mail.gmail.com>
	<574559AB.3010909@redhat.com>
	<CANjx1tVmq0k0oN_=THZ4u3Y9Q=+s6AtENrtAqdRaoNfj8kTH=w@mail.gmail.com>
	<758567810.2557658.1469035295319.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CANjx1tWxJVVA3_Wo8VRscgVOo2fX-RbNZz1-XHMOGG3cEapnfw@mail.gmail.com>

Hi Noel,

Yes this is available in Hibernate 5.2.

Have a look at
http://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/Hibernate_User_Guide.html#caching-provider-jcache

You can of course use Ehcache 3.x as the JCache implementation - for which
documentation is available at
http://www.ehcache.org/documentation/3.1/107.html but does not cover any
hibernate specifics.

And of course, it should work for any JCache provider out there.

Regards,
Louis

On Wed, Jul 20, 2016 at 7:21 PM Noel Diaz <zerg2k at yahoo.com> wrote:

> Hi Guys,
>
> Is it possible to use EhCache 3.x with Hibernate 5.2 ?
>
> Many Thanks,
>
> Noel
>
>
>
> On Wednesday, May 25, 2016 6:51 AM, Louis Jacomet <ljacomet at gmail.com>
> wrote:
>
>
> Hi,
>
> I have opened the PR: https://github.com/hibernate/hibernate-orm/pull/1386
>
> I'll be looking at the test referenced by Radim over the next days to see
> what can be done.
>
> Regards,
> Louis
>
> On Wed, May 25, 2016 at 9:52 AM Radim Vansa <rvansa at redhat.com> wrote:
>
> > It would be very nice if different implemenations could share parts of
> > the testsuite, no doubts about that.
> >
> > TCK (or functional tests) is useful to find out cases when the
> > implementation does not adhere to specification (which is 'always return
> > the same thing DB would' in the modes but nonstrict-rw). However, race
> > conditions are different matter. From my experience a stress test that
> > the developer runs for a couple of hours is more likely to hit race
> > conditions, that won't show up in functional testsuite. It's possible
> > that there would be less issues due to EhCache's locking nature of the
> > implementation, though. And if the code is meant to be run in clustered
> > environment, it has to be tested that way, as distributed systems tend
> > to behave in unexpected manners.
> >
> > I've written a stress test [1] that covers the basic operations but
> > don't take it as "passed => it's correct". I've tweaked the parameters
> > (most notably NUM_FAMILIES) and probabilities of operations (e.g.
> > removing the InvalidateCache as this breaks many transactions) to
> > manifest different situations. Also, it's important to test with both H2
> > 1.3 and H2 1.4 as these use different locking semantics, leading to
> > races or deadlocks.
> >
> > It shouldn't be hard to reuse most of it - Infinispan specific code
> > deals only with test setup and then introduces random failures in the
> > operations (as RPC/locking timeouts or other errors happen in a
> > distributed system). Trying to reuse the functional testsuite will be
> > more time-demanding task.
> >
> > Radim
> >
> > [1]
> >
> >
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/stress/CorrectnessTestCase.java
> >
> > On 05/25/2016 01:24 AM, Steve Ebersole wrote:
> > > Master is 5.2.  There was a previous discussion on this list detailing
> > the
> > > 5.2 changes.  Where possible we did not change APIs (though there were
> a
> > > few cases where that was needed to avoid clashes with JPA method
> names).
> > > We did change lots of SPIs though.
> > >
> > > If you are willing to commit to getting this to us early next week, I
> > > commit to reviewing the PR.  I'd feel most comfortable if Sanne looked
> it
> > > over as well.
> > >
> > > Also, I do think it would be worthwhile to investigate a "cache
> provider
> > > tck".  Radio, thoughts?
> > >
> > > On Tue, May 24, 2016, 4:27 PM Louis Jacomet <ljacomet at gmail.com>
> wrote:
> > >
> > >> Hey Steve,
> > >>
> > >> That's a tough question.
> > >> For tomorrow I don't see how ... Technically the code is out there.
> But
> > it
> > >> lacks documentation which is needed: how to select a specific provider
> > and
> > >> specify a URI which can be used as config source. That still needs to
> be
> > >> added.
> > >>
> > >> In one week, more likely. I am willing to commit on having it all in
> > >> proper shape.
> > >>
> > >> Which branch will 5.2 be cut from? Because when I last checked some
> > >> changes happened in master that impacted api but seem to be identified
> > as
> > >> 6.0 related.
> > >>
> > >> What are the chances someone from the hibernate side can look at it in
> > >> this timeframe? To make sure nothing dumb slips through.
> > >>
> > >> Regards,
> > >> Louis
> > >>
> > >>
> > >> On mar. 24 mai 2016 at 22:57, Steve Ebersole <steve at hibernate.org>
> > wrote:
> > >>
> > >>> https://hibernate.atlassian.net/browse/HHH-10770
> > >>>
> > >>> On Tue, May 24, 2016 at 3:51 PM Steve Ebersole <steve at hibernate.org>
> > >>> wrote:
> > >>>
> > >>>> Hi Louis,
> > >>>>
> > >>>> In my opinion,
> > >>>>
> > >>>>    - Yes, of course :)
> > >>>>    - The plan is to release 5.2 tomorrow.  So either this would have
> > to
> > >>>>    be done tomorrow or the release date pushed back in order for
> > this to be
> > >>>>    part of 5.2.  We could push 5.2 another week, but would the work
> > for this
> > >>>>    be done in a week?
> > >>>>
> > >>>>
> > >>>> On Tue, May 24, 2016 at 3:39 PM Louis Jacomet <ljacomet at gmail.com>
> > >>>> wrote:
> > >>>>
> > >>>>> Hello,
> > >>>>>
> > >>>>> I have a couple questions:
> > >>>>> * Should there be an issue created to track this work?
> > >>>>> * On which branch should this work based if we target a release
> with
> > >>>>> 5.2?
> > >>>>>
> > >>>>> In parallel, I have been reading the pointers Vlad gave and I
> intend
> > to
> > >>>>> verify the current code actually works in all these cases :-) Any
> > chance
> > >>>>> there exist some kind of test suite for L2 caching providers?
> > >>>>>
> > >>>>> Regards,
> > >>>>> Louis
> > >>>>>
> > >>>>> On Fri, May 20, 2016 at 3:41 PM Steve Ebersole <
> steve at hibernate.org>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> What we had decided before during a discussion with myself, Alex
> > Snaps,
> > >>>>>> Radim and Sanne was to develop a JCache-based L2 case module and
> > that
> > >>>>>> Ehcache 3 would be supported through that mechanism.  We'd
> continue
> > >>>>>> support
> > >>>>>> for the current Ehcahce 2 based hibernate-ehcache module for a
> short
> > >>>>>> period
> > >>>>>> of time.
> > >>>>>>
> > >>>>>> On Fri, May 20, 2016 at 7:48 AM Guillaume Smet <
> > >>>>>> guillaume.smet at gmail.com>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> Hi,
> > >>>>>>>
> > >>>>>>> On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard <
> > >>>>>> emmanuel at hibernate.org>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> 3. change the Ehcache module and move it from v2 to v3
> > >>>>>>>>
> > >>>>>>> Please don't do that.
> > >>>>>>>
> > >>>>>>> I'm pretty sure users will need to test Ehcache 3 before going
> live
> > >>>>>> and it
> > >>>>>>> shouldn't be tied to an Hibernate upgrade. Cache is a very
> sensible
> > >>>>>> subject
> > >>>>>>> and I'm pretty sure moving to Ehcache 3 will come with its
> > >>>>>> challenges. We
> > >>>>>>> should at least have 1 or 2 versions allowing both Ehcache 2 and
> 3.
> > >>>>>>>
> > >>>>>>> Moreover, last time I checked, there was no Jgroups replication
> yet
> > >>>>>> in
> > >>>>>>> Ehcache 3 (or it's not documented).
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Guillaume
> > >>>>>>> _______________________________________________
> > >>>>>>> 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
> >
> >
> > --
> > 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
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>

From zerg2k at yahoo.com  Wed Jul 20 14:22:00 2016
From: zerg2k at yahoo.com (Noel Diaz)
Date: Wed, 20 Jul 2016 18:22:00 +0000 (UTC)
Subject: [hibernate-dev] [ORM] EhCache 3 and JCache
In-Reply-To: <CANjx1tWxJVVA3_Wo8VRscgVOo2fX-RbNZz1-XHMOGG3cEapnfw@mail.gmail.com>
References: <94FCCFD1-0AFE-496A-B232-032DA66186A3@hibernate.org>
	<CALt0+o-8qHLajz3FMju+oOm96Qd-+NLT0kOp=zz_p7SJDesMGg@mail.gmail.com>
	<CAFdSV9u=srQq8=hn3=1FKNHXgdODy1wa+qiycG9CrNRYA76UGQ@mail.gmail.com>
	<CANjx1tVwCkP3i205wu8Qwb2hL+UbGgNspQXHqmghARPCc7fhow@mail.gmail.com>
	<CAFdSV9uaN2gjbExuATEjkrb75C8th91x_Vu7Z19kTBC0mHQgag@mail.gmail.com>
	<CAFdSV9uCjJjQhtOrBA1ht5ccc3Q4HThtueF5BaLEjAtgDC=V3g@mail.gmail.com>
	<CANjx1tWeG4K8596QkBF90M-kNfeYVu7vuPiJYO2+9z+ocmybyQ@mail.gmail.com>
	<CAFdSV9sCc7SGUZ076rPBrOwJ21uP7XO4UhT0PcF0LJRXKD4m3A@mail.gmail.com>
	<574559AB.3010909@redhat.com>
	<CANjx1tVmq0k0oN_=THZ4u3Y9Q=+s6AtENrtAqdRaoNfj8kTH=w@mail.gmail.com>
	<758567810.2557658.1469035295319.JavaMail.yahoo@mail.yahoo.com>
	<CANjx1tWxJVVA3_Wo8VRscgVOo2fX-RbNZz1-XHMOGG3cEapnfw@mail.gmail.com>
Message-ID: <1443700490.2609505.1469038920528.JavaMail.yahoo@mail.yahoo.com>

Thank you very much for the quick reply!
Noel 

    On Wednesday, July 20, 2016 2:18 PM, Louis Jacomet <ljacomet at gmail.com> wrote:
 

 Hi Noel,
Yes this is available in Hibernate 5.2.
Have a look at?http://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/Hibernate_User_Guide.html#caching-provider-jcache
You can of course use Ehcache 3.x as the JCache implementation - for which documentation is available at?http://www.ehcache.org/documentation/3.1/107.html?but does not cover any hibernate specifics.
And of course, it should work for any JCache provider out there.
Regards,Louis
On Wed, Jul 20, 2016 at 7:21 PM Noel Diaz <zerg2k at yahoo.com> wrote:

Hi Guys,
Is it possible to use EhCache 3.x with Hibernate 5.2 ??
Many Thanks,?
Noel
 

    On Wednesday, May 25, 2016 6:51 AM, Louis Jacomet <ljacomet at gmail.com> wrote:
 

 Hi,

I have opened the PR: https://github.com/hibernate/hibernate-orm/pull/1386

I'll be looking at the test referenced by Radim over the next days to see
what can be done.

Regards,
Louis

On Wed, May 25, 2016 at 9:52 AM Radim Vansa <rvansa at redhat.com> wrote:

> It would be very nice if different implemenations could share parts of
> the testsuite, no doubts about that.
>
> TCK (or functional tests) is useful to find out cases when the
> implementation does not adhere to specification (which is 'always return
> the same thing DB would' in the modes but nonstrict-rw). However, race
> conditions are different matter. From my experience a stress test that
> the developer runs for a couple of hours is more likely to hit race
> conditions, that won't show up in functional testsuite. It's possible
> that there would be less issues due to EhCache's locking nature of the
> implementation, though. And if the code is meant to be run in clustered
> environment, it has to be tested that way, as distributed systems tend
> to behave in unexpected manners.
>
> I've written a stress test [1] that covers the basic operations but
> don't take it as "passed => it's correct". I've tweaked the parameters
> (most notably NUM_FAMILIES) and probabilities of operations (e.g.
> removing the InvalidateCache as this breaks many transactions) to
> manifest different situations. Also, it's important to test with both H2
> 1.3 and H2 1.4 as these use different locking semantics, leading to
> races or deadlocks.
>
> It shouldn't be hard to reuse most of it - Infinispan specific code
> deals only with test setup and then introduces random failures in the
> operations (as RPC/locking timeouts or other errors happen in a
> distributed system). Trying to reuse the functional testsuite will be
> more time-demanding task.
>
> Radim
>
> [1]
>
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/stress/CorrectnessTestCase.java
>
> On 05/25/2016 01:24 AM, Steve Ebersole wrote:
> > Master is 5.2.? There was a previous discussion on this list detailing
> the
> > 5.2 changes.? Where possible we did not change APIs (though there were a
> > few cases where that was needed to avoid clashes with JPA method names).
> > We did change lots of SPIs though.
> >
> > If you are willing to commit to getting this to us early next week, I
> > commit to reviewing the PR.? I'd feel most comfortable if Sanne looked it
> > over as well.
> >
> > Also, I do think it would be worthwhile to investigate a "cache provider
> > tck".? Radio, thoughts?
> >
> > On Tue, May 24, 2016, 4:27 PM Louis Jacomet <ljacomet at gmail.com> wrote:
> >
> >> Hey Steve,
> >>
> >> That's a tough question.
> >> For tomorrow I don't see how ... Technically the code is out there. But
> it
> >> lacks documentation which is needed: how to select a specific provider
> and
> >> specify a URI which can be used as config source. That still needs to be
> >> added.
> >>
> >> In one week, more likely. I am willing to commit on having it all in
> >> proper shape.
> >>
> >> Which branch will 5.2 be cut from? Because when I last checked some
> >> changes happened in master that impacted api but seem to be identified
> as
> >> 6.0 related.
> >>
> >> What are the chances someone from the hibernate side can look at it in
> >> this timeframe? To make sure nothing dumb slips through.
> >>
> >> Regards,
> >> Louis
> >>
> >>
> >> On mar. 24 mai 2016 at 22:57, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>
> >>> https://hibernate.atlassian.net/browse/HHH-10770
> >>>
> >>> On Tue, May 24, 2016 at 3:51 PM Steve Ebersole <steve at hibernate.org>
> >>> wrote:
> >>>
> >>>> Hi Louis,
> >>>>
> >>>> In my opinion,
> >>>>
> >>>>? ? - Yes, of course :)
> >>>>? ? - The plan is to release 5.2 tomorrow.? So either this would have
> to
> >>>>? ? be done tomorrow or the release date pushed back in order for
> this to be
> >>>>? ? part of 5.2.? We could push 5.2 another week, but would the work
> for this
> >>>>? ? be done in a week?
> >>>>
> >>>>
> >>>> On Tue, May 24, 2016 at 3:39 PM Louis Jacomet <ljacomet at gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> I have a couple questions:
> >>>>> * Should there be an issue created to track this work?
> >>>>> * On which branch should this work based if we target a release with
> >>>>> 5.2?
> >>>>>
> >>>>> In parallel, I have been reading the pointers Vlad gave and I intend
> to
> >>>>> verify the current code actually works in all these cases :-) Any
> chance
> >>>>> there exist some kind of test suite for L2 caching providers?
> >>>>>
> >>>>> Regards,
> >>>>> Louis
> >>>>>
> >>>>> On Fri, May 20, 2016 at 3:41 PM Steve Ebersole <steve at hibernate.org>
> >>>>> wrote:
> >>>>>
> >>>>>> What we had decided before during a discussion with myself, Alex
> Snaps,
> >>>>>> Radim and Sanne was to develop a JCache-based L2 case module and
> that
> >>>>>> Ehcache 3 would be supported through that mechanism.? We'd continue
> >>>>>> support
> >>>>>> for the current Ehcahce 2 based hibernate-ehcache module for a short
> >>>>>> period
> >>>>>> of time.
> >>>>>>
> >>>>>> On Fri, May 20, 2016 at 7:48 AM Guillaume Smet <
> >>>>>> guillaume.smet at gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard <
> >>>>>> emmanuel at hibernate.org>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> 3. change the Ehcache module and move it from v2 to v3
> >>>>>>>>
> >>>>>>> Please don't do that.
> >>>>>>>
> >>>>>>> I'm pretty sure users will need to test Ehcache 3 before going live
> >>>>>> and it
> >>>>>>> shouldn't be tied to an Hibernate upgrade. Cache is a very sensible
> >>>>>> subject
> >>>>>>> and I'm pretty sure moving to Ehcache 3 will come with its
> >>>>>> challenges. We
> >>>>>>> should at least have 1 or 2 versions allowing both Ehcache 2 and 3.
> >>>>>>>
> >>>>>>> Moreover, last time I checked, there was no Jgroups replication yet
> >>>>>> in
> >>>>>>> Ehcache 3 (or it's not documented).
> >>>>>>>
> >>>>>>> --
> >>>>>>> Guillaume
> >>>>>>> _______________________________________________
> >>>>>>> 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
>
>
> --
> 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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


   


  

From guillaume.smet at gmail.com  Thu Jul 21 07:33:49 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 21 Jul 2016 13:33:49 +0200
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>
References: <CALt0+o9hA+aQ1feyLVf=+aB=4NMtJe8E2tGCjDJOae63MRS5AA@mail.gmail.com>
	<CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>
Message-ID: <CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>

Hi all!

So here is a status of what I did:
- I updated the /stable/ link of ogm from 3.0 (cough, cough) to 5.0:
http://docs.jboss.org/hibernate/stable/ogm/reference/en-US/html/: we
need to include this in our release process.
- I updated the /current/ symlink of ORM to point to 5.2 instead of
5.1: it needs to be integrated in the release process; (the /stable/
link uses the /current/ symlink so it's also fixed)
- I removed the docs for OGM 3.0 as they were a copy of the doc of OGM 4.2

Next, I applied some magic to 2 old versions of OGM and Search so that
you can check everything is OK for you before I generalize it:
- Add meta description and keywords
- Add a canonical link to the /stable/ single html version
- Add a piece of Javascript to warn the user and propose to redirect
him to the best possible place of our last stable release
documentation

See the 2 examples here:
http://docs.jboss.org.local/hibernate/ogm/4.1/reference/en-US/html/ogm-architecture.html
(scroll to see the hash tracker in action)
http://docs.jboss.org/hibernate/search/4.2/reference/en-US/html/search-architecture.html

See the current code and descriptors here:
https://docs.jboss.org/hibernate/_outdated-content/

The script and the descriptors work for all existing versions of the
OGM and Search doc.

The marker to include in the docs looks like that:
<script src="//code.jquery.com/jquery-3.1.0.min.js"
integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
crossorigin="anonymous"></script>
<script src="/hibernate/_outdated-content/outdated-content.js"
type="text/javascript"></script>
<script type="text/javascript">$(document).ready(function() {
HibernateDoc.OutdatedContent.install("search"); });</script>

(I'm using a CDN but maybe we should host jQuery on docs.jboss.org?)

The script is capable to redirect either to the multi page version
(using the redirects declared in the JSON file: it automatically
cumulates the redirects from version X to version Y so we don't need
that much metadata) or to the single page version by leveraging the
anchors and hashes. For now, I decided to push the user to the single
page version as it's the one we use for the canonical link but we can
of course discuss it. Note that I add a ?v=X.X parameter to be sure
the user is redirected to a fresh version of the corresponding
/stable/ page and not a cache. I had the issue a couple of times.

Next if you like it:
- generalize it to all the existing versions of the docs, sed FTW
- modify the Hibernate XSL stylesheets to include it in the newly generated ones
- probably modify our website so that the stable release points to the
/stable/ link to the docs
- do the same for Validator

@ORM: interested in me pursuing this for ORM too? It will probably be
a lot more work as the structure of the docs got changed a lot.

Comments, opinions, thoughts welcome.

-- 
Guillaume

On Wed, Jul 20, 2016 at 12:06 PM, Davide D'Alto <davide at hibernate.org> wrote:
> I'll try to apply these changes on Friday.
>
> Davide
>
> On Tue, Jul 19, 2016 at 11:53 PM, Guillaume Smet
> <guillaume.smet at gmail.com> wrote:
>> Hi Sanne,
>>
>> Thanks for your feedback. I was pretty sure I hadn't all the history!
>>
>> Getting Google to prioritize our latest doc is probably a long time goal.
>>
>> I played a bit with jQuery to suggest to the user to go to the latest
>> stable. Note that I only took into consideration the page for the time
>> being and didn't consider the anchor but it should be easy to add it
>> if we think it's worth it (it's a lot more work on the json descriptor
>> though).
>>
>> The following command for each version is all that is needed:
>> sed -i 's@</body>@<script
>> src="http://code.jquery.com/jquery-3.1.0.min.js"
>> integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
>> crossorigin="anonymous"></script><script
>> src="/hibernate/search/outdated-version.js"></script></body>@' *.html
>> (or a find -exec to do it on all the versions at once)
>>
>> I attached the global json descriptor and the js file (with a .txt
>> extension as it didn't pass the mail filter). Both should be added to
>> /hibernate/search/. Note that I only did the work for version 4.5 in
>> the json descriptor. The work for other versions would mostly be a
>> copy/paste.
>>
>> I also attached a screenshot of how it looks like. Nothing fancy but
>> we can do whatever we want.
>>
>> Note that I only targeted the multi page HTML output as it was the
>> most interesting to prototype.
>>
>> When we release a new version, we would have to update the descriptor file.
>>
>> Comments?
>>
>> --
>> Guillaume

From guillaume.smet at gmail.com  Thu Jul 21 07:34:57 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 21 Jul 2016 13:34:57 +0200
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
References: <CALt0+o9hA+aQ1feyLVf=+aB=4NMtJe8E2tGCjDJOae63MRS5AA@mail.gmail.com>
	<CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>
	<CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
Message-ID: <CALt0+o_rXsWtM-sx63r3Gs4D4Rz5z2GdcFOU=yFcBgP0oL-Wqw@mail.gmail.com>

Iiiik, remove the .local suffix in the domain for the first example!

On Thu, Jul 21, 2016 at 1:33 PM, Guillaume Smet
<guillaume.smet at gmail.com> wrote:
> Hi all!
>
> So here is a status of what I did:
> - I updated the /stable/ link of ogm from 3.0 (cough, cough) to 5.0:
> http://docs.jboss.org/hibernate/stable/ogm/reference/en-US/html/: we
> need to include this in our release process.
> - I updated the /current/ symlink of ORM to point to 5.2 instead of
> 5.1: it needs to be integrated in the release process; (the /stable/
> link uses the /current/ symlink so it's also fixed)
> - I removed the docs for OGM 3.0 as they were a copy of the doc of OGM 4.2
>
> Next, I applied some magic to 2 old versions of OGM and Search so that
> you can check everything is OK for you before I generalize it:
> - Add meta description and keywords
> - Add a canonical link to the /stable/ single html version
> - Add a piece of Javascript to warn the user and propose to redirect
> him to the best possible place of our last stable release
> documentation
>
> See the 2 examples here:
> http://docs.jboss.org.local/hibernate/ogm/4.1/reference/en-US/html/ogm-architecture.html
> (scroll to see the hash tracker in action)
> http://docs.jboss.org/hibernate/search/4.2/reference/en-US/html/search-architecture.html
>
> See the current code and descriptors here:
> https://docs.jboss.org/hibernate/_outdated-content/
>
> The script and the descriptors work for all existing versions of the
> OGM and Search doc.
>
> The marker to include in the docs looks like that:
> <script src="//code.jquery.com/jquery-3.1.0.min.js"
> integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
> crossorigin="anonymous"></script>
> <script src="/hibernate/_outdated-content/outdated-content.js"
> type="text/javascript"></script>
> <script type="text/javascript">$(document).ready(function() {
> HibernateDoc.OutdatedContent.install("search"); });</script>
>
> (I'm using a CDN but maybe we should host jQuery on docs.jboss.org?)
>
> The script is capable to redirect either to the multi page version
> (using the redirects declared in the JSON file: it automatically
> cumulates the redirects from version X to version Y so we don't need
> that much metadata) or to the single page version by leveraging the
> anchors and hashes. For now, I decided to push the user to the single
> page version as it's the one we use for the canonical link but we can
> of course discuss it. Note that I add a ?v=X.X parameter to be sure
> the user is redirected to a fresh version of the corresponding
> /stable/ page and not a cache. I had the issue a couple of times.
>
> Next if you like it:
> - generalize it to all the existing versions of the docs, sed FTW
> - modify the Hibernate XSL stylesheets to include it in the newly generated ones
> - probably modify our website so that the stable release points to the
> /stable/ link to the docs
> - do the same for Validator
>
> @ORM: interested in me pursuing this for ORM too? It will probably be
> a lot more work as the structure of the docs got changed a lot.
>
> Comments, opinions, thoughts welcome.
>
> --
> Guillaume
>
> On Wed, Jul 20, 2016 at 12:06 PM, Davide D'Alto <davide at hibernate.org> wrote:
>> I'll try to apply these changes on Friday.
>>
>> Davide
>>
>> On Tue, Jul 19, 2016 at 11:53 PM, Guillaume Smet
>> <guillaume.smet at gmail.com> wrote:
>>> Hi Sanne,
>>>
>>> Thanks for your feedback. I was pretty sure I hadn't all the history!
>>>
>>> Getting Google to prioritize our latest doc is probably a long time goal.
>>>
>>> I played a bit with jQuery to suggest to the user to go to the latest
>>> stable. Note that I only took into consideration the page for the time
>>> being and didn't consider the anchor but it should be easy to add it
>>> if we think it's worth it (it's a lot more work on the json descriptor
>>> though).
>>>
>>> The following command for each version is all that is needed:
>>> sed -i 's@</body>@<script
>>> src="http://code.jquery.com/jquery-3.1.0.min.js"
>>> integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
>>> crossorigin="anonymous"></script><script
>>> src="/hibernate/search/outdated-version.js"></script></body>@' *.html
>>> (or a find -exec to do it on all the versions at once)
>>>
>>> I attached the global json descriptor and the js file (with a .txt
>>> extension as it didn't pass the mail filter). Both should be added to
>>> /hibernate/search/. Note that I only did the work for version 4.5 in
>>> the json descriptor. The work for other versions would mostly be a
>>> copy/paste.
>>>
>>> I also attached a screenshot of how it looks like. Nothing fancy but
>>> we can do whatever we want.
>>>
>>> Note that I only targeted the multi page HTML output as it was the
>>> most interesting to prototype.
>>>
>>> When we release a new version, we would have to update the descriptor file.
>>>
>>> Comments?
>>>
>>> --
>>> Guillaume

From emmanuel at hibernate.org  Thu Jul 21 08:07:06 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 21 Jul 2016 14:07:06 +0200
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
References: <CALt0+o9hA+aQ1feyLVf=+aB=4NMtJe8E2tGCjDJOae63MRS5AA@mail.gmail.com>
	<CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>
	<CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
Message-ID: <20160721120706.GD75699@hibernate.org>

Nice,

Should we add a X or I got it button to remove this nagging when I have
to read and stay on the old doc?

If that piece of code is in the xsl, how will it work when the doc is in
the distribution?

How screwed are you if we stop using these stylesheet and say embrace
the Asciidoctor default style?

On Thu 2016-07-21 13:33, Guillaume Smet wrote:
> Hi all!
> 
> So here is a status of what I did:
> - I updated the /stable/ link of ogm from 3.0 (cough, cough) to 5.0:
> http://docs.jboss.org/hibernate/stable/ogm/reference/en-US/html/: we
> need to include this in our release process.
> - I updated the /current/ symlink of ORM to point to 5.2 instead of
> 5.1: it needs to be integrated in the release process; (the /stable/
> link uses the /current/ symlink so it's also fixed)
> - I removed the docs for OGM 3.0 as they were a copy of the doc of OGM 4.2
> 
> Next, I applied some magic to 2 old versions of OGM and Search so that
> you can check everything is OK for you before I generalize it:
> - Add meta description and keywords
> - Add a canonical link to the /stable/ single html version
> - Add a piece of Javascript to warn the user and propose to redirect
> him to the best possible place of our last stable release
> documentation
> 
> See the 2 examples here:
> http://docs.jboss.org.local/hibernate/ogm/4.1/reference/en-US/html/ogm-architecture.html
> (scroll to see the hash tracker in action)
> http://docs.jboss.org/hibernate/search/4.2/reference/en-US/html/search-architecture.html
> 
> See the current code and descriptors here:
> https://docs.jboss.org/hibernate/_outdated-content/
> 
> The script and the descriptors work for all existing versions of the
> OGM and Search doc.
> 
> The marker to include in the docs looks like that:
> <script src="//code.jquery.com/jquery-3.1.0.min.js"
> integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
> crossorigin="anonymous"></script>
> <script src="/hibernate/_outdated-content/outdated-content.js"
> type="text/javascript"></script>
> <script type="text/javascript">$(document).ready(function() {
> HibernateDoc.OutdatedContent.install("search"); });</script>
> 
> (I'm using a CDN but maybe we should host jQuery on docs.jboss.org?)
> 
> The script is capable to redirect either to the multi page version
> (using the redirects declared in the JSON file: it automatically
> cumulates the redirects from version X to version Y so we don't need
> that much metadata) or to the single page version by leveraging the
> anchors and hashes. For now, I decided to push the user to the single
> page version as it's the one we use for the canonical link but we can
> of course discuss it. Note that I add a ?v=X.X parameter to be sure
> the user is redirected to a fresh version of the corresponding
> /stable/ page and not a cache. I had the issue a couple of times.
> 
> Next if you like it:
> - generalize it to all the existing versions of the docs, sed FTW
> - modify the Hibernate XSL stylesheets to include it in the newly generated ones
> - probably modify our website so that the stable release points to the
> /stable/ link to the docs
> - do the same for Validator
> 
> @ORM: interested in me pursuing this for ORM too? It will probably be
> a lot more work as the structure of the docs got changed a lot.
> 
> Comments, opinions, thoughts welcome.
> 
> -- 
> Guillaume
> 
> On Wed, Jul 20, 2016 at 12:06 PM, Davide D'Alto <davide at hibernate.org> wrote:
> > I'll try to apply these changes on Friday.
> >
> > Davide
> >
> > On Tue, Jul 19, 2016 at 11:53 PM, Guillaume Smet
> > <guillaume.smet at gmail.com> wrote:
> >> Hi Sanne,
> >>
> >> Thanks for your feedback. I was pretty sure I hadn't all the history!
> >>
> >> Getting Google to prioritize our latest doc is probably a long time goal.
> >>
> >> I played a bit with jQuery to suggest to the user to go to the latest
> >> stable. Note that I only took into consideration the page for the time
> >> being and didn't consider the anchor but it should be easy to add it
> >> if we think it's worth it (it's a lot more work on the json descriptor
> >> though).
> >>
> >> The following command for each version is all that is needed:
> >> sed -i 's@</body>@<script
> >> src="http://code.jquery.com/jquery-3.1.0.min.js"
> >> integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
> >> crossorigin="anonymous"></script><script
> >> src="/hibernate/search/outdated-version.js"></script></body>@' *.html
> >> (or a find -exec to do it on all the versions at once)
> >>
> >> I attached the global json descriptor and the js file (with a .txt
> >> extension as it didn't pass the mail filter). Both should be added to
> >> /hibernate/search/. Note that I only did the work for version 4.5 in
> >> the json descriptor. The work for other versions would mostly be a
> >> copy/paste.
> >>
> >> I also attached a screenshot of how it looks like. Nothing fancy but
> >> we can do whatever we want.
> >>
> >> Note that I only targeted the multi page HTML output as it was the
> >> most interesting to prototype.
> >>
> >> When we release a new version, we would have to update the descriptor file.
> >>
> >> Comments?
> >>
> >> --
> >> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at gmail.com  Thu Jul 21 08:20:56 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 21 Jul 2016 14:20:56 +0200
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <20160721120706.GD75699@hibernate.org>
References: <CALt0+o9hA+aQ1feyLVf=+aB=4NMtJe8E2tGCjDJOae63MRS5AA@mail.gmail.com>
	<CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>
	<CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
	<20160721120706.GD75699@hibernate.org>
Message-ID: <CALt0+o-kHeeK2sb64gx0_WHBQwJjTRy47RJxh=tz8KnUTRodDg@mail.gmail.com>

On Thu, Jul 21, 2016 at 2:07 PM, Emmanuel Bernard
<emmanuel at hibernate.org> wrote:
> Should we add a X or I got it button to remove this nagging when I have
> to read and stay on the old doc?

I thought about it but I don't find it that invasive that we need to
add a close button. But I can do it if people think it's needed. I
suppose we would need a cookie to keep the information during the
navigation on the doc.

> If that piece of code is in the xsl, how will it work when the doc is in
> the distribution?

It won't work. It won't be able to load the Javascript files (the //
doesn't work with file:// protocol, and
/hibernate/_outdated-content/outdated-content.js will not be present).
I can make it work by using absolute URLs for everything but I thought
it was better to not have it in the distribution doc: if you have
downloaded a particular version of the doc, you probably want to read
this version.

> How screwed are you if we stop using these stylesheet and say embrace
> the Asciidoctor default style?

Well, either we can include top and bottom template anyway or we have
to run a sed on the files before uploading them to the doc server.

Maybe we should even do it this way and add the sed calls in our
release process. This way, it won't be in the distribution doc and we
won't have to alter the stylesheets.

Basically, we have to execute this in the reference directory (I
didn't do the work for the Javadoc, would it be useful?):
# Hibernate Search

find . -name \*.html -exec sed -i 's@</body>@<script
src="//code.jquery.com/jquery-3.1.0.min.js"
integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
crossorigin="anonymous"></script><script
src="/hibernate/_outdated-content/outdated-content.js"
type="text/javascript"></script><script
type="text/javascript">$(document).ready(function() {
HibernateDoc.OutdatedContent.install("search"); });</script></body>@'
{} \;

find . -name \*.html -exec sed -i 's@</title><link
rel="stylesheet"@</title><meta name="description" content="Hibernate
Search, full text search for your entities - Reference Documentation"
/><meta name="keywords" content="hibernate, search, hibernate search,
full text, lucene" /><meta name="viewport"
content="width=device-width, initial-scale=1.0" /><link
rel="canonical"
href="https://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/"
/><link rel="stylesheet"@' {} \;

We might even include <!-- HibernateDoc.Outdated Content--> xxxx <!--
/HibernateDoc.OutdatedContent --> markers to be able to update the
code easily in the future. Same for the meta.

-- 
Guillaume

From emmanuel at hibernate.org  Thu Jul 21 08:38:09 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 21 Jul 2016 14:38:09 +0200
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <CALt0+o-kHeeK2sb64gx0_WHBQwJjTRy47RJxh=tz8KnUTRodDg@mail.gmail.com>
References: <CALt0+o9hA+aQ1feyLVf=+aB=4NMtJe8E2tGCjDJOae63MRS5AA@mail.gmail.com>
	<CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>
	<CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
	<20160721120706.GD75699@hibernate.org>
	<CALt0+o-kHeeK2sb64gx0_WHBQwJjTRy47RJxh=tz8KnUTRodDg@mail.gmail.com>
Message-ID: <20160721123809.GE75699@hibernate.org>

On Thu 2016-07-21 14:20, Guillaume Smet wrote:
> On Thu, Jul 21, 2016 at 2:07 PM, Emmanuel Bernard
> <emmanuel at hibernate.org> wrote:
> > Should we add a X or I got it button to remove this nagging when I have
> > to read and stay on the old doc?
> 
> I thought about it but I don't find it that invasive that we need to
> add a close button. But I can do it if people think it's needed. I
> suppose we would need a cookie to keep the information during the
> navigation on the doc.
> 
> > If that piece of code is in the xsl, how will it work when the doc is in
> > the distribution?
> 
> It won't work. It won't be able to load the Javascript files (the //
> doesn't work with file:// protocol, and
> /hibernate/_outdated-content/outdated-content.js will not be present).
> I can make it work by using absolute URLs for everything but I thought
> it was better to not have it in the distribution doc: if you have
> downloaded a particular version of the doc, you probably want to read
> this version.

Right we should not have it.


From emmanuel at hibernate.org  Thu Jul 21 08:39:42 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 21 Jul 2016 14:39:42 +0200
Subject: [hibernate-dev] HSEARCH-1872 Sort API preliminary evaluation
Message-ID: <20160721123942.GF75699@hibernate.org>

Before I go and play with an actual API, can anyone interesting comment
on https://hibernate.atlassian.net/browse/HSEARCH-1872

Both on what we want to support and what we are fine not to support?

Emmanuel

PS: I suppose a total integration within the DSL is a different story that
we will tackle separately.

From guillaume.smet at gmail.com  Thu Jul 21 08:46:02 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 21 Jul 2016 14:46:02 +0200
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <20160721123809.GE75699@hibernate.org>
References: <CALt0+o9hA+aQ1feyLVf=+aB=4NMtJe8E2tGCjDJOae63MRS5AA@mail.gmail.com>
	<CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>
	<CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
	<20160721120706.GD75699@hibernate.org>
	<CALt0+o-kHeeK2sb64gx0_WHBQwJjTRy47RJxh=tz8KnUTRodDg@mail.gmail.com>
	<20160721123809.GE75699@hibernate.org>
Message-ID: <CALt0+o8+-9-9rpRwEPduB_=s6SePGdgDJRHTBJcdsa8wX_Wx5w@mail.gmail.com>

@Davide, @Sanne: would it be an issue to include the sed lines in our
release process to prepare the docs before uploading them to the doc
server?

If it's not, it's probably the best solution. I'll wait for your
confirmation before polishing them.

On Thu, Jul 21, 2016 at 2:38 PM, Emmanuel Bernard
<emmanuel at hibernate.org> wrote:
> On Thu 2016-07-21 14:20, Guillaume Smet wrote:
>> On Thu, Jul 21, 2016 at 2:07 PM, Emmanuel Bernard
>> <emmanuel at hibernate.org> wrote:
>> > Should we add a X or I got it button to remove this nagging when I have
>> > to read and stay on the old doc?
>>
>> I thought about it but I don't find it that invasive that we need to
>> add a close button. But I can do it if people think it's needed. I
>> suppose we would need a cookie to keep the information during the
>> navigation on the doc.
>>
>> > If that piece of code is in the xsl, how will it work when the doc is in
>> > the distribution?
>>
>> It won't work. It won't be able to load the Javascript files (the //
>> doesn't work with file:// protocol, and
>> /hibernate/_outdated-content/outdated-content.js will not be present).
>> I can make it work by using absolute URLs for everything but I thought
>> it was better to not have it in the distribution doc: if you have
>> downloaded a particular version of the doc, you probably want to read
>> this version.
>
> Right we should not have it.
>

From steve at hibernate.org  Thu Jul 21 08:49:01 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 21 Jul 2016 12:49:01 +0000
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <4FC109C0-070E-4D20-9D24-AABEF7B9133C@hibernate.org>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
	<4FC109C0-070E-4D20-9D24-AABEF7B9133C@hibernate.org>
Message-ID: <CAFdSV9ugqgJGqHRnWhNF-nFZMpqHhiC9yyDeH0r08eo3Nm==Vw@mail.gmail.com>

I am working on a larger response to some current challenges, but here is a
quick response to your specific points...

On Wed, Jul 20, 2016 at 12:50 PM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

>
> BasicType does not handle multiple column and compositeType is the
> mebedded case. How would multi-column types would be handled?
>

In terms of what exactly?  Assuming you mean access to the JDBC
descriptors, that is still being determined.  At the moment there is no
single Type-level access to this information.  Each specific Type
sub-interface defines access differently.  I am not a fan of that that
aspect.  The other approach is to define a plural form on Type
(Type#getColumnMappings), and BasicType would just ensure that there is
just one.


Why do you need to ?unscope" the TypeConfiguration? What do you gain from
> it? I?m trying to picture a reuse use case?
>

Functionally we do not gain anything.  I was just trying to be balanced.
We injected the SF into the TypeConfiguration, I wanted to un-inject it as
well for 2 reasons:

   1. release the reference to the SF
   2. prepare the TypeConfiguration for binding to another SF.

The only use case I had in mind was tests where we occasionally build
multiple SF instances from a single Metadata.


Methods of Type needing Session: I used to call them passing null in some
> old code and hoping for the best. Are the reasons for using Session still
> present? Would be nice to get rid of that.
>

This is only ever needed (sometimes) from EntityType.  I guess it depends
which specific method(s) you are asking about.  For some (reading, writing)
yes I think we will continue to need the Session: it is used for access to
JDBC as well as other needed interactions with the Session/PC (scheduling
ids for batch load, etc).  For other methods, maybe not.


On the genericization of Type, it would be extremely nice indeed for OGM,
> but it would require to genericize SqlTypeDescriptor and its methods
> essentially. Not necessarily super trivial.
>

I understand that.  It is not a primary goal for me tbh.  But if we can get
a decent design for the ORM case and can see an easy way to extend this to
OGM without negatively impacting ORM I am all for it.  Given the delegation
to Binder and Extractor I think this will be doable, although I assume we
will need some parameterized param object to make this work.  The paam
object would give us access to "JDBC services" in ORM and something else in
OGM.

From steve at hibernate.org  Thu Jul 21 08:51:50 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 21 Jul 2016 12:51:50 +0000
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
References: <CALt0+o9hA+aQ1feyLVf=+aB=4NMtJe8E2tGCjDJOae63MRS5AA@mail.gmail.com>
	<CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>
	<CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
Message-ID: <CAFdSV9sPQX63Af_sGMhyt_5J_xyn8yJqF5GjRZCxJ3RVTZxihA@mail.gmail.com>

On Thu, Jul 21, 2016 at 6:36 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

>
> @ORM: interested in me pursuing this for ORM too? It will probably be
> a lot more work as the structure of the docs got changed a lot.
>

I would definitely be interested in a solution that finally allows us to
fix this.  If you are willing to take this on, that would be amazing.

From davide at hibernate.org  Thu Jul 21 08:52:14 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Thu, 21 Jul 2016 13:52:14 +0100
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <CALt0+o8+-9-9rpRwEPduB_=s6SePGdgDJRHTBJcdsa8wX_Wx5w@mail.gmail.com>
References: <CALt0+o9hA+aQ1feyLVf=+aB=4NMtJe8E2tGCjDJOae63MRS5AA@mail.gmail.com>
	<CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>
	<CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
	<20160721120706.GD75699@hibernate.org>
	<CALt0+o-kHeeK2sb64gx0_WHBQwJjTRy47RJxh=tz8KnUTRodDg@mail.gmail.com>
	<20160721123809.GE75699@hibernate.org>
	<CALt0+o8+-9-9rpRwEPduB_=s6SePGdgDJRHTBJcdsa8wX_Wx5w@mail.gmail.com>
Message-ID: <CANoTJYMbkJa_0GZoZEmwsp5AQEq-vnTu_yKV8LgrbMrQzYzU4g@mail.gmail.com>

It should be easy for OGM, you need to update this file:
https://github.com/hibernate/hibernate-ogm/blob/master/src/main/release-scripts/upload-documentation.sh

On Thu, Jul 21, 2016 at 1:46 PM, Guillaume Smet
<guillaume.smet at gmail.com> wrote:
> @Davide, @Sanne: would it be an issue to include the sed lines in our
> release process to prepare the docs before uploading them to the doc
> server?
>
> If it's not, it's probably the best solution. I'll wait for your
> confirmation before polishing them.
>
> On Thu, Jul 21, 2016 at 2:38 PM, Emmanuel Bernard
> <emmanuel at hibernate.org> wrote:
>> On Thu 2016-07-21 14:20, Guillaume Smet wrote:
>>> On Thu, Jul 21, 2016 at 2:07 PM, Emmanuel Bernard
>>> <emmanuel at hibernate.org> wrote:
>>> > Should we add a X or I got it button to remove this nagging when I have
>>> > to read and stay on the old doc?
>>>
>>> I thought about it but I don't find it that invasive that we need to
>>> add a close button. But I can do it if people think it's needed. I
>>> suppose we would need a cookie to keep the information during the
>>> navigation on the doc.
>>>
>>> > If that piece of code is in the xsl, how will it work when the doc is in
>>> > the distribution?
>>>
>>> It won't work. It won't be able to load the Javascript files (the //
>>> doesn't work with file:// protocol, and
>>> /hibernate/_outdated-content/outdated-content.js will not be present).
>>> I can make it work by using absolute URLs for everything but I thought
>>> it was better to not have it in the distribution doc: if you have
>>> downloaded a particular version of the doc, you probably want to read
>>> this version.
>>
>> Right we should not have it.
>>

From sanne at hibernate.org  Thu Jul 21 09:06:13 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 21 Jul 2016 14:06:13 +0100
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <CANoTJYMbkJa_0GZoZEmwsp5AQEq-vnTu_yKV8LgrbMrQzYzU4g@mail.gmail.com>
References: <CALt0+o9hA+aQ1feyLVf=+aB=4NMtJe8E2tGCjDJOae63MRS5AA@mail.gmail.com>
	<CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>
	<CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
	<20160721120706.GD75699@hibernate.org>
	<CALt0+o-kHeeK2sb64gx0_WHBQwJjTRy47RJxh=tz8KnUTRodDg@mail.gmail.com>
	<20160721123809.GE75699@hibernate.org>
	<CALt0+o8+-9-9rpRwEPduB_=s6SePGdgDJRHTBJcdsa8wX_Wx5w@mail.gmail.com>
	<CANoTJYMbkJa_0GZoZEmwsp5AQEq-vnTu_yKV8LgrbMrQzYzU4g@mail.gmail.com>
Message-ID: <CAFm4XO3_wC2TDwX6rqC4+yQmKS-VcWjg0e_ad=z52z3JbsYfyQ@mail.gmail.com>

On 21 July 2016 at 13:52, Davide D'Alto <davide at hibernate.org> wrote:
> It should be easy for OGM, you need to update this file:
> https://github.com/hibernate/hibernate-ogm/blob/master/src/main/release-scripts/upload-documentation.sh

+1, no problems for Search either. It's not scripted yet, so I'll just
need clear instructions on the release wiki:
 - https://developer.jboss.org/wiki/ReleasingHibernateSearch

How should we update the metadata file at e.g.
http://docs.jboss.org/hibernate/_outdated-content/search.json ?

Maybe we could move that to the website, as similar metadata is
already being deployed, e.g.
 - https://github.com/hibernate/hibernate.org/tree/staging/_data/projects/search/releases

Ideally the website building scripts could take the yaml file and
publish an updated search.json when updating hibernate.org ?

Looks great, thanks!

From emmanuel at hibernate.org  Thu Jul 21 12:24:50 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 21 Jul 2016 18:24:50 +0200
Subject: [hibernate-dev] HSEARCH-1872 Sort API preliminary evaluation
In-Reply-To: <20160721123942.GF75699@hibernate.org>
References: <20160721123942.GF75699@hibernate.org>
Message-ID: <20160721162450.GG75699@hibernate.org>

I came up with something quite natural to our DSL. WDYT?

https://hibernate.atlassian.net/browse/HSEARCH-1872?focusedCommentId=81543&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-81543

On Thu 2016-07-21 14:39, Emmanuel Bernard wrote:
> Before I go and play with an actual API, can anyone interesting comment
> on https://hibernate.atlassian.net/browse/HSEARCH-1872
> 
> Both on what we want to support and what we are fine not to support?
> 
> Emmanuel
> 
> PS: I suppose a total integration within the DSL is a different story that
> we will tackle separately.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Jul 21 15:27:49 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 21 Jul 2016 19:27:49 +0000
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <CAFdSV9ugqgJGqHRnWhNF-nFZMpqHhiC9yyDeH0r08eo3Nm==Vw@mail.gmail.com>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
	<4FC109C0-070E-4D20-9D24-AABEF7B9133C@hibernate.org>
	<CAFdSV9ugqgJGqHRnWhNF-nFZMpqHhiC9yyDeH0r08eo3Nm==Vw@mail.gmail.com>
Message-ID: <CAFdSV9uPWkehRv8raXqMYgkodAg_9K57ZMkNe2tuecJaTXFn4w@mail.gmail.com>

One goal of the redesign is to build more friendly, easy-to-follow contract
for access to this metadata at runtime (legacy persister state).  Rather
than accessing pieces of information pertaining to attributes across many,
many arrays I wanted an array of a composite representation of these
attributes.  JPA defines it this way, so on some level you'd think it would
be pretty straightforward to move this direction.  The major pain-point I
have been facing is that JPA does not define "mapping information" at all
in its Metamodel/Types.  The main place this comes to a head is
EmbeddableType, especially given access to it directly on Metamodel *by
class*.  In JPA terms that return has to model the Embeddable (no mapping
info) rather than the Embedded.  And then further when we
expose EmbeddableType's attributes we have the same problem continued
because the context/root is the embeddable rather than the embedded.
Hopefully this makes sense, but as an example consider (using a "component
safe NamingStrategy):

@Entity
class Store {
    ...
    @Embedded
    Address headquartersAddress;
    @Embedded
    Address locationAddress;
}

@Embeddable
class Address {
    String streetAddress;
    @Embedded
    PostalCode postalCode;
    ...
}

@Embeddable
class PostalCode {
    String zip;
    String plus4;
    @ManyToOne
    City city;
}

Then consider that JPA frames access to this information as:

EmbeddableType<Address> addrType = metamodel.embeddable( Address.class );

Because it is generic to the Address embeddable, we have no access to the
specific embedded mapping info.  And if we follow this access down further,
it also means the same for accessing the attributes of that
EmbeddableType<Address>.
For example, accessing the "postalCode.zip" from the EmbeddableType<Address>
we'd have no ability to resolve whether that maps to
"headquartersAddress_postalCode_zip"
or "locationAddress_postalCode_zip".  And of course, as an ORM we need
access to that mapping information :)

Essentially that is the crux of the difficulty I have at the moment.

I know we could get around this by splitting (or keeping split) the notions
of ORM Type and JPA Type, but I would like to avoid that : this unification
is going to be important to the SQM Criteria support.

So the question becomes how to best handle exposing an "Attribute" with
mapping information as well as an "Attribute" without mapping information.

I will be working on some proposals for ways to do this over the next week
or so.  And maybe y'all see a solution easier than I do (I fear I may not
be seeing the forest through the trees atm).


On Thu, Jul 21, 2016 at 7:49 AM Steve Ebersole <steve at hibernate.org> wrote:

> I am working on a larger response to some current challenges, but here is
> a quick response to your specific points...
>
> On Wed, Jul 20, 2016 at 12:50 PM Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>
>>
>> BasicType does not handle multiple column and compositeType is the
>> mebedded case. How would multi-column types would be handled?
>>
>
> In terms of what exactly?  Assuming you mean access to the JDBC
> descriptors, that is still being determined.  At the moment there is no
> single Type-level access to this information.  Each specific Type
> sub-interface defines access differently.  I am not a fan of that that
> aspect.  The other approach is to define a plural form on Type
> (Type#getColumnMappings), and BasicType would just ensure that there is
> just one.
>
>
> Why do you need to ?unscope" the TypeConfiguration? What do you gain from
>> it? I?m trying to picture a reuse use case?
>>
>
> Functionally we do not gain anything.  I was just trying to be balanced.
> We injected the SF into the TypeConfiguration, I wanted to un-inject it as
> well for 2 reasons:
>
>    1. release the reference to the SF
>    2. prepare the TypeConfiguration for binding to another SF.
>
> The only use case I had in mind was tests where we occasionally build
> multiple SF instances from a single Metadata.
>
>
> Methods of Type needing Session: I used to call them passing null in some
>> old code and hoping for the best. Are the reasons for using Session still
>> present? Would be nice to get rid of that.
>>
>
> This is only ever needed (sometimes) from EntityType.  I guess it depends
> which specific method(s) you are asking about.  For some (reading, writing)
> yes I think we will continue to need the Session: it is used for access to
> JDBC as well as other needed interactions with the Session/PC (scheduling
> ids for batch load, etc).  For other methods, maybe not.
>
>
> On the genericization of Type, it would be extremely nice indeed for OGM,
>> but it would require to genericize SqlTypeDescriptor and its methods
>> essentially. Not necessarily super trivial.
>>
>
> I understand that.  It is not a primary goal for me tbh.  But if we can
> get a decent design for the ORM case and can see an easy way to extend this
> to OGM without negatively impacting ORM I am all for it.  Given the
> delegation to Binder and Extractor I think this will be doable, although I
> assume we will need some parameterized param object to make this work.  The
> paam object would give us access to "JDBC services" in ORM and something
> else in OGM.
>
>
>

From steve at hibernate.org  Thu Jul 21 17:10:08 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 21 Jul 2016 21:10:08 +0000
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <CAFdSV9uPWkehRv8raXqMYgkodAg_9K57ZMkNe2tuecJaTXFn4w@mail.gmail.com>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
	<4FC109C0-070E-4D20-9D24-AABEF7B9133C@hibernate.org>
	<CAFdSV9ugqgJGqHRnWhNF-nFZMpqHhiC9yyDeH0r08eo3Nm==Vw@mail.gmail.com>
	<CAFdSV9uPWkehRv8raXqMYgkodAg_9K57ZMkNe2tuecJaTXFn4w@mail.gmail.com>
Message-ID: <CAFdSV9ujif8+KKMBpVQDZm9aG05v_an3jHLYtE3OLDkt9wa=2A@mail.gmail.com>

Put another way, I think the problem (and probably the solution) here is
similar to JPA's Bindable (and Path) concept.

On Thu, Jul 21, 2016 at 2:27 PM Steve Ebersole <steve at hibernate.org> wrote:

> One goal of the redesign is to build more friendly, easy-to-follow
> contract for access to this metadata at runtime (legacy persister state).
> Rather than accessing pieces of information pertaining to attributes across
> many, many arrays I wanted an array of a composite representation of these
> attributes.  JPA defines it this way, so on some level you'd think it would
> be pretty straightforward to move this direction.  The major pain-point I
> have been facing is that JPA does not define "mapping information" at all
> in its Metamodel/Types.  The main place this comes to a head is
> EmbeddableType, especially given access to it directly on Metamodel *by
> class*.  In JPA terms that return has to model the Embeddable (no mapping
> info) rather than the Embedded.  And then further when we
> expose EmbeddableType's attributes we have the same problem continued
> because the context/root is the embeddable rather than the embedded.
> Hopefully this makes sense, but as an example consider (using a "component
> safe NamingStrategy):
>
> @Entity
> class Store {
>     ...
>     @Embedded
>     Address headquartersAddress;
>     @Embedded
>     Address locationAddress;
> }
>
> @Embeddable
> class Address {
>     String streetAddress;
>     @Embedded
>     PostalCode postalCode;
>     ...
> }
>
> @Embeddable
> class PostalCode {
>     String zip;
>     String plus4;
>     @ManyToOne
>     City city;
> }
>
> Then consider that JPA frames access to this information as:
>
> EmbeddableType<Address> addrType = metamodel.embeddable( Address.class );
>
> Because it is generic to the Address embeddable, we have no access to the
> specific embedded mapping info.  And if we follow this access down further,
> it also means the same for accessing the attributes of that EmbeddableType<Address>.
> For example, accessing the "postalCode.zip" from the EmbeddableType<Address>
> we'd have no ability to resolve whether that maps to "headquartersAddress_postalCode_zip"
> or "locationAddress_postalCode_zip".  And of course, as an ORM we need
> access to that mapping information :)
>
> Essentially that is the crux of the difficulty I have at the moment.
>
> I know we could get around this by splitting (or keeping split) the
> notions of ORM Type and JPA Type, but I would like to avoid that : this
> unification is going to be important to the SQM Criteria support.
>
> So the question becomes how to best handle exposing an "Attribute" with
> mapping information as well as an "Attribute" without mapping information.
>
> I will be working on some proposals for ways to do this over the next week
> or so.  And maybe y'all see a solution easier than I do (I fear I may not
> be seeing the forest through the trees atm).
>
>
> On Thu, Jul 21, 2016 at 7:49 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I am working on a larger response to some current challenges, but here is
>> a quick response to your specific points...
>>
>> On Wed, Jul 20, 2016 at 12:50 PM Emmanuel Bernard <emmanuel at hibernate.org>
>> wrote:
>>
>>>
>>> BasicType does not handle multiple column and compositeType is the
>>> mebedded case. How would multi-column types would be handled?
>>>
>>
>> In terms of what exactly?  Assuming you mean access to the JDBC
>> descriptors, that is still being determined.  At the moment there is no
>> single Type-level access to this information.  Each specific Type
>> sub-interface defines access differently.  I am not a fan of that that
>> aspect.  The other approach is to define a plural form on Type
>> (Type#getColumnMappings), and BasicType would just ensure that there is
>> just one.
>>
>>
>> Why do you need to ?unscope" the TypeConfiguration? What do you gain from
>>> it? I?m trying to picture a reuse use case?
>>>
>>
>> Functionally we do not gain anything.  I was just trying to be balanced.
>> We injected the SF into the TypeConfiguration, I wanted to un-inject it as
>> well for 2 reasons:
>>
>>    1. release the reference to the SF
>>    2. prepare the TypeConfiguration for binding to another SF.
>>
>> The only use case I had in mind was tests where we occasionally build
>> multiple SF instances from a single Metadata.
>>
>>
>> Methods of Type needing Session: I used to call them passing null in some
>>> old code and hoping for the best. Are the reasons for using Session still
>>> present? Would be nice to get rid of that.
>>>
>>
>> This is only ever needed (sometimes) from EntityType.  I guess it depends
>> which specific method(s) you are asking about.  For some (reading, writing)
>> yes I think we will continue to need the Session: it is used for access to
>> JDBC as well as other needed interactions with the Session/PC (scheduling
>> ids for batch load, etc).  For other methods, maybe not.
>>
>>
>> On the genericization of Type, it would be extremely nice indeed for OGM,
>>> but it would require to genericize SqlTypeDescriptor and its methods
>>> essentially. Not necessarily super trivial.
>>>
>>
>> I understand that.  It is not a primary goal for me tbh.  But if we can
>> get a decent design for the ORM case and can see an easy way to extend this
>> to OGM without negatively impacting ORM I am all for it.  Given the
>> delegation to Binder and Extractor I think this will be doable, although I
>> assume we will need some parameterized param object to make this work.  The
>> paam object would give us access to "JDBC services" in ORM and something
>> else in OGM.
>>
>>
>>

From guillaume.smet at gmail.com  Thu Jul 21 18:26:05 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 22 Jul 2016 00:26:05 +0200
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <CAFm4XO3_wC2TDwX6rqC4+yQmKS-VcWjg0e_ad=z52z3JbsYfyQ@mail.gmail.com>
References: <CALt0+o9hA+aQ1feyLVf=+aB=4NMtJe8E2tGCjDJOae63MRS5AA@mail.gmail.com>
	<CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>
	<CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
	<20160721120706.GD75699@hibernate.org>
	<CALt0+o-kHeeK2sb64gx0_WHBQwJjTRy47RJxh=tz8KnUTRodDg@mail.gmail.com>
	<20160721123809.GE75699@hibernate.org>
	<CALt0+o8+-9-9rpRwEPduB_=s6SePGdgDJRHTBJcdsa8wX_Wx5w@mail.gmail.com>
	<CANoTJYMbkJa_0GZoZEmwsp5AQEq-vnTu_yKV8LgrbMrQzYzU4g@mail.gmail.com>
	<CAFm4XO3_wC2TDwX6rqC4+yQmKS-VcWjg0e_ad=z52z3JbsYfyQ@mail.gmail.com>
Message-ID: <CALt0+o-xq0at6C7pTeNnyQLTycjmE+v5Z5a4XQxDx8dC0pd8MQ@mail.gmail.com>

On Thu, Jul 21, 2016 at 3:06 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> Maybe we could move that to the website, as similar metadata is
> already being deployed, e.g.
>  - https://github.com/hibernate/hibernate.org/tree/staging/_data/projects/search/releases

We already need to update the /stable/ symlink on the doc server so we
might as well do it when we push the doc.

I got something like this:
https://gist.github.com/gsmet/8c8e29c46337f69bfbc9e84f108d951f . I'll
push a PR tomorrow.

I pushed the JS and the metadata to all known doc versions of Search and OGM.

-- 
Guillaume

From emmanuel at hibernate.org  Fri Jul 22 05:14:45 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 22 Jul 2016 11:14:45 +0200
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <CAFdSV9ujif8+KKMBpVQDZm9aG05v_an3jHLYtE3OLDkt9wa=2A@mail.gmail.com>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
	<4FC109C0-070E-4D20-9D24-AABEF7B9133C@hibernate.org>
	<CAFdSV9ugqgJGqHRnWhNF-nFZMpqHhiC9yyDeH0r08eo3Nm==Vw@mail.gmail.com>
	<CAFdSV9uPWkehRv8raXqMYgkodAg_9K57ZMkNe2tuecJaTXFn4w@mail.gmail.com>
	<CAFdSV9ujif8+KKMBpVQDZm9aG05v_an3jHLYtE3OLDkt9wa=2A@mail.gmail.com>
Message-ID: <20160722091445.GD11493@hibernate.org>

The good news is that I am following you :D

I think one of the option is some API to which you can pass the (JPA)
Type, a Path from root and it would return a structure qualifying the
embedded info and not just the embeddable.

I'm making things up here

//might not even need the type, could be guessed from the Path?
AttributeMapping am = mappingProvider.forPath(path);

What's nasty is that it then requires two parallel APIs, or rather it
would not flow from an enhanced JPA type API.

An alternative would be what I think you propose with the BindableType,
that is an extension point that describes the specifics of the
specialization when navigating from one node type to another. I think.

An alternative that I can think of is as follows. I'm assuming that the
data that needs to be contextualized by the path is mapping in nature or
at least not at all represented in the JPA types.
Each (JPA) type instance would be inherently specific to the path it
comes from. It would keep exposing the JPA non contextualized info but
also add contextualized info.

HibernateEntityType<Foo> fooModel =
  (HibernateEntityType<Foo>) entityManagerFactory.getMetamodel().entity(Foo.class); // considered a root for navigation

for (HibernateSingularAttribute sa : fooModel.getSingularAttributes()) {
   if (sa.getPersistentAttributeType() == EMBEDDED) {
       HibernateEmbeddableType et = (HibernateEmbeddableType) sa.getType();
       for (HibernateSingularAttribute esa : fooModel.getSingularAttributes()) {
           if (esa.getPersistentAttributeType() == BASIC) {
               int span = esa.getPhysicalInfo().getColumnSpan();
           }
      }
    }
}

Hopefully, JPA does not mandate == between different types.

A question I have is how navigable and easy such API would be for a
persister. But that's something to explore.

Emmanuel

On Thu 2016-07-21 21:10, Steve Ebersole wrote:
> Put another way, I think the problem (and probably the solution) here is
> similar to JPA's Bindable (and Path) concept.
> 
> On Thu, Jul 21, 2016 at 2:27 PM Steve Ebersole <steve at hibernate.org> wrote:
> 
> > One goal of the redesign is to build more friendly, easy-to-follow
> > contract for access to this metadata at runtime (legacy persister state).
> > Rather than accessing pieces of information pertaining to attributes across
> > many, many arrays I wanted an array of a composite representation of these
> > attributes.  JPA defines it this way, so on some level you'd think it would
> > be pretty straightforward to move this direction.  The major pain-point I
> > have been facing is that JPA does not define "mapping information" at all
> > in its Metamodel/Types.  The main place this comes to a head is
> > EmbeddableType, especially given access to it directly on Metamodel *by
> > class*.  In JPA terms that return has to model the Embeddable (no mapping
> > info) rather than the Embedded.  And then further when we
> > expose EmbeddableType's attributes we have the same problem continued
> > because the context/root is the embeddable rather than the embedded.
> > Hopefully this makes sense, but as an example consider (using a "component
> > safe NamingStrategy):
> >
> > @Entity
> > class Store {
> >     ...
> >     @Embedded
> >     Address headquartersAddress;
> >     @Embedded
> >     Address locationAddress;
> > }
> >
> > @Embeddable
> > class Address {
> >     String streetAddress;
> >     @Embedded
> >     PostalCode postalCode;
> >     ...
> > }
> >
> > @Embeddable
> > class PostalCode {
> >     String zip;
> >     String plus4;
> >     @ManyToOne
> >     City city;
> > }
> >
> > Then consider that JPA frames access to this information as:
> >
> > EmbeddableType<Address> addrType = metamodel.embeddable( Address.class );
> >
> > Because it is generic to the Address embeddable, we have no access to the
> > specific embedded mapping info.  And if we follow this access down further,
> > it also means the same for accessing the attributes of that EmbeddableType<Address>.
> > For example, accessing the "postalCode.zip" from the EmbeddableType<Address>
> > we'd have no ability to resolve whether that maps to "headquartersAddress_postalCode_zip"
> > or "locationAddress_postalCode_zip".  And of course, as an ORM we need
> > access to that mapping information :)
> >
> > Essentially that is the crux of the difficulty I have at the moment.
> >
> > I know we could get around this by splitting (or keeping split) the
> > notions of ORM Type and JPA Type, but I would like to avoid that : this
> > unification is going to be important to the SQM Criteria support.
> >
> > So the question becomes how to best handle exposing an "Attribute" with
> > mapping information as well as an "Attribute" without mapping information.
> >
> > I will be working on some proposals for ways to do this over the next week
> > or so.  And maybe y'all see a solution easier than I do (I fear I may not
> > be seeing the forest through the trees atm).
> >
> >
> > On Thu, Jul 21, 2016 at 7:49 AM Steve Ebersole <steve at hibernate.org>
> > wrote:
> >
> >> I am working on a larger response to some current challenges, but here is
> >> a quick response to your specific points...
> >>
> >> On Wed, Jul 20, 2016 at 12:50 PM Emmanuel Bernard <emmanuel at hibernate.org>
> >> wrote:
> >>
> >>>
> >>> BasicType does not handle multiple column and compositeType is the
> >>> mebedded case. How would multi-column types would be handled?
> >>>
> >>
> >> In terms of what exactly?  Assuming you mean access to the JDBC
> >> descriptors, that is still being determined.  At the moment there is no
> >> single Type-level access to this information.  Each specific Type
> >> sub-interface defines access differently.  I am not a fan of that that
> >> aspect.  The other approach is to define a plural form on Type
> >> (Type#getColumnMappings), and BasicType would just ensure that there is
> >> just one.
> >>
> >>
> >> Why do you need to ?unscope" the TypeConfiguration? What do you gain from
> >>> it? I?m trying to picture a reuse use case?
> >>>
> >>
> >> Functionally we do not gain anything.  I was just trying to be balanced.
> >> We injected the SF into the TypeConfiguration, I wanted to un-inject it as
> >> well for 2 reasons:
> >>
> >>    1. release the reference to the SF
> >>    2. prepare the TypeConfiguration for binding to another SF.
> >>
> >> The only use case I had in mind was tests where we occasionally build
> >> multiple SF instances from a single Metadata.
> >>
> >>
> >> Methods of Type needing Session: I used to call them passing null in some
> >>> old code and hoping for the best. Are the reasons for using Session still
> >>> present? Would be nice to get rid of that.
> >>>
> >>
> >> This is only ever needed (sometimes) from EntityType.  I guess it depends
> >> which specific method(s) you are asking about.  For some (reading, writing)
> >> yes I think we will continue to need the Session: it is used for access to
> >> JDBC as well as other needed interactions with the Session/PC (scheduling
> >> ids for batch load, etc).  For other methods, maybe not.
> >>
> >>
> >> On the genericization of Type, it would be extremely nice indeed for OGM,
> >>> but it would require to genericize SqlTypeDescriptor and its methods
> >>> essentially. Not necessarily super trivial.
> >>>
> >>
> >> I understand that.  It is not a primary goal for me tbh.  But if we can
> >> get a decent design for the ORM case and can see an easy way to extend this
> >> to OGM without negatively impacting ORM I am all for it.  Given the
> >> delegation to Binder and Extractor I think this will be doable, although I
> >> assume we will need some parameterized param object to make this work.  The
> >> paam object would give us access to "JDBC services" in ORM and something
> >> else in OGM.
> >>
> >>
> >>

From emmanuel at hibernate.org  Fri Jul 22 06:20:58 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 22 Jul 2016 12:20:58 +0200
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <20160722091445.GD11493@hibernate.org>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
	<4FC109C0-070E-4D20-9D24-AABEF7B9133C@hibernate.org>
	<CAFdSV9ugqgJGqHRnWhNF-nFZMpqHhiC9yyDeH0r08eo3Nm==Vw@mail.gmail.com>
	<CAFdSV9uPWkehRv8raXqMYgkodAg_9K57ZMkNe2tuecJaTXFn4w@mail.gmail.com>
	<CAFdSV9ujif8+KKMBpVQDZm9aG05v_an3jHLYtE3OLDkt9wa=2A@mail.gmail.com>
	<20160722091445.GD11493@hibernate.org>
Message-ID: <E2844939-C2E5-47EB-A031-AE29603D1FBD@hibernate.org>

The contextualization would only work when user calls metamodel.entity(). Not the other methods

> On 22 juil. 2016, at 11:14, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
> The good news is that I am following you :D
> 
> I think one of the option is some API to which you can pass the (JPA)
> Type, a Path from root and it would return a structure qualifying the
> embedded info and not just the embeddable.
> 
> I'm making things up here
> 
> //might not even need the type, could be guessed from the Path?
> AttributeMapping am = mappingProvider.forPath(path);
> 
> What's nasty is that it then requires two parallel APIs, or rather it
> would not flow from an enhanced JPA type API.
> 
> An alternative would be what I think you propose with the BindableType,
> that is an extension point that describes the specifics of the
> specialization when navigating from one node type to another. I think.
> 
> An alternative that I can think of is as follows. I'm assuming that the
> data that needs to be contextualized by the path is mapping in nature or
> at least not at all represented in the JPA types.
> Each (JPA) type instance would be inherently specific to the path it
> comes from. It would keep exposing the JPA non contextualized info but
> also add contextualized info.
> 
> HibernateEntityType<Foo> fooModel =
>  (HibernateEntityType<Foo>) entityManagerFactory.getMetamodel().entity(Foo.class); // considered a root for navigation
> 
> for (HibernateSingularAttribute sa : fooModel.getSingularAttributes()) {
>   if (sa.getPersistentAttributeType() == EMBEDDED) {
>       HibernateEmbeddableType et = (HibernateEmbeddableType) sa.getType();
>       for (HibernateSingularAttribute esa : fooModel.getSingularAttributes()) {
>           if (esa.getPersistentAttributeType() == BASIC) {
>               int span = esa.getPhysicalInfo().getColumnSpan();
>           }
>      }
>    }
> }
> 
> Hopefully, JPA does not mandate == between different types.
> 
> A question I have is how navigable and easy such API would be for a
> persister. But that's something to explore.
> 
> Emmanuel
> 
>> On Thu 2016-07-21 21:10, Steve Ebersole wrote:
>> Put another way, I think the problem (and probably the solution) here is
>> similar to JPA's Bindable (and Path) concept.
>> 
>>> On Thu, Jul 21, 2016 at 2:27 PM Steve Ebersole <steve at hibernate.org> wrote:
>>> 
>>> One goal of the redesign is to build more friendly, easy-to-follow
>>> contract for access to this metadata at runtime (legacy persister state).
>>> Rather than accessing pieces of information pertaining to attributes across
>>> many, many arrays I wanted an array of a composite representation of these
>>> attributes.  JPA defines it this way, so on some level you'd think it would
>>> be pretty straightforward to move this direction.  The major pain-point I
>>> have been facing is that JPA does not define "mapping information" at all
>>> in its Metamodel/Types.  The main place this comes to a head is
>>> EmbeddableType, especially given access to it directly on Metamodel *by
>>> class*.  In JPA terms that return has to model the Embeddable (no mapping
>>> info) rather than the Embedded.  And then further when we
>>> expose EmbeddableType's attributes we have the same problem continued
>>> because the context/root is the embeddable rather than the embedded.
>>> Hopefully this makes sense, but as an example consider (using a "component
>>> safe NamingStrategy):
>>> 
>>> @Entity
>>> class Store {
>>>    ...
>>>    @Embedded
>>>    Address headquartersAddress;
>>>    @Embedded
>>>    Address locationAddress;
>>> }
>>> 
>>> @Embeddable
>>> class Address {
>>>    String streetAddress;
>>>    @Embedded
>>>    PostalCode postalCode;
>>>    ...
>>> }
>>> 
>>> @Embeddable
>>> class PostalCode {
>>>    String zip;
>>>    String plus4;
>>>    @ManyToOne
>>>    City city;
>>> }
>>> 
>>> Then consider that JPA frames access to this information as:
>>> 
>>> EmbeddableType<Address> addrType = metamodel.embeddable( Address.class );
>>> 
>>> Because it is generic to the Address embeddable, we have no access to the
>>> specific embedded mapping info.  And if we follow this access down further,
>>> it also means the same for accessing the attributes of that EmbeddableType<Address>.
>>> For example, accessing the "postalCode.zip" from the EmbeddableType<Address>
>>> we'd have no ability to resolve whether that maps to "headquartersAddress_postalCode_zip"
>>> or "locationAddress_postalCode_zip".  And of course, as an ORM we need
>>> access to that mapping information :)
>>> 
>>> Essentially that is the crux of the difficulty I have at the moment.
>>> 
>>> I know we could get around this by splitting (or keeping split) the
>>> notions of ORM Type and JPA Type, but I would like to avoid that : this
>>> unification is going to be important to the SQM Criteria support.
>>> 
>>> So the question becomes how to best handle exposing an "Attribute" with
>>> mapping information as well as an "Attribute" without mapping information.
>>> 
>>> I will be working on some proposals for ways to do this over the next week
>>> or so.  And maybe y'all see a solution easier than I do (I fear I may not
>>> be seeing the forest through the trees atm).
>>> 
>>> 
>>> On Thu, Jul 21, 2016 at 7:49 AM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>> 
>>>> I am working on a larger response to some current challenges, but here is
>>>> a quick response to your specific points...
>>>> 
>>>> On Wed, Jul 20, 2016 at 12:50 PM Emmanuel Bernard <emmanuel at hibernate.org>
>>>> wrote:
>>>> 
>>>>> 
>>>>> BasicType does not handle multiple column and compositeType is the
>>>>> mebedded case. How would multi-column types would be handled?
>>>> 
>>>> In terms of what exactly?  Assuming you mean access to the JDBC
>>>> descriptors, that is still being determined.  At the moment there is no
>>>> single Type-level access to this information.  Each specific Type
>>>> sub-interface defines access differently.  I am not a fan of that that
>>>> aspect.  The other approach is to define a plural form on Type
>>>> (Type#getColumnMappings), and BasicType would just ensure that there is
>>>> just one.
>>>> 
>>>> 
>>>> Why do you need to ?unscope" the TypeConfiguration? What do you gain from
>>>>> it? I?m trying to picture a reuse use case?
>>>> 
>>>> Functionally we do not gain anything.  I was just trying to be balanced.
>>>> We injected the SF into the TypeConfiguration, I wanted to un-inject it as
>>>> well for 2 reasons:
>>>> 
>>>>   1. release the reference to the SF
>>>>   2. prepare the TypeConfiguration for binding to another SF.
>>>> 
>>>> The only use case I had in mind was tests where we occasionally build
>>>> multiple SF instances from a single Metadata.
>>>> 
>>>> 
>>>> Methods of Type needing Session: I used to call them passing null in some
>>>>> old code and hoping for the best. Are the reasons for using Session still
>>>>> present? Would be nice to get rid of that.
>>>> 
>>>> This is only ever needed (sometimes) from EntityType.  I guess it depends
>>>> which specific method(s) you are asking about.  For some (reading, writing)
>>>> yes I think we will continue to need the Session: it is used for access to
>>>> JDBC as well as other needed interactions with the Session/PC (scheduling
>>>> ids for batch load, etc).  For other methods, maybe not.
>>>> 
>>>> 
>>>> On the genericization of Type, it would be extremely nice indeed for OGM,
>>>>> but it would require to genericize SqlTypeDescriptor and its methods
>>>>> essentially. Not necessarily super trivial.
>>>> 
>>>> I understand that.  It is not a primary goal for me tbh.  But if we can
>>>> get a decent design for the ORM case and can see an easy way to extend this
>>>> to OGM without negatively impacting ORM I am all for it.  Given the
>>>> delegation to Binder and Extractor I think this will be doable, although I
>>>> assume we will need some parameterized param object to make this work.  The
>>>> paam object would give us access to "JDBC services" in ORM and something
>>>> else in OGM.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From coladict at gmail.com  Fri Jul 22 08:56:50 2016
From: coladict at gmail.com (Jordan Gigov)
Date: Fri, 22 Jul 2016 15:56:50 +0300
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
Message-ID: <CA+nBocA2pUQuQohnXMSfmL1SpS7EsRS9HpjkJhu_icwC=R98Lg@mail.gmail.com>

While this topic is hot and the type handlers will not be
backwards-compatible, I think they should have some access to the
connection-specific Dialect. I have started (but largely paused) an
implementation of Array datatypes, but it's highly dependent on instance
type-checking of WrapperOptions ugly hackyness. It also needs to call
`java.sql.Connection.createArrayOf` on that same connection. Those two
interfaces should somehow be exposed to the type handlers at some point.
Also I haven't figured out yet how to use them as arrays of entity keys.
Storing an array of entities by their Id keys would be a nice bonus.

From steve at hibernate.org  Fri Jul 22 09:22:25 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 22 Jul 2016 13:22:25 +0000
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <CA+nBocA2pUQuQohnXMSfmL1SpS7EsRS9HpjkJhu_icwC=R98Lg@mail.gmail.com>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
	<CA+nBocA2pUQuQohnXMSfmL1SpS7EsRS9HpjkJhu_icwC=R98Lg@mail.gmail.com>
Message-ID: <CAFdSV9tzQARSrbYDD4WXLdr0=VggHALk7O-+A8+J2TBpAzMg1g@mail.gmail.com>

Vlad and I already spoke about some form of native (or at least more easily
user defined) support for SQL ARRAY types.  However, I do not know that
that will extend to ARRAYs of entities.

That said... all the methods to read a value on Type will be passed a
Session.  I think that was a mistake in the first iteration of Type to not
always pass it.  From Session you would have access to everything you ask
about.

On Fri, Jul 22, 2016 at 7:59 AM Jordan Gigov <coladict at gmail.com> wrote:

> While this topic is hot and the type handlers will not be
> backwards-compatible, I think they should have some access to the
> connection-specific Dialect. I have started (but largely paused) an
> implementation of Array datatypes, but it's highly dependent on instance
> type-checking of WrapperOptions ugly hackyness. It also needs to call
> `java.sql.Connection.createArrayOf` on that same connection. Those two
> interfaces should somehow be exposed to the type handlers at some point.
> Also I haven't figured out yet how to use them as arrays of entity keys.
> Storing an array of entities by their Id keys would be a nice bonus.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Jul 22 09:32:40 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 22 Jul 2016 13:32:40 +0000
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <E2844939-C2E5-47EB-A031-AE29603D1FBD@hibernate.org>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
	<4FC109C0-070E-4D20-9D24-AABEF7B9133C@hibernate.org>
	<CAFdSV9ugqgJGqHRnWhNF-nFZMpqHhiC9yyDeH0r08eo3Nm==Vw@mail.gmail.com>
	<CAFdSV9uPWkehRv8raXqMYgkodAg_9K57ZMkNe2tuecJaTXFn4w@mail.gmail.com>
	<CAFdSV9ujif8+KKMBpVQDZm9aG05v_an3jHLYtE3OLDkt9wa=2A@mail.gmail.com>
	<20160722091445.GD11493@hibernate.org>
	<E2844939-C2E5-47EB-A031-AE29603D1FBD@hibernate.org>
Message-ID: <CAFdSV9v=RkR2ZH18uHtBY8tUbdDjXC54_C8BbUmH1Yfo+XtLEw@mail.gmail.com>

I get what you mean.  We have to start from a "bindable" root.  FWIW other
types beside entity could be a "contextualization root" depending on the
Metamodel method signature.

Obviously the return from Metamodel#embeddable(Class) could not.  But, we
could expose methods that would allow access the "embedded" form, e.g.:


   - Metamodel#embedded(ManagedType,String) - String is the embedded
   attribute role relative to ManagedType
   - Metamodel#embedded(Path)
   - Metamodel#embedded(AttributePath)
   - Metamodel#embedded(AttributeRole)
   - Metamodel#embedded(String)

etc

similar for collections.

I take "contextualization" to mean "providing a context back to a root".
And in that sense, yes, you grok and describe the exact point I am
struggling with now.  I could not communicate it clearly because I have
developed the proper terms and concepts to describe and model it.  So thank
you for the different perspective, it helps.  I am still going through your
larger reply and trying to distill it into my mental model.


On Fri, Jul 22, 2016 at 5:21 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> The contextualization would only work when user calls metamodel.entity().
> Not the other methods
>
> > On 22 juil. 2016, at 11:14, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >
> > The good news is that I am following you :D
> >
> > I think one of the option is some API to which you can pass the (JPA)
> > Type, a Path from root and it would return a structure qualifying the
> > embedded info and not just the embeddable.
> >
> > I'm making things up here
> >
> > //might not even need the type, could be guessed from the Path?
> > AttributeMapping am = mappingProvider.forPath(path);
> >
> > What's nasty is that it then requires two parallel APIs, or rather it
> > would not flow from an enhanced JPA type API.
> >
> > An alternative would be what I think you propose with the BindableType,
> > that is an extension point that describes the specifics of the
> > specialization when navigating from one node type to another. I think.
> >
> > An alternative that I can think of is as follows. I'm assuming that the
> > data that needs to be contextualized by the path is mapping in nature or
> > at least not at all represented in the JPA types.
> > Each (JPA) type instance would be inherently specific to the path it
> > comes from. It would keep exposing the JPA non contextualized info but
> > also add contextualized info.
> >
> > HibernateEntityType<Foo> fooModel =
> >  (HibernateEntityType<Foo>)
> entityManagerFactory.getMetamodel().entity(Foo.class); // considered a root
> for navigation
> >
> > for (HibernateSingularAttribute sa : fooModel.getSingularAttributes()) {
> >   if (sa.getPersistentAttributeType() == EMBEDDED) {
> >       HibernateEmbeddableType et = (HibernateEmbeddableType)
> sa.getType();
> >       for (HibernateSingularAttribute esa :
> fooModel.getSingularAttributes()) {
> >           if (esa.getPersistentAttributeType() == BASIC) {
> >               int span = esa.getPhysicalInfo().getColumnSpan();
> >           }
> >      }
> >    }
> > }
> >
> > Hopefully, JPA does not mandate == between different types.
> >
> > A question I have is how navigable and easy such API would be for a
> > persister. But that's something to explore.
> >
> > Emmanuel
> >
> >> On Thu 2016-07-21 21:10, Steve Ebersole wrote:
> >> Put another way, I think the problem (and probably the solution) here is
> >> similar to JPA's Bindable (and Path) concept.
> >>
> >>> On Thu, Jul 21, 2016 at 2:27 PM Steve Ebersole <steve at hibernate.org>
> wrote:
> >>>
> >>> One goal of the redesign is to build more friendly, easy-to-follow
> >>> contract for access to this metadata at runtime (legacy persister
> state).
> >>> Rather than accessing pieces of information pertaining to attributes
> across
> >>> many, many arrays I wanted an array of a composite representation of
> these
> >>> attributes.  JPA defines it this way, so on some level you'd think it
> would
> >>> be pretty straightforward to move this direction.  The major
> pain-point I
> >>> have been facing is that JPA does not define "mapping information" at
> all
> >>> in its Metamodel/Types.  The main place this comes to a head is
> >>> EmbeddableType, especially given access to it directly on Metamodel *by
> >>> class*.  In JPA terms that return has to model the Embeddable (no
> mapping
> >>> info) rather than the Embedded.  And then further when we
> >>> expose EmbeddableType's attributes we have the same problem continued
> >>> because the context/root is the embeddable rather than the embedded.
> >>> Hopefully this makes sense, but as an example consider (using a
> "component
> >>> safe NamingStrategy):
> >>>
> >>> @Entity
> >>> class Store {
> >>>    ...
> >>>    @Embedded
> >>>    Address headquartersAddress;
> >>>    @Embedded
> >>>    Address locationAddress;
> >>> }
> >>>
> >>> @Embeddable
> >>> class Address {
> >>>    String streetAddress;
> >>>    @Embedded
> >>>    PostalCode postalCode;
> >>>    ...
> >>> }
> >>>
> >>> @Embeddable
> >>> class PostalCode {
> >>>    String zip;
> >>>    String plus4;
> >>>    @ManyToOne
> >>>    City city;
> >>> }
> >>>
> >>> Then consider that JPA frames access to this information as:
> >>>
> >>> EmbeddableType<Address> addrType = metamodel.embeddable( Address.class
> );
> >>>
> >>> Because it is generic to the Address embeddable, we have no access to
> the
> >>> specific embedded mapping info.  And if we follow this access down
> further,
> >>> it also means the same for accessing the attributes of that
> EmbeddableType<Address>.
> >>> For example, accessing the "postalCode.zip" from the
> EmbeddableType<Address>
> >>> we'd have no ability to resolve whether that maps to
> "headquartersAddress_postalCode_zip"
> >>> or "locationAddress_postalCode_zip".  And of course, as an ORM we need
> >>> access to that mapping information :)
> >>>
> >>> Essentially that is the crux of the difficulty I have at the moment.
> >>>
> >>> I know we could get around this by splitting (or keeping split) the
> >>> notions of ORM Type and JPA Type, but I would like to avoid that : this
> >>> unification is going to be important to the SQM Criteria support.
> >>>
> >>> So the question becomes how to best handle exposing an "Attribute" with
> >>> mapping information as well as an "Attribute" without mapping
> information.
> >>>
> >>> I will be working on some proposals for ways to do this over the next
> week
> >>> or so.  And maybe y'all see a solution easier than I do (I fear I may
> not
> >>> be seeing the forest through the trees atm).
> >>>
> >>>
> >>> On Thu, Jul 21, 2016 at 7:49 AM Steve Ebersole <steve at hibernate.org>
> >>> wrote:
> >>>
> >>>> I am working on a larger response to some current challenges, but
> here is
> >>>> a quick response to your specific points...
> >>>>
> >>>> On Wed, Jul 20, 2016 at 12:50 PM Emmanuel Bernard <
> emmanuel at hibernate.org>
> >>>> wrote:
> >>>>
> >>>>>
> >>>>> BasicType does not handle multiple column and compositeType is the
> >>>>> mebedded case. How would multi-column types would be handled?
> >>>>
> >>>> In terms of what exactly?  Assuming you mean access to the JDBC
> >>>> descriptors, that is still being determined.  At the moment there is
> no
> >>>> single Type-level access to this information.  Each specific Type
> >>>> sub-interface defines access differently.  I am not a fan of that that
> >>>> aspect.  The other approach is to define a plural form on Type
> >>>> (Type#getColumnMappings), and BasicType would just ensure that there
> is
> >>>> just one.
> >>>>
> >>>>
> >>>> Why do you need to ?unscope" the TypeConfiguration? What do you gain
> from
> >>>>> it? I?m trying to picture a reuse use case?
> >>>>
> >>>> Functionally we do not gain anything.  I was just trying to be
> balanced.
> >>>> We injected the SF into the TypeConfiguration, I wanted to un-inject
> it as
> >>>> well for 2 reasons:
> >>>>
> >>>>   1. release the reference to the SF
> >>>>   2. prepare the TypeConfiguration for binding to another SF.
> >>>>
> >>>> The only use case I had in mind was tests where we occasionally build
> >>>> multiple SF instances from a single Metadata.
> >>>>
> >>>>
> >>>> Methods of Type needing Session: I used to call them passing null in
> some
> >>>>> old code and hoping for the best. Are the reasons for using Session
> still
> >>>>> present? Would be nice to get rid of that.
> >>>>
> >>>> This is only ever needed (sometimes) from EntityType.  I guess it
> depends
> >>>> which specific method(s) you are asking about.  For some (reading,
> writing)
> >>>> yes I think we will continue to need the Session: it is used for
> access to
> >>>> JDBC as well as other needed interactions with the Session/PC
> (scheduling
> >>>> ids for batch load, etc).  For other methods, maybe not.
> >>>>
> >>>>
> >>>> On the genericization of Type, it would be extremely nice indeed for
> OGM,
> >>>>> but it would require to genericize SqlTypeDescriptor and its methods
> >>>>> essentially. Not necessarily super trivial.
> >>>>
> >>>> I understand that.  It is not a primary goal for me tbh.  But if we
> can
> >>>> get a decent design for the ORM case and can see an easy way to
> extend this
> >>>> to OGM without negatively impacting ORM I am all for it.  Given the
> >>>> delegation to Binder and Extractor I think this will be doable,
> although I
> >>>> assume we will need some parameterized param object to make this
> work.  The
> >>>> paam object would give us access to "JDBC services" in ORM and
> something
> >>>> else in OGM.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Fri Jul 22 10:59:01 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 22 Jul 2016 14:59:01 +0000
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <20160722091445.GD11493@hibernate.org>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
	<4FC109C0-070E-4D20-9D24-AABEF7B9133C@hibernate.org>
	<CAFdSV9ugqgJGqHRnWhNF-nFZMpqHhiC9yyDeH0r08eo3Nm==Vw@mail.gmail.com>
	<CAFdSV9uPWkehRv8raXqMYgkodAg_9K57ZMkNe2tuecJaTXFn4w@mail.gmail.com>
	<CAFdSV9ujif8+KKMBpVQDZm9aG05v_an3jHLYtE3OLDkt9wa=2A@mail.gmail.com>
	<20160722091445.GD11493@hibernate.org>
Message-ID: <CAFdSV9ugnHwZ3eUBZjm01UOts71n6XbePCrYH4FfbBW=0Go63A@mail.gmail.com>

Some preliminary thoughts are inline.  Like I said in the earlier reply I
am still trying to distill this in total.

On Fri, Jul 22, 2016 at 4:14 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> The good news is that I am following you :D
>
> I think one of the option is some API to which you can pass the (JPA)
> Type, a Path from root and it would return a structure qualifying the
> embedded info and not just the embeddable.
>
> I'm making things up here
>
> //might not even need the type, could be guessed from the Path?
> AttributeMapping am = mappingProvider.forPath(path);
>
> What's nasty is that it then requires two parallel APIs, or rather it
> would not flow from an enhanced JPA type API.
>

Yes, this is more or less one option I had considered... at least the
general approach is the same.  Basically 2 separate, parallel ways to
describe attribute/mapping info.

However, that said, even Path (assuming you specifically
mean javax.persistence.criteria.Path) includes the "context" we need; it
has to ultimately be rooted back to a root (#getParentPath) with mapping
information: we cannot build a Path rooted at an embeddable.

So to further define these 2 "separate, parallel" models:

   1. Type would only ever deal with the generic model information (aligned
   with JPA) by Attribute.  Meaning this simply describes the domain model -
   more or less, obviously it does expose some simplistic persistence data
   points like inheritance-type, singular attribute "classifications", etc
   mandated by the JPA contracts.
   2. The idea of a "mapping model" would more follow this Path/Binadable
   model.  This would be the purpose of persisters and its exposed
   "MappedAttributes"

Yes, it would be much nicer if we could combine these models/concepts, but
I think the JPA model is just too limited to allow that.


An alternative would be what I think you propose with the BindableType,
> that is an extension point that describes the specifics of the
> specialization when navigating from one node type to another. I think.
>

Yes, and no.  Based on that break-down above - BindableType would just be
things that can be part of a Path.  In fact, in JPA Bindable/BindableType
has no correlation to its Type.  Bindable simply unifies things that can be
part of a query Path which could be either:

   1. an EntityType
   2. a SingularAttribute
   3. a PluralAttribute

This distinction is great because it happens to line up with how we see
this mapping information (with the assumption that a "root" can only ever
be the first - an EntityType).  So I'd slightly alter this list to say that
Bindable can be either:

   1. an EntityType*
   2. a SingularMappedAttribute
   3. a PluralMappedAttribute

(*) - can be root.

The idea of "MappedAttribute" would essentially be a composition of

   1. Attribute
   2. MappedAttributeContainer - extension of Bindable

I think that Path will not work for modeling since Path is specifically a
query concept and could be circular.

From daltodavide at gmail.com  Fri Jul 22 11:57:19 2016
From: daltodavide at gmail.com (Davide D'Alto)
Date: Fri, 22 Jul 2016 16:57:19 +0100
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <CALt0+o-xq0at6C7pTeNnyQLTycjmE+v5Z5a4XQxDx8dC0pd8MQ@mail.gmail.com>
References: <CALt0+o9hA+aQ1feyLVf=+aB=4NMtJe8E2tGCjDJOae63MRS5AA@mail.gmail.com>
	<CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>
	<CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
	<20160721120706.GD75699@hibernate.org>
	<CALt0+o-kHeeK2sb64gx0_WHBQwJjTRy47RJxh=tz8KnUTRodDg@mail.gmail.com>
	<20160721123809.GE75699@hibernate.org>
	<CALt0+o8+-9-9rpRwEPduB_=s6SePGdgDJRHTBJcdsa8wX_Wx5w@mail.gmail.com>
	<CANoTJYMbkJa_0GZoZEmwsp5AQEq-vnTu_yKV8LgrbMrQzYzU4g@mail.gmail.com>
	<CAFm4XO3_wC2TDwX6rqC4+yQmKS-VcWjg0e_ad=z52z3JbsYfyQ@mail.gmail.com>
	<CALt0+o-xq0at6C7pTeNnyQLTycjmE+v5Z5a4XQxDx8dC0pd8MQ@mail.gmail.com>
Message-ID: <CANoTJYNa4=9wv5zJf5o77J3Yg7Yb4G_qwsHB8pZmhrXL81V87w@mail.gmail.com>

I've updated the microdata on our blog.
I  used the google validation page to check the result:
https://search.google.com/structured-data/testing-tool/u/0/?hl=EN#url=http%3A%2F%2Fin.relation.to%2F

I'm not familiar with microdata, if you think that something is wrong
let me know.

I have a question about the organization, should I put Red Hat or Hibernate?
At the moment I'm using Hibernate and hibernate.org as organizarion
url, but let me know.

Cheers,
Davide

On Thu, Jul 21, 2016 at 11:26 PM, Guillaume Smet
<guillaume.smet at gmail.com> wrote:
> On Thu, Jul 21, 2016 at 3:06 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>> Maybe we could move that to the website, as similar metadata is
>> already being deployed, e.g.
>>  - https://github.com/hibernate/hibernate.org/tree/staging/_data/projects/search/releases
>
> We already need to update the /stable/ symlink on the doc server so we
> might as well do it when we push the doc.
>
> I got something like this:
> https://gist.github.com/gsmet/8c8e29c46337f69bfbc9e84f108d951f . I'll
> push a PR tomorrow.
>
> I pushed the JS and the metadata to all known doc versions of Search and OGM.
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From emmanuel at hibernate.org  Fri Jul 22 12:33:33 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 22 Jul 2016 18:33:33 +0200
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <CANoTJYNa4=9wv5zJf5o77J3Yg7Yb4G_qwsHB8pZmhrXL81V87w@mail.gmail.com>
References: <CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>
	<CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
	<20160721120706.GD75699@hibernate.org>
	<CALt0+o-kHeeK2sb64gx0_WHBQwJjTRy47RJxh=tz8KnUTRodDg@mail.gmail.com>
	<20160721123809.GE75699@hibernate.org>
	<CALt0+o8+-9-9rpRwEPduB_=s6SePGdgDJRHTBJcdsa8wX_Wx5w@mail.gmail.com>
	<CANoTJYMbkJa_0GZoZEmwsp5AQEq-vnTu_yKV8LgrbMrQzYzU4g@mail.gmail.com>
	<CAFm4XO3_wC2TDwX6rqC4+yQmKS-VcWjg0e_ad=z52z3JbsYfyQ@mail.gmail.com>
	<CALt0+o-xq0at6C7pTeNnyQLTycjmE+v5Z5a4XQxDx8dC0pd8MQ@mail.gmail.com>
	<CANoTJYNa4=9wv5zJf5o77J3Yg7Yb4G_qwsHB8pZmhrXL81V87w@mail.gmail.com>
Message-ID: <20160722163333.GI11493@hibernate.org>

Hibernate is fine.

On Fri 2016-07-22 16:57, Davide D'Alto wrote:
> I've updated the microdata on our blog.
> I  used the google validation page to check the result:
> https://search.google.com/structured-data/testing-tool/u/0/?hl=EN#url=http%3A%2F%2Fin.relation.to%2F
> 
> I'm not familiar with microdata, if you think that something is wrong
> let me know.
> 
> I have a question about the organization, should I put Red Hat or Hibernate?
> At the moment I'm using Hibernate and hibernate.org as organizarion
> url, but let me know.
> 
> Cheers,
> Davide
> 
> On Thu, Jul 21, 2016 at 11:26 PM, Guillaume Smet
> <guillaume.smet at gmail.com> wrote:
> > On Thu, Jul 21, 2016 at 3:06 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> >> Maybe we could move that to the website, as similar metadata is
> >> already being deployed, e.g.
> >>  - https://github.com/hibernate/hibernate.org/tree/staging/_data/projects/search/releases
> >
> > We already need to update the /stable/ symlink on the doc server so we
> > might as well do it when we push the doc.
> >
> > I got something like this:
> > https://gist.github.com/gsmet/8c8e29c46337f69bfbc9e84f108d951f . I'll
> > push a PR tomorrow.
> >
> > I pushed the JS and the metadata to all known doc versions of Search and OGM.
> >
> > --
> > Guillaume
> > _______________________________________________
> > 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 emmanuel at hibernate.org  Fri Jul 22 12:35:38 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 22 Jul 2016 18:35:38 +0200
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <CAFdSV9ugnHwZ3eUBZjm01UOts71n6XbePCrYH4FfbBW=0Go63A@mail.gmail.com>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
	<4FC109C0-070E-4D20-9D24-AABEF7B9133C@hibernate.org>
	<CAFdSV9ugqgJGqHRnWhNF-nFZMpqHhiC9yyDeH0r08eo3Nm==Vw@mail.gmail.com>
	<CAFdSV9uPWkehRv8raXqMYgkodAg_9K57ZMkNe2tuecJaTXFn4w@mail.gmail.com>
	<CAFdSV9ujif8+KKMBpVQDZm9aG05v_an3jHLYtE3OLDkt9wa=2A@mail.gmail.com>
	<20160722091445.GD11493@hibernate.org>
	<CAFdSV9ugnHwZ3eUBZjm01UOts71n6XbePCrYH4FfbBW=0Go63A@mail.gmail.com>
Message-ID: <20160722163538.GJ11493@hibernate.org>

I am eager to see what you think of my third option in my email. I dread
there is a technical blocker somewhere but it would be quite a nice
solution if that's not the case.

On Fri 2016-07-22 14:59, Steve Ebersole wrote:
> Some preliminary thoughts are inline.  Like I said in the earlier reply I
> am still trying to distill this in total.
> 
> On Fri, Jul 22, 2016 at 4:14 AM Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> 
> > The good news is that I am following you :D
> >
> > I think one of the option is some API to which you can pass the (JPA)
> > Type, a Path from root and it would return a structure qualifying the
> > embedded info and not just the embeddable.
> >
> > I'm making things up here
> >
> > //might not even need the type, could be guessed from the Path?
> > AttributeMapping am = mappingProvider.forPath(path);
> >
> > What's nasty is that it then requires two parallel APIs, or rather it
> > would not flow from an enhanced JPA type API.
> >
> 
> Yes, this is more or less one option I had considered... at least the
> general approach is the same.  Basically 2 separate, parallel ways to
> describe attribute/mapping info.
> 
> However, that said, even Path (assuming you specifically
> mean javax.persistence.criteria.Path) includes the "context" we need; it
> has to ultimately be rooted back to a root (#getParentPath) with mapping
> information: we cannot build a Path rooted at an embeddable.
> 
> So to further define these 2 "separate, parallel" models:
> 
>    1. Type would only ever deal with the generic model information (aligned
>    with JPA) by Attribute.  Meaning this simply describes the domain model -
>    more or less, obviously it does expose some simplistic persistence data
>    points like inheritance-type, singular attribute "classifications", etc
>    mandated by the JPA contracts.
>    2. The idea of a "mapping model" would more follow this Path/Binadable
>    model.  This would be the purpose of persisters and its exposed
>    "MappedAttributes"
> 
> Yes, it would be much nicer if we could combine these models/concepts, but
> I think the JPA model is just too limited to allow that.
> 
> 
> An alternative would be what I think you propose with the BindableType,
> > that is an extension point that describes the specifics of the
> > specialization when navigating from one node type to another. I think.
> >
> 
> Yes, and no.  Based on that break-down above - BindableType would just be
> things that can be part of a Path.  In fact, in JPA Bindable/BindableType
> has no correlation to its Type.  Bindable simply unifies things that can be
> part of a query Path which could be either:
> 
>    1. an EntityType
>    2. a SingularAttribute
>    3. a PluralAttribute
> 
> This distinction is great because it happens to line up with how we see
> this mapping information (with the assumption that a "root" can only ever
> be the first - an EntityType).  So I'd slightly alter this list to say that
> Bindable can be either:
> 
>    1. an EntityType*
>    2. a SingularMappedAttribute
>    3. a PluralMappedAttribute
> 
> (*) - can be root.
> 
> The idea of "MappedAttribute" would essentially be a composition of
> 
>    1. Attribute
>    2. MappedAttributeContainer - extension of Bindable
> 
> I think that Path will not work for modeling since Path is specifically a
> query concept and could be circular.

From steve at hibernate.org  Fri Jul 22 13:39:14 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 22 Jul 2016 17:39:14 +0000
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <20160722163538.GJ11493@hibernate.org>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
	<4FC109C0-070E-4D20-9D24-AABEF7B9133C@hibernate.org>
	<CAFdSV9ugqgJGqHRnWhNF-nFZMpqHhiC9yyDeH0r08eo3Nm==Vw@mail.gmail.com>
	<CAFdSV9uPWkehRv8raXqMYgkodAg_9K57ZMkNe2tuecJaTXFn4w@mail.gmail.com>
	<CAFdSV9ujif8+KKMBpVQDZm9aG05v_an3jHLYtE3OLDkt9wa=2A@mail.gmail.com>
	<20160722091445.GD11493@hibernate.org>
	<CAFdSV9ugnHwZ3eUBZjm01UOts71n6XbePCrYH4FfbBW=0Go63A@mail.gmail.com>
	<20160722163538.GJ11493@hibernate.org>
Message-ID: <CAFdSV9sGhO2SpCQ_fXH8nN90dr0Uy6R7gM2donzwTCFRd3CtpA@mail.gmail.com>

Still letting it percolate :)


On Fri, Jul 22, 2016 at 11:35 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> I am eager to see what you think of my third option in my email. I dread
> there is a technical blocker somewhere but it would be quite a nice
> solution if that's not the case.
>
> On Fri 2016-07-22 14:59, Steve Ebersole wrote:
> > Some preliminary thoughts are inline.  Like I said in the earlier reply I
> > am still trying to distill this in total.
> >
> > On Fri, Jul 22, 2016 at 4:14 AM Emmanuel Bernard <emmanuel at hibernate.org
> >
> > wrote:
> >
> > > The good news is that I am following you :D
> > >
> > > I think one of the option is some API to which you can pass the (JPA)
> > > Type, a Path from root and it would return a structure qualifying the
> > > embedded info and not just the embeddable.
> > >
> > > I'm making things up here
> > >
> > > //might not even need the type, could be guessed from the Path?
> > > AttributeMapping am = mappingProvider.forPath(path);
> > >
> > > What's nasty is that it then requires two parallel APIs, or rather it
> > > would not flow from an enhanced JPA type API.
> > >
> >
> > Yes, this is more or less one option I had considered... at least the
> > general approach is the same.  Basically 2 separate, parallel ways to
> > describe attribute/mapping info.
> >
> > However, that said, even Path (assuming you specifically
> > mean javax.persistence.criteria.Path) includes the "context" we need; it
> > has to ultimately be rooted back to a root (#getParentPath) with mapping
> > information: we cannot build a Path rooted at an embeddable.
> >
> > So to further define these 2 "separate, parallel" models:
> >
> >    1. Type would only ever deal with the generic model information
> (aligned
> >    with JPA) by Attribute.  Meaning this simply describes the domain
> model -
> >    more or less, obviously it does expose some simplistic persistence
> data
> >    points like inheritance-type, singular attribute "classifications",
> etc
> >    mandated by the JPA contracts.
> >    2. The idea of a "mapping model" would more follow this Path/Binadable
> >    model.  This would be the purpose of persisters and its exposed
> >    "MappedAttributes"
> >
> > Yes, it would be much nicer if we could combine these models/concepts,
> but
> > I think the JPA model is just too limited to allow that.
> >
> >
> > An alternative would be what I think you propose with the BindableType,
> > > that is an extension point that describes the specifics of the
> > > specialization when navigating from one node type to another. I think.
> > >
> >
> > Yes, and no.  Based on that break-down above - BindableType would just be
> > things that can be part of a Path.  In fact, in JPA Bindable/BindableType
> > has no correlation to its Type.  Bindable simply unifies things that can
> be
> > part of a query Path which could be either:
> >
> >    1. an EntityType
> >    2. a SingularAttribute
> >    3. a PluralAttribute
> >
> > This distinction is great because it happens to line up with how we see
> > this mapping information (with the assumption that a "root" can only ever
> > be the first - an EntityType).  So I'd slightly alter this list to say
> that
> > Bindable can be either:
> >
> >    1. an EntityType*
> >    2. a SingularMappedAttribute
> >    3. a PluralMappedAttribute
> >
> > (*) - can be root.
> >
> > The idea of "MappedAttribute" would essentially be a composition of
> >
> >    1. Attribute
> >    2. MappedAttributeContainer - extension of Bindable
> >
> > I think that Path will not work for modeling since Path is specifically a
> > query concept and could be circular.
>

From gbadner at redhat.com  Fri Jul 22 15:08:18 2016
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 22 Jul 2016 12:08:18 -0700
Subject: [hibernate-dev] Needing and ORM 5.1.1.Final
In-Reply-To: <7569820e-91ac-3daa-fbd6-7597e981660b@gmail.com>
References: <CAFm4XO1D2WeeQ_M4_U=ESDcOAPZRZ4QQueTHuqas5b_kgG7L_A@mail.gmail.com>
	<7569820e-91ac-3daa-fbd6-7597e981660b@gmail.com>
Message-ID: <CAFDzhiRawy0=Lks93cHTcXmnBGg-dfYZps2JrOcXA31YTGjyZw@mail.gmail.com>

It looks like it will be next week (hopefull). We have a critical issue to
fix. Once that's done, I'll do the release.

On Wed, Jul 20, 2016 at 8:05 AM, Chris Cranford <crancran at gmail.com> wrote:

> Sanne -
>
> I'm under the impression that Gail has plans to do a 5.0.10 / 5.1.1 late
> this week if all goes according to plan.
>
> Chris
>
>
> On 07/20/2016 04:36 AM, Sanne Grinovero wrote:
> > Hi all,
> > we're still needing a release of Hibernate ORM 5.1.1 for Hibernate OGM..
> >
> > could we plan for one soon please?
> >
> > 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 gbadner at redhat.com  Fri Jul 22 15:09:07 2016
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 22 Jul 2016 12:09:07 -0700
Subject: [hibernate-dev] "Awaiting Testcase" transition
In-Reply-To: <CAFdSV9s84Dg4RDMr4V-qM861KZTycsNun3e_ifzSvmM7nEyszg@mail.gmail.com>
References: <CAFdSV9suTBTG+ZzMUvFkZ9Pb6Mg_o2gjDGrop+q+rGRqBFhzvA@mail.gmail.com>
	<578C0C2C.7070702@hibernate.org>
	<d21092b1-65eb-1a3e-65fa-df6297fa0fab@hibernate.org>
	<CAFdSV9s84Dg4RDMr4V-qM861KZTycsNun3e_ifzSvmM7nEyszg@mail.gmail.com>
Message-ID: <CAFDzhiTLbqaWhVFnYLoBaYocs5GFrSimjGxv1wBJyiOAJFKNhA@mail.gmail.com>

+1

On Mon, Jul 18, 2016 at 6:25 AM, Steve Ebersole <steve at hibernate.org> wrote:

> This is the comment that will now be added to an issue whenever an issue is
> transitioned to "Awaiting Test Case":
>
> Please attach a short but complete [test case|
> https://github.com/hibernate/hibernate-orm/wiki/Test-Case-Guide] that
> reproduces the reported bug.
>
> * That Test Case Guide is something I just wrote.
>
>
> On Sun, Jul 17, 2016 at 9:27 PM Chris Cranford <chris at hibernate.org>
> wrote:
>
> > +1
> > On 07/17/2016 05:52 PM, Brett Meyer wrote:
> > > +1!
> > >
> > > On 07/17/2016 10:54 AM, Steve Ebersole wrote:
> > >> I see folks using a generic "template" for the comment added to an
> issue
> > >> when they transition it to the "Awaiting Testcase" status.  If we all
> > >> agree, we could make that a post-function of the transition - meaning
> > that
> > >> comment would be added automatically.
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Jul 22 15:22:04 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 22 Jul 2016 19:22:04 +0000
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <20160722091445.GD11493@hibernate.org>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
	<4FC109C0-070E-4D20-9D24-AABEF7B9133C@hibernate.org>
	<CAFdSV9ugqgJGqHRnWhNF-nFZMpqHhiC9yyDeH0r08eo3Nm==Vw@mail.gmail.com>
	<CAFdSV9uPWkehRv8raXqMYgkodAg_9K57ZMkNe2tuecJaTXFn4w@mail.gmail.com>
	<CAFdSV9ujif8+KKMBpVQDZm9aG05v_an3jHLYtE3OLDkt9wa=2A@mail.gmail.com>
	<20160722091445.GD11493@hibernate.org>
Message-ID: <CAFdSV9s1p5ybnaorF37GOPkh=b7u4HV-hezR+6o+6JS+efoK-g@mail.gmail.com>

On Fri, Jul 22, 2016 at 4:14 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

An alternative that I can think of is as follows. I'm assuming that the
> data that needs to be contextualized by the path is mapping in nature or
> at least not at all represented in the JPA types.
> Each (JPA) type instance would be inherently specific to the path it
> comes from. It would keep exposing the JPA non contextualized info but
> also add contextualized info.
>
> HibernateEntityType<Foo> fooModel =
>   (HibernateEntityType<Foo>)
> entityManagerFactory.getMetamodel().entity(Foo.class); // considered a root
> for navigation
>
> for (HibernateSingularAttribute sa : fooModel.getSingularAttributes()) {
>    if (sa.getPersistentAttributeType() == EMBEDDED) {
>        HibernateEmbeddableType et = (HibernateEmbeddableType) sa.getType();
>        for (HibernateSingularAttribute esa :
> fooModel.getSingularAttributes()) {
>            if (esa.getPersistentAttributeType() == BASIC) {
>                int span = esa.getPhysicalInfo().getColumnSpan();
>            }
>       }
>     }
> }
>
>
Yes this is quite similar to what I had in mind.  One thing I had
envisioned differently was to have  sa.getPersistentAttributeType() ==
EMBEDDED translate as the attribute being an EmbeddedAttributeMapping which
gives access to what I think you mean by "physical info".

But other than that, yes I think we see it the same way.

From guillaume.smet at gmail.com  Fri Jul 22 19:55:39 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Sat, 23 Jul 2016 01:55:39 +0200
Subject: [hibernate-dev] [OGM] Mapping of embedded
In-Reply-To: <CALt0+o83WZj29NCw-HTyaNAdTyU1tjsrRmaitZnLeRU9DkGW+A@mail.gmail.com>
References: <CALt0+o9xuwqS+ZxkYFVxJ9Vdh1xXimS1ouHnmRUpybdR=sWvwQ@mail.gmail.com>
	<CALt0+o83WZj29NCw-HTyaNAdTyU1tjsrRmaitZnLeRU9DkGW+A@mail.gmail.com>
Message-ID: <0057EDA1-0F24-4234-A4B8-6EB4F2CA8703@gmail.com>

Hi all,

So after having discussed this issue with Emmanuel:

1/ is correct. It's the behavior we expect considering the ORM behavior. If we want the postal_code to be nested in homeAddress, we need to use @Column(name = "homeAddress.postal_code") or @AttributeOverride(name="zipCode", column=@Column(name="homeAddress.postal_code").

See the note here: http://docs.jboss.org/hibernate/ogm/5.0/reference/en-US/html_single/#d0e9677

[2/ current situation] was incorrect and needed to be fixed

[2/ after PR 728] is still incorrect

In this case, to have the postal_code nested in addresses, we would expect the user to use an @AttributeOverride to set the column name to addresses.postal_code.

So this is what we need to fix to be consistent:

List<Address> with Address>@Column("postal_code")
-> not supported

List<Address> with Address>@Column("addresses.postal_code") - probably not very useful in practice - or an @AttributeOverride(name="zipCode", column=@Column(name="addresses.postal_code") on the addresses property,
->
{
   "addresses": [
      {
          "country": "Germany",
          "city": "Paris",
          "street1": "1 avenue des Champs Elysees",
          "postal_code": "75007"
      },
      {
          "city": "Rome",
          "street1": "Piazza del Colosseo, 1",
          "type": {
              "name": "primary"
          },
          "postal_code": "00184"
      }
   ],
}

If we want to change that in the future (default to nested), we need to wait for OGM 6 and we will need ORM to keep the path information, which is not the case atm. So if we want to consider it, we probably need to ping Steve et al. about this.

We need to fix this before merging PR 728. Davide, do you take the lead on this or should I? I'm on vacation next week. 

We also need to add more tests for this behavior.

-- 
Guillaume

> On Wed, Jul 13, 2016 at 3:22 PM, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> So this is a followup of my previous email (looks like I found out the
> Send shortcut on GMail...)... which was supposed to be a followup of:
> * https://hibernate.atlassian.net/browse/OGM-893
> * https://github.com/hibernate/hibernate-ogm/pull/728
> * and a discussion we had yesterday with Davide.
> 
> Taking MongoDB as the reference implementation here.
> 
> Current situation
> =================
> 
> 1/ for a simple embedded Address (property: homeAddress) with one of
> the property having a @Column(name = "postal_code"), we end up with
> the following mapping:
> {
>    [...],
>    'homeAddress' : {
>        'city' : 'Paris',
>        'country' : 'France',
>        'street1' : '1 avenue des Champs Elysees',
>        'type' : {
>            'name' : 'main'
>        }
>    },
>    'postal_code' : '75007',
>    [...]
> }
> As you can see, postal_code is stored outside of the nested structure.
> This is in line with the ORM behavior where you end up having the
> columns homeAddress_city and postal_code.
> 
> Of course, this is a bit weird when we are considering nested documents.
> 
> See EmbeddableMappingTest for reference.
> 
> 2/ now suppose that we have a List<Address>, the current mapping is
> the following:
> {
>    [...],
>    "addresses": [
>       {
>           "addresses": {
>               "country": "Germany",
>               "city": "Paris",
>               "street1": "1 avenue des Champs Elysees"
>           },
>            "postal_code": "75007"
>       },
>       {
>           "addresses": {
>               "city": "Rome",
>               "street1": "Piazza del Colosseo, 1",
>               "type": {
>                   "name": "primary"
>               }
>           },
>            "postal_code": "00184"
>       }
>    ],
>    [...]
> }
> 
> Note the fact that addresses is nested twice.
> 
> This is discussed at length in https://hibernate.atlassian.net/browse/OGM-893.
> 
> What does PR 728 change?
> ========================
> 
> After the work we did with Steve on ORM and the followup of Davide on
> OGM, we end up with the following situation:
> 
> 1/ Same as before. postal_code is outside of the nested document.
> 
> 2/ This is where the behavior has changed, we now have the following mapping:
> {
>    "addresses": [
>       {
>           "country": "Germany",
>           "city": "Paris",
>           "street1": "1 avenue des Champs Elysees",
>           "postal_code": "75007"
>       },
>       {
>           "city": "Rome",
>           "street1": "Piazza del Colosseo, 1",
>           "type": {
>               "name": "primary"
>           },
>           "postal_code": "00184"
>       }
>    ],
> }
> 
> Note that postal_code and city are now at the same level.
> 
> See this future test executed on top of pr/728:
> https://gist.github.com/gsmet/0652294523b2c48efe72668ccc0a6e1c
> 
> Conclusion
> ==========
> 
> So as you can see, the mapping is quite different between a simple
> embedded and a list of embedded. I was not very happy with the
> behavior of 2/ before, especially because if you remove the @Column,
> you lose the data stored. Same if you didn't have one before and you
> add one to your embeddable.
> 
> But I'm also not convinced having a different behavior between 1/ and
> 2/ is the way to go. Note that, from what I've seen, I don't think
> changing 1/ to move postal_code in the nested document will be easy
> (or even feasible).
> 
> Opinions? Thoughts?
> 
> --
> Guillaume


From emmanuel at hibernate.org  Mon Jul 25 08:10:48 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 25 Jul 2016 14:10:48 +0200
Subject: [hibernate-dev] [OGM] Mapping of embedded
In-Reply-To: <0057EDA1-0F24-4234-A4B8-6EB4F2CA8703@gmail.com>
References: <CALt0+o9xuwqS+ZxkYFVxJ9Vdh1xXimS1ouHnmRUpybdR=sWvwQ@mail.gmail.com>
	<CALt0+o83WZj29NCw-HTyaNAdTyU1tjsrRmaitZnLeRU9DkGW+A@mail.gmail.com>
	<0057EDA1-0F24-4234-A4B8-6EB4F2CA8703@gmail.com>
Message-ID: <20160725121048.GN11493@hibernate.org>

On Sat 2016-07-23  1:55, Guillaume Smet wrote:
> Hi all,
> 
> So after having discussed this issue with Emmanuel:
> 
> 1/ is correct. It's the behavior we expect considering the ORM behavior. If we want the postal_code to be nested in homeAddress, we need to use @Column(name = "homeAddress.postal_code") or @AttributeOverride(name="zipCode", column=@Column(name="homeAddress.postal_code").
> 
> See the note here: http://docs.jboss.org/hibernate/ogm/5.0/reference/en-US/html_single/#d0e9677
> 
> [2/ current situation] was incorrect and needed to be fixed
> 
> [2/ after PR 728] is still incorrect
> 
> In this case, to have the postal_code nested in addresses, we would expect the user to use an @AttributeOverride to set the column name to addresses.postal_code.
> 
> So this is what we need to fix to be consistent:
> 
> List<Address> with Address>@Column("postal_code")
> -> not supported
> 
> List<Address> with Address>@Column("addresses.postal_code") - probably not very useful in practice - or an @AttributeOverride(name="zipCode", column=@Column(name="addresses.postal_code") on the addresses property,

I am having second thoughts on the collection case. When I look at ORM's
test suite and AttributeOverrideTest + PropertyRecord, the property name
is not including the owning property (addresses in this case).

	@AttributeOverrides({
			@AttributeOverride(name = "size", column = @Column(name = "SQUARE_FEET")),
			@AttributeOverride(name = "tax", column = @Column(name = "ASSESSMENT"))
					})
	@ElementCollection
	public Set<PropertyInfo> unsortedParcels;

So we probably should not need to put "addresses" in the @Column for the collection cases. It makes sense from an ORM PoV since we are talking about different tables.

> ->
> {
>    "addresses": [
>       {
>           "country": "Germany",
>           "city": "Paris",
>           "street1": "1 avenue des Champs Elysees",
>           "postal_code": "75007"
>       },
>       {
>           "city": "Rome",
>           "street1": "Piazza del Colosseo, 1",
>           "type": {
>               "name": "primary"
>           },
>           "postal_code": "00184"
>       }
>    ],
> }
> 
> If we want to change that in the future (default to nested), we need to wait for OGM 6 and we will need ORM to keep the path information, which is not the case atm. So if we want to consider it, we probably need to ping Steve et al. about this.
> 
> We need to fix this before merging PR 728. Davide, do you take the lead on this or should I? I'm on vacation next week. 
> 
> We also need to add more tests for this behavior.
> 
> -- 
> Guillaume
> 
> > On Wed, Jul 13, 2016 at 3:22 PM, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> > So this is a followup of my previous email (looks like I found out the
> > Send shortcut on GMail...)... which was supposed to be a followup of:
> > * https://hibernate.atlassian.net/browse/OGM-893
> > * https://github.com/hibernate/hibernate-ogm/pull/728
> > * and a discussion we had yesterday with Davide.
> > 
> > Taking MongoDB as the reference implementation here.
> > 
> > Current situation
> > =================
> > 
> > 1/ for a simple embedded Address (property: homeAddress) with one of
> > the property having a @Column(name = "postal_code"), we end up with
> > the following mapping:
> > {
> >    [...],
> >    'homeAddress' : {
> >        'city' : 'Paris',
> >        'country' : 'France',
> >        'street1' : '1 avenue des Champs Elysees',
> >        'type' : {
> >            'name' : 'main'
> >        }
> >    },
> >    'postal_code' : '75007',
> >    [...]
> > }
> > As you can see, postal_code is stored outside of the nested structure.
> > This is in line with the ORM behavior where you end up having the
> > columns homeAddress_city and postal_code.
> > 
> > Of course, this is a bit weird when we are considering nested documents.
> > 
> > See EmbeddableMappingTest for reference.
> > 
> > 2/ now suppose that we have a List<Address>, the current mapping is
> > the following:
> > {
> >    [...],
> >    "addresses": [
> >       {
> >           "addresses": {
> >               "country": "Germany",
> >               "city": "Paris",
> >               "street1": "1 avenue des Champs Elysees"
> >           },
> >            "postal_code": "75007"
> >       },
> >       {
> >           "addresses": {
> >               "city": "Rome",
> >               "street1": "Piazza del Colosseo, 1",
> >               "type": {
> >                   "name": "primary"
> >               }
> >           },
> >            "postal_code": "00184"
> >       }
> >    ],
> >    [...]
> > }
> > 
> > Note the fact that addresses is nested twice.
> > 
> > This is discussed at length in https://hibernate.atlassian.net/browse/OGM-893.
> > 
> > What does PR 728 change?
> > ========================
> > 
> > After the work we did with Steve on ORM and the followup of Davide on
> > OGM, we end up with the following situation:
> > 
> > 1/ Same as before. postal_code is outside of the nested document.
> > 
> > 2/ This is where the behavior has changed, we now have the following mapping:
> > {
> >    "addresses": [
> >       {
> >           "country": "Germany",
> >           "city": "Paris",
> >           "street1": "1 avenue des Champs Elysees",
> >           "postal_code": "75007"
> >       },
> >       {
> >           "city": "Rome",
> >           "street1": "Piazza del Colosseo, 1",
> >           "type": {
> >               "name": "primary"
> >           },
> >           "postal_code": "00184"
> >       }
> >    ],
> > }
> > 
> > Note that postal_code and city are now at the same level.
> > 
> > See this future test executed on top of pr/728:
> > https://gist.github.com/gsmet/0652294523b2c48efe72668ccc0a6e1c
> > 
> > Conclusion
> > ==========
> > 
> > So as you can see, the mapping is quite different between a simple
> > embedded and a list of embedded. I was not very happy with the
> > behavior of 2/ before, especially because if you remove the @Column,
> > you lose the data stored. Same if you didn't have one before and you
> > add one to your embeddable.
> > 
> > But I'm also not convinced having a different behavior between 1/ and
> > 2/ is the way to go. Note that, from what I've seen, I don't think
> > changing 1/ to move postal_code in the nested document will be easy
> > (or even feasible).
> > 
> > Opinions? Thoughts?
> > 
> > --
> > Guillaume
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Mon Jul 25 13:27:25 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 25 Jul 2016 17:27:25 +0000
Subject: [hibernate-dev] multiLoad support
Message-ID: <CAFdSV9sTJvRmzbVK1R8W7wZBoTJwLCgixC6F4QHzMtQtVdv0Ow@mail.gmail.com>

I wanted to start a consolidated discussion about multi-load support.  This
relates to a few Jiras, questioning a few different aspects of its current
behavior:

https://hibernate.atlassian.net/browse/HHH-10984
https://hibernate.atlassian.net/browse/HHH-10617

Basically this comes down to the following questions/requests...


## Handling locally deleted entities

First (from HHH-10984) is the idea that locally deleted entities are
currently returned from multi-load calls.  The background here is that
multi-load support was designed based on IdentifierLoadAccess#getReference
(Session#load).  So its outcome follows what is done for #getReference in
terms of behavior and results.  Now one of the behaviors of #getReference
that differs from IdentifierLoadAccess#load (Session#get) is how locally
deleted entities are treated: #getReference will return them, whereas #load
will not.

So as I see it we have 3 options:

   1. Continue to expose just the one form on MultiIdentifierLoadAccess and
   either have this filter out the locally deleted objects, or add a new
   option to specify whether locally deleted objects ought to be returned in
   the results.
   2. Expose 2 distinct forms on MultiIdentifierLoadAccess:
      1. Plural form of #getReference (current behavior, more or less)
      2. Plural form of #load
   3. Expose 3 distinct forms on MultiIdentifierLoadAccess:
      1. Plural form of #getReference
      2. Plural form of #load
      3. "Hybrid" form


## Ordering of results

Much of the discussion on HHH-10984 revolves around the (poorly based, imo)
assumption that because a List/array of ids is passed in and because a List
is returned that we ought to return the results in the order indicated by
the incoming List/array of ids.

While I do not agree with the assumption there, I can see that that
behavior might sometimes be beneficial.  Is this something we want to
support?  There is certainly a performance overhead, and so I think we
definitely do not want to support it by default.  But do we want to expose
an option to allow users to request this?

From andrea at hibernate.org  Mon Jul 25 14:02:19 2016
From: andrea at hibernate.org (andrea boriero)
Date: Mon, 25 Jul 2016 20:02:19 +0200
Subject: [hibernate-dev] multiLoad support
In-Reply-To: <CAL00eSQ4qB7atiA7KoekAL-RsE+djDEf-T7Sbv5CGYzAFhTJBg@mail.gmail.com>
References: <CAFdSV9sTJvRmzbVK1R8W7wZBoTJwLCgixC6F4QHzMtQtVdv0Ow@mail.gmail.com>
	<CAL00eSQdX1JYsXKeUj+MChja1KNiX0pTHWwawv7Wezg=FicNkA@mail.gmail.com>
	<CAL00eSQtc8qQcfqoAmXcKGpdNNxQ+pdKR4Jk0A9BeEg22pZOZw@mail.gmail.com>
	<CAL00eSQX3qkq_4FvFhEiNb41f9y7Pn7Duw5U2Qrj12RS+VRUgw@mail.gmail.com>
	<CAL00eSQ4qB7atiA7KoekAL-RsE+djDEf-T7Sbv5CGYzAFhTJBg@mail.gmail.com>
Message-ID: <CAL00eSQ1x7YLDAOSShFY5ednMG3370FHae9WxH5R9dQP7pzHoA@mail.gmail.com>

On 25 Jul 2016 19:29, "Steve Ebersole" <steve at hibernate.org> wrote:
>
> I wanted to start a consolidated discussion about multi-load support.
This
> relates to a few Jiras, questioning a few different aspects of its current
> behavior:
>
> https://hibernate.atlassian.net/browse/HHH-10984
> https://hibernate.atlassian.net/browse/HHH-10617
>
> Basically this comes down to the following questions/requests...
>
>
> ## Handling locally deleted entities
>
> First (from HHH-10984) is the idea that locally deleted entities are
> currently returned from multi-load calls.  The background here is that
> multi-load support was designed based on IdentifierLoadAccess#getReference
> (Session#load).  So its outcome follows what is done for #getReference in
> terms of behavior and results.  Now one of the behaviors of #getReference
> that differs from IdentifierLoadAccess#load (Session#get) is how locally
> deleted entities are treated: #getReference will return them, whereas
#load
> will not.
>
> So as I see it we have 3 options:
>
>    1. Continue to expose just the one form on MultiIdentifierLoadAccess
and
>    either have this filter out the locally deleted objects, or add a new
>    option to specify whether locally deleted objects ought to be returned
in
>    the results.
>    2. Expose 2 distinct forms on MultiIdentifierLoadAccess:
>       1. Plural form of #getReference (current behavior, more or less)
>       2. Plural form of #load
>    3. Expose 3 distinct forms on MultiIdentifierLoadAccess:
>       1. Plural form of #getReference
>       2. Plural form of #load
>       3. "Hybrid" form
>
>
I am inclined towards the 2 plural forms
> ## Ordering of results
>
> Much of the discussion on HHH-10984 revolves around the (poorly based,
imo)
> assumption that because a List/array of ids is passed in and because a
List
> is returned that we ought to return the results in the order indicated by
> the incoming List/array of ids.
>
> While I do not agree with the assumption there, I can see that that
> behavior might sometimes be beneficial.  Is this something we want to
> support?  There is certainly a performance overhead, and so I think we
> definitely do not want to support it by default.  But do we want to expose
> an option to allow users to request this?
>
+1 for exposing an option for ordering the results
_______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Mon Jul 25 14:06:06 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 25 Jul 2016 19:06:06 +0100
Subject: [hibernate-dev] multiLoad support
In-Reply-To: <CAFdSV9sTJvRmzbVK1R8W7wZBoTJwLCgixC6F4QHzMtQtVdv0Ow@mail.gmail.com>
References: <CAFdSV9sTJvRmzbVK1R8W7wZBoTJwLCgixC6F4QHzMtQtVdv0Ow@mail.gmail.com>
Message-ID: <CAFm4XO1Bkb0iZFqT-vvwDQx=d6o2YDPT1DARg+brLBFw_5Oy5w@mail.gmail.com>

some comments inline:

On 25 July 2016 at 18:27, Steve Ebersole <steve at hibernate.org> wrote:
> I wanted to start a consolidated discussion about multi-load support.  This
> relates to a few Jiras, questioning a few different aspects of its current
> behavior:
>
> https://hibernate.atlassian.net/browse/HHH-10984
> https://hibernate.atlassian.net/browse/HHH-10617
>
> Basically this comes down to the following questions/requests...
>
>
> ## Handling locally deleted entities
>
> First (from HHH-10984) is the idea that locally deleted entities are
> currently returned from multi-load calls.  The background here is that
> multi-load support was designed based on IdentifierLoadAccess#getReference
> (Session#load).  So its outcome follows what is done for #getReference in
> terms of behavior and results.  Now one of the behaviors of #getReference
> that differs from IdentifierLoadAccess#load (Session#get) is how locally
> deleted entities are treated: #getReference will return them, whereas #load
> will not.
>
> So as I see it we have 3 options:
>
>    1. Continue to expose just the one form on MultiIdentifierLoadAccess and
>    either have this filter out the locally deleted objects, or add a new
>    option to specify whether locally deleted objects ought to be returned in
>    the results.
>    2. Expose 2 distinct forms on MultiIdentifierLoadAccess:
>       1. Plural form of #getReference (current behavior, more or less)
>       2. Plural form of #load
>    3. Expose 3 distinct forms on MultiIdentifierLoadAccess:
>       1. Plural form of #getReference
>       2. Plural form of #load
>       3. "Hybrid" form

Regarding locally deleted entities, I understand the underlying logic
but as a user I think I'd be surprised for it to return them.
Is there a good use case to return these?

Failing that, I'd filter them out by resorting to a load-like semantic
and avoid giving options.


> ## Ordering of results
>
> Much of the discussion on HHH-10984 revolves around the (poorly based, imo)
> assumption that because a List/array of ids is passed in and because a List
> is returned that we ought to return the results in the order indicated by
> the incoming List/array of ids.

As discussed on chat, in lack of any explicit documentation I also
would have expected the order to be preserved, but stating otherwise
in javadoc seems good enough to me.

+1 to change the parameter type from List to Collection as you
suggested; the return should also be changed from List so to not
suggest any ordering guarantee but since that's breaking we'll do it
later.

> While I do not agree with the assumption there, I can see that that
> behavior might sometimes be beneficial.  Is this something we want to
> support?  There is certainly a performance overhead, and so I think we
> definitely do not want to support it by default.  But do we want to expose
> an option to allow users to request this?

Yes I think there would be performance benefits to allow the consumer
to push the sorting guarantee to ORM:
in worst case, ORM will do it in the same inefficient way that the
consumer would need to, but there might be cases in which ORM can do
something smarter.

In Hibernate Search we have two different situations in which we'd
load by "byMultipleIds";
in one case we'll need strict sorting, in the other we actually don't
care at all for the order.. so yes we'd benefit from an option.

Considering that the current API takes a List as parameter, and
returns a List, and that we seem to agree that there's value in
maintaining ordering.. maybe we should keep this API as is and make it
always ordered?
One could add the variation based on Collections as the alternative
API to use when ordering is not needed, by adding it as a new API we'd
not be breaking anything and still providing both options.

Thanks,
Sanne

From steve at hibernate.org  Mon Jul 25 14:55:50 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 25 Jul 2016 18:55:50 +0000
Subject: [hibernate-dev] multiLoad support
In-Reply-To: <CAFm4XO1Bkb0iZFqT-vvwDQx=d6o2YDPT1DARg+brLBFw_5Oy5w@mail.gmail.com>
References: <CAFdSV9sTJvRmzbVK1R8W7wZBoTJwLCgixC6F4QHzMtQtVdv0Ow@mail.gmail.com>
	<CAFm4XO1Bkb0iZFqT-vvwDQx=d6o2YDPT1DARg+brLBFw_5Oy5w@mail.gmail.com>
Message-ID: <CAFdSV9u-iUqoNUuMZHZp+yg4vcWbBpDVEe6Woiz16ZeVxUfu1A@mail.gmail.com>

See inline...


On Mon, Jul 25, 2016 at 1:06 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> some comments inline:
>
> On 25 July 2016 at 18:27, Steve Ebersole <steve at hibernate.org> wrote:
> > I wanted to start a consolidated discussion about multi-load support.
> This
> > relates to a few Jiras, questioning a few different aspects of its
> current
> > behavior:
> >
> > https://hibernate.atlassian.net/browse/HHH-10984
> > https://hibernate.atlassian.net/browse/HHH-10617
> >
> > Basically this comes down to the following questions/requests...
> >
> >
> > ## Handling locally deleted entities
> >
> > First (from HHH-10984) is the idea that locally deleted entities are
> > currently returned from multi-load calls.  The background here is that
> > multi-load support was designed based on
> IdentifierLoadAccess#getReference
> > (Session#load).  So its outcome follows what is done for #getReference in
> > terms of behavior and results.  Now one of the behaviors of #getReference
> > that differs from IdentifierLoadAccess#load (Session#get) is how locally
> > deleted entities are treated: #getReference will return them, whereas
> #load
> > will not.
> >
> > So as I see it we have 3 options:
> >
> >    1. Continue to expose just the one form on MultiIdentifierLoadAccess
> and
> >    either have this filter out the locally deleted objects, or add a new
> >    option to specify whether locally deleted objects ought to be
> returned in
> >    the results.
> >    2. Expose 2 distinct forms on MultiIdentifierLoadAccess:
> >       1. Plural form of #getReference (current behavior, more or less)
> >       2. Plural form of #load
> >    3. Expose 3 distinct forms on MultiIdentifierLoadAccess:
> >       1. Plural form of #getReference
> >       2. Plural form of #load
> >       3. "Hybrid" form
>
> Regarding locally deleted entities, I understand the underlying logic
> but as a user I think I'd be surprised for it to return them.
> Is there a good use case to return these?
>

I think its just more efficient in many cases.  Meaning, in some cases
filtering out the deleted ones would mean a performance overhead mainly
because we'd have to ascertain whether they are deleted or not.  Which
means going to check the related EntityEntry, which has an overhead going
the reference to via creation of an EntityKey and then the
"EntityEntryContext lookup".  So I think in the case of #getReference
(allow proxy creation) it might be more of a significant overhead .

If we go with the proposed "2 distinct forms" approach, the current
behavior would align with "plural form of #getReference (current behavior,
more or less)".  We'd just offer another solution that aligns with "plural
form of #load".  However, see the caveat wrt nulls as discussed below...


> Much of the discussion on HHH-10984 revolves around the (poorly based,
> imo)
> > assumption that because a List/array of ids is passed in and because a
> List
> > is returned that we ought to return the results in the order indicated by
> > the incoming List/array of ids.
>
> As discussed on chat, in lack of any explicit documentation I also
> would have expected the order to be preserved, but stating otherwise
> in javadoc seems good enough to me.
>
> +1 to change the parameter type from List to Collection as you
> suggested; the return should also be changed from List so to not
> suggest any ordering guarantee but since that's breaking we'll do it
> later.
>
> > While I do not agree with the assumption there, I can see that that
> > behavior might sometimes be beneficial.  Is this something we want to
> > support?  There is certainly a performance overhead, and so I think we
> > definitely do not want to support it by default.  But do we want to
> expose
> > an option to allow users to request this?
>
> Yes I think there would be performance benefits to allow the consumer
> to push the sorting guarantee to ORM:
> in worst case, ORM will do it in the same inefficient way that the
> consumer would need to, but there might be cases in which ORM can do
> something smarter.
>
> In Hibernate Search we have two different situations in which we'd
> load by "byMultipleIds";
> in one case we'll need strict sorting, in the other we actually don't
> care at all for the order.. so yes we'd benefit from an option.
>
> Considering that the current API takes a List as parameter, and
> returns a List, and that we seem to agree that there's value in
> maintaining ordering.. maybe we should keep this API as is and make it
> always ordered?
> One could add the variation based on Collections as the alternative
> API to use when ordering is not needed, by adding it as a new API we'd
> not be breaking anything and still providing both options.
>

I'd instead opt then to keep the current API taking and returning Lists,
but with a sorting option (#enabledOrderedResults) that controls whether we
sort or not.

Keep in mind too that this Jira also then asserts (and I'd have to agree
with, if we accept ordering) that nulls should be pushed into the resulting
List at the correct spot.  So the List consumer would have to handle for
null elements, which would be a change in behavior as well.  Sanne - could
Search, as the List consumer, deal with null elements?

That is why I would allow to control this via the switch.  I could agree
either way about the default here.

From sanne at hibernate.org  Mon Jul 25 16:01:07 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 25 Jul 2016 21:01:07 +0100
Subject: [hibernate-dev] multiLoad support
In-Reply-To: <CAFdSV9u-iUqoNUuMZHZp+yg4vcWbBpDVEe6Woiz16ZeVxUfu1A@mail.gmail.com>
References: <CAFdSV9sTJvRmzbVK1R8W7wZBoTJwLCgixC6F4QHzMtQtVdv0Ow@mail.gmail.com>
	<CAFm4XO1Bkb0iZFqT-vvwDQx=d6o2YDPT1DARg+brLBFw_5Oy5w@mail.gmail.com>
	<CAFdSV9u-iUqoNUuMZHZp+yg4vcWbBpDVEe6Woiz16ZeVxUfu1A@mail.gmail.com>
Message-ID: <CAFm4XO3pXzuyig5sq0jQ8yJhXkHm6yTEEtnxBZ5Z_YO0ZmZRJA@mail.gmail.com>

On 25 July 2016 at 19:55, Steve Ebersole <steve at hibernate.org> wrote:
> See inline...
>
>
> On Mon, Jul 25, 2016 at 1:06 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> some comments inline:
>>
>> On 25 July 2016 at 18:27, Steve Ebersole <steve at hibernate.org> wrote:
>> > I wanted to start a consolidated discussion about multi-load support.
>> > This
>> > relates to a few Jiras, questioning a few different aspects of its
>> > current
>> > behavior:
>> >
>> > https://hibernate.atlassian.net/browse/HHH-10984
>> > https://hibernate.atlassian.net/browse/HHH-10617
>> >
>> > Basically this comes down to the following questions/requests...
>> >
>> >
>> > ## Handling locally deleted entities
>> >
>> > First (from HHH-10984) is the idea that locally deleted entities are
>> > currently returned from multi-load calls.  The background here is that
>> > multi-load support was designed based on
>> > IdentifierLoadAccess#getReference
>> > (Session#load).  So its outcome follows what is done for #getReference
>> > in
>> > terms of behavior and results.  Now one of the behaviors of
>> > #getReference
>> > that differs from IdentifierLoadAccess#load (Session#get) is how locally
>> > deleted entities are treated: #getReference will return them, whereas
>> > #load
>> > will not.
>> >
>> > So as I see it we have 3 options:
>> >
>> >    1. Continue to expose just the one form on MultiIdentifierLoadAccess
>> > and
>> >    either have this filter out the locally deleted objects, or add a new
>> >    option to specify whether locally deleted objects ought to be
>> > returned in
>> >    the results.
>> >    2. Expose 2 distinct forms on MultiIdentifierLoadAccess:
>> >       1. Plural form of #getReference (current behavior, more or less)
>> >       2. Plural form of #load
>> >    3. Expose 3 distinct forms on MultiIdentifierLoadAccess:
>> >       1. Plural form of #getReference
>> >       2. Plural form of #load
>> >       3. "Hybrid" form
>>
>> Regarding locally deleted entities, I understand the underlying logic
>> but as a user I think I'd be surprised for it to return them.
>> Is there a good use case to return these?
>
>
> I think its just more efficient in many cases.  Meaning, in some cases
> filtering out the deleted ones would mean a performance overhead mainly
> because we'd have to ascertain whether they are deleted or not.  Which means
> going to check the related EntityEntry, which has an overhead going the
> reference to via creation of an EntityKey and then the "EntityEntryContext
> lookup".  So I think in the case of #getReference (allow proxy creation) it
> might be more of a significant overhead .
>
> If we go with the proposed "2 distinct forms" approach, the current behavior
> would align with "plural form of #getReference (current behavior, more or
> less)".  We'd just offer another solution that aligns with "plural form of
> #load".  However, see the caveat wrt nulls as discussed below...
>
>
>> > Much of the discussion on HHH-10984 revolves around the (poorly based,
>> > imo)
>> > assumption that because a List/array of ids is passed in and because a
>> > List
>> > is returned that we ought to return the results in the order indicated
>> > by
>> > the incoming List/array of ids.
>>
>> As discussed on chat, in lack of any explicit documentation I also
>> would have expected the order to be preserved, but stating otherwise
>> in javadoc seems good enough to me.
>>
>> +1 to change the parameter type from List to Collection as you
>> suggested; the return should also be changed from List so to not
>> suggest any ordering guarantee but since that's breaking we'll do it
>> later.
>>
>> > While I do not agree with the assumption there, I can see that that
>> > behavior might sometimes be beneficial.  Is this something we want to
>> > support?  There is certainly a performance overhead, and so I think we
>> > definitely do not want to support it by default.  But do we want to
>> > expose
>> > an option to allow users to request this?
>>
>> Yes I think there would be performance benefits to allow the consumer
>> to push the sorting guarantee to ORM:
>> in worst case, ORM will do it in the same inefficient way that the
>> consumer would need to, but there might be cases in which ORM can do
>> something smarter.
>>
>> In Hibernate Search we have two different situations in which we'd
>> load by "byMultipleIds";
>> in one case we'll need strict sorting, in the other we actually don't
>> care at all for the order.. so yes we'd benefit from an option.
>>
>> Considering that the current API takes a List as parameter, and
>> returns a List, and that we seem to agree that there's value in
>> maintaining ordering.. maybe we should keep this API as is and make it
>> always ordered?
>> One could add the variation based on Collections as the alternative
>> API to use when ordering is not needed, by adding it as a new API we'd
>> not be breaking anything and still providing both options.
>
>
> I'd instead opt then to keep the current API taking and returning Lists, but
> with a sorting option (#enabledOrderedResults) that controls whether we sort
> or not.
>
> Keep in mind too that this Jira also then asserts (and I'd have to agree
> with, if we accept ordering) that nulls should be pushed into the resulting
> List at the correct spot.  So the List consumer would have to handle for
> null elements, which would be a change in behavior as well.  Sanne - could
> Search, as the List consumer, deal with null elements?

Yes, not a problem.

>
> That is why I would allow to control this via the switch.  I could agree
> either way about the default here.

From guillaume.smet at gmail.com  Tue Jul 26 05:20:40 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 26 Jul 2016 11:20:40 +0200
Subject: [hibernate-dev] [OGM] Mapping of embedded
In-Reply-To: <20160725121048.GN11493@hibernate.org>
References: <CALt0+o9xuwqS+ZxkYFVxJ9Vdh1xXimS1ouHnmRUpybdR=sWvwQ@mail.gmail.com>
	<CALt0+o83WZj29NCw-HTyaNAdTyU1tjsrRmaitZnLeRU9DkGW+A@mail.gmail.com>
	<0057EDA1-0F24-4234-A4B8-6EB4F2CA8703@gmail.com>
	<20160725121048.GN11493@hibernate.org>
Message-ID: <CALt0+o9-UbUxGVb8m4Vt+4nDaKS5cK7DumeASh2z=tM=PU-UvQ@mail.gmail.com>

On Mon, Jul 25, 2016 at 2:10 PM, Emmanuel Bernard
<emmanuel at hibernate.org> wrote:
> I am having second thoughts on the collection case. When I look at ORM's
> test suite and AttributeOverrideTest + PropertyRecord, the property name
> is not including the owning property (addresses in this case).
>
>         @AttributeOverrides({
>                         @AttributeOverride(name = "size", column = @Column(name = "SQUARE_FEET")),
>                         @AttributeOverride(name = "tax", column = @Column(name = "ASSESSMENT"))
>                                         })
>         @ElementCollection
>         public Set<PropertyInfo> unsortedParcels;
>
> So we probably should not need to put "addresses" in the @Column for the collection cases. It makes sense from an ORM PoV since we are talking about different tables.

OK, so this means our current implementation is correct and we just
need to wait for 5.1.1 before merging pr/728.

-- 
Guillaume

From emmanuel at hibernate.org  Tue Jul 26 08:15:46 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 26 Jul 2016 14:15:46 +0200
Subject: [hibernate-dev] HSEARCH-1872 Sort API preliminary evaluation
In-Reply-To: <20160721162450.GG75699@hibernate.org>
References: <20160721123942.GF75699@hibernate.org>
	<20160721162450.GG75699@hibernate.org>
Message-ID: <20160726121546.GI30609@hibernate.org>

I made more progress with the full interfaces for the DSL
https://github.com/hibernate/hibernate-search/pull/1132

You can play with it in your IDE, runtime won't work.

I've also added questions on the issue itself.

On Thu 2016-07-21 18:24, Emmanuel Bernard wrote:
> I came up with something quite natural to our DSL. WDYT?
> 
> https://hibernate.atlassian.net/browse/HSEARCH-1872?focusedCommentId=81543&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-81543
> 
> On Thu 2016-07-21 14:39, Emmanuel Bernard wrote:
> > Before I go and play with an actual API, can anyone interesting comment
> > on https://hibernate.atlassian.net/browse/HSEARCH-1872
> > 
> > Both on what we want to support and what we are fine not to support?
> > 
> > Emmanuel
> > 
> > PS: I suppose a total integration within the DSL is a different story that
> > we will tackle separately.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Tue Jul 26 10:06:52 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 26 Jul 2016 15:06:52 +0100
Subject: [hibernate-dev] HSEARCH-1872 Sort API preliminary evaluation
In-Reply-To: <20160726121546.GI30609@hibernate.org>
References: <20160721123942.GF75699@hibernate.org>
	<20160721162450.GG75699@hibernate.org>
	<20160726121546.GI30609@hibernate.org>
Message-ID: <CAFm4XO219Xd7rKs7HdfNW8_M7eKfwWtoOyS-E+Yt2C9VnATKYA@mail.gmail.com>

Thanks, that's very helpful! Starting to play now.

On 26 July 2016 at 13:15, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> I made more progress with the full interfaces for the DSL
> https://github.com/hibernate/hibernate-search/pull/1132
>
> You can play with it in your IDE, runtime won't work.
>
> I've also added questions on the issue itself.
>
> On Thu 2016-07-21 18:24, Emmanuel Bernard wrote:
>> I came up with something quite natural to our DSL. WDYT?
>>
>> https://hibernate.atlassian.net/browse/HSEARCH-1872?focusedCommentId=81543&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-81543
>>
>> On Thu 2016-07-21 14:39, Emmanuel Bernard wrote:
>> > Before I go and play with an actual API, can anyone interesting comment
>> > on https://hibernate.atlassian.net/browse/HSEARCH-1872
>> >
>> > Both on what we want to support and what we are fine not to support?
>> >
>> > Emmanuel
>> >
>> > PS: I suppose a total integration within the DSL is a different story that
>> > we will tackle separately.
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Tue Jul 26 11:44:42 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 26 Jul 2016 15:44:42 +0000
Subject: [hibernate-dev] multiLoad support
In-Reply-To: <CAFm4XO3pXzuyig5sq0jQ8yJhXkHm6yTEEtnxBZ5Z_YO0ZmZRJA@mail.gmail.com>
References: <CAFdSV9sTJvRmzbVK1R8W7wZBoTJwLCgixC6F4QHzMtQtVdv0Ow@mail.gmail.com>
	<CAFm4XO1Bkb0iZFqT-vvwDQx=d6o2YDPT1DARg+brLBFw_5Oy5w@mail.gmail.com>
	<CAFdSV9u-iUqoNUuMZHZp+yg4vcWbBpDVEe6Woiz16ZeVxUfu1A@mail.gmail.com>
	<CAFm4XO3pXzuyig5sq0jQ8yJhXkHm6yTEEtnxBZ5Z_YO0ZmZRJA@mail.gmail.com>
Message-ID: <CAFdSV9vP67VUGo229TY1zeJR7nzMc4MJr_b6cjA2vChGMoD=GA@mail.gmail.com>

So what I ended up doing is:

   1. Add new MultiIdentifierLoadAccess#enableReturnOfDeletedEntities
   option (default == false)
   2. Add new MultiIdentifierLoadAccess#enableOrderedReturn option (default
   == true)
   3. Added Javadoc clarification to MultiIdentifierLoadAccess#multiLoad to
   see the Javadocs for the above 2 options.

I am not super stoked about the way the ordering happens, at the moment.
For now I essentially:

   1. Perform X number of batch loads
   2. After all the batch loads, come back and build the result List based
   on the incoming id positions.

I did it this way to also handle de-duplication which is a related,
reported bug.

On Mon, Jul 25, 2016 at 3:01 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 25 July 2016 at 19:55, Steve Ebersole <steve at hibernate.org> wrote:
> > See inline...
> >
> >
> > On Mon, Jul 25, 2016 at 1:06 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> some comments inline:
> >>
> >> On 25 July 2016 at 18:27, Steve Ebersole <steve at hibernate.org> wrote:
> >> > I wanted to start a consolidated discussion about multi-load support.
> >> > This
> >> > relates to a few Jiras, questioning a few different aspects of its
> >> > current
> >> > behavior:
> >> >
> >> > https://hibernate.atlassian.net/browse/HHH-10984
> >> > https://hibernate.atlassian.net/browse/HHH-10617
> >> >
> >> > Basically this comes down to the following questions/requests...
> >> >
> >> >
> >> > ## Handling locally deleted entities
> >> >
> >> > First (from HHH-10984) is the idea that locally deleted entities are
> >> > currently returned from multi-load calls.  The background here is that
> >> > multi-load support was designed based on
> >> > IdentifierLoadAccess#getReference
> >> > (Session#load).  So its outcome follows what is done for #getReference
> >> > in
> >> > terms of behavior and results.  Now one of the behaviors of
> >> > #getReference
> >> > that differs from IdentifierLoadAccess#load (Session#get) is how
> locally
> >> > deleted entities are treated: #getReference will return them, whereas
> >> > #load
> >> > will not.
> >> >
> >> > So as I see it we have 3 options:
> >> >
> >> >    1. Continue to expose just the one form on
> MultiIdentifierLoadAccess
> >> > and
> >> >    either have this filter out the locally deleted objects, or add a
> new
> >> >    option to specify whether locally deleted objects ought to be
> >> > returned in
> >> >    the results.
> >> >    2. Expose 2 distinct forms on MultiIdentifierLoadAccess:
> >> >       1. Plural form of #getReference (current behavior, more or less)
> >> >       2. Plural form of #load
> >> >    3. Expose 3 distinct forms on MultiIdentifierLoadAccess:
> >> >       1. Plural form of #getReference
> >> >       2. Plural form of #load
> >> >       3. "Hybrid" form
> >>
> >> Regarding locally deleted entities, I understand the underlying logic
> >> but as a user I think I'd be surprised for it to return them.
> >> Is there a good use case to return these?
> >
> >
> > I think its just more efficient in many cases.  Meaning, in some cases
> > filtering out the deleted ones would mean a performance overhead mainly
> > because we'd have to ascertain whether they are deleted or not.  Which
> means
> > going to check the related EntityEntry, which has an overhead going the
> > reference to via creation of an EntityKey and then the
> "EntityEntryContext
> > lookup".  So I think in the case of #getReference (allow proxy creation)
> it
> > might be more of a significant overhead .
> >
> > If we go with the proposed "2 distinct forms" approach, the current
> behavior
> > would align with "plural form of #getReference (current behavior, more or
> > less)".  We'd just offer another solution that aligns with "plural form
> of
> > #load".  However, see the caveat wrt nulls as discussed below...
> >
> >
> >> > Much of the discussion on HHH-10984 revolves around the (poorly based,
> >> > imo)
> >> > assumption that because a List/array of ids is passed in and because a
> >> > List
> >> > is returned that we ought to return the results in the order indicated
> >> > by
> >> > the incoming List/array of ids.
> >>
> >> As discussed on chat, in lack of any explicit documentation I also
> >> would have expected the order to be preserved, but stating otherwise
> >> in javadoc seems good enough to me.
> >>
> >> +1 to change the parameter type from List to Collection as you
> >> suggested; the return should also be changed from List so to not
> >> suggest any ordering guarantee but since that's breaking we'll do it
> >> later.
> >>
> >> > While I do not agree with the assumption there, I can see that that
> >> > behavior might sometimes be beneficial.  Is this something we want to
> >> > support?  There is certainly a performance overhead, and so I think we
> >> > definitely do not want to support it by default.  But do we want to
> >> > expose
> >> > an option to allow users to request this?
> >>
> >> Yes I think there would be performance benefits to allow the consumer
> >> to push the sorting guarantee to ORM:
> >> in worst case, ORM will do it in the same inefficient way that the
> >> consumer would need to, but there might be cases in which ORM can do
> >> something smarter.
> >>
> >> In Hibernate Search we have two different situations in which we'd
> >> load by "byMultipleIds";
> >> in one case we'll need strict sorting, in the other we actually don't
> >> care at all for the order.. so yes we'd benefit from an option.
> >>
> >> Considering that the current API takes a List as parameter, and
> >> returns a List, and that we seem to agree that there's value in
> >> maintaining ordering.. maybe we should keep this API as is and make it
> >> always ordered?
> >> One could add the variation based on Collections as the alternative
> >> API to use when ordering is not needed, by adding it as a new API we'd
> >> not be breaking anything and still providing both options.
> >
> >
> > I'd instead opt then to keep the current API taking and returning Lists,
> but
> > with a sorting option (#enabledOrderedResults) that controls whether we
> sort
> > or not.
> >
> > Keep in mind too that this Jira also then asserts (and I'd have to agree
> > with, if we accept ordering) that nulls should be pushed into the
> resulting
> > List at the correct spot.  So the List consumer would have to handle for
> > null elements, which would be a change in behavior as well.  Sanne -
> could
> > Search, as the List consumer, deal with null elements?
>
> Yes, not a problem.
>
> >
> > That is why I would allow to control this via the switch.  I could agree
> > either way about the default here.
>

From sanne at hibernate.org  Tue Jul 26 11:53:45 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 26 Jul 2016 16:53:45 +0100
Subject: [hibernate-dev] multiLoad support
In-Reply-To: <CAFdSV9vP67VUGo229TY1zeJR7nzMc4MJr_b6cjA2vChGMoD=GA@mail.gmail.com>
References: <CAFdSV9sTJvRmzbVK1R8W7wZBoTJwLCgixC6F4QHzMtQtVdv0Ow@mail.gmail.com>
	<CAFm4XO1Bkb0iZFqT-vvwDQx=d6o2YDPT1DARg+brLBFw_5Oy5w@mail.gmail.com>
	<CAFdSV9u-iUqoNUuMZHZp+yg4vcWbBpDVEe6Woiz16ZeVxUfu1A@mail.gmail.com>
	<CAFm4XO3pXzuyig5sq0jQ8yJhXkHm6yTEEtnxBZ5Z_YO0ZmZRJA@mail.gmail.com>
	<CAFdSV9vP67VUGo229TY1zeJR7nzMc4MJr_b6cjA2vChGMoD=GA@mail.gmail.com>
Message-ID: <CAFm4XO2C8ctsaK5Lc_Z_nDfazGwdh5c4jNt8q6u41NArrVdwEQ@mail.gmail.com>

On 26 July 2016 at 16:44, Steve Ebersole <steve at hibernate.org> wrote:
> So what I ended up doing is:
>
> Add new MultiIdentifierLoadAccess#enableReturnOfDeletedEntities option
> (default == false)
> Add new MultiIdentifierLoadAccess#enableOrderedReturn option (default ==
> true)
> Added Javadoc clarification to MultiIdentifierLoadAccess#multiLoad to see
> the Javadocs for the above 2 options.

Thanks Steve, looks good!
So since you now have an option in which order might matter, I guess
you won't change the argument type from List to Collection?

> I am not super stoked about the way the ordering happens, at the moment.
> For now I essentially:
>
> Perform X number of batch loads
> After all the batch loads, come back and build the result List based on the
> incoming id positions.
>
> I did it this way to also handle de-duplication which is a related, reported
> bug.

Fair enough, it has to work clearly and correctly first. People will
have to come back on this if they have concrete data on how it
performs, that's usually a better approach than trying to predict or
make it unnecessarily complex.

-- Sanne

>
> On Mon, Jul 25, 2016 at 3:01 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> On 25 July 2016 at 19:55, Steve Ebersole <steve at hibernate.org> wrote:
>> > See inline...
>> >
>> >
>> > On Mon, Jul 25, 2016 at 1:06 PM Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >>
>> >> some comments inline:
>> >>
>> >> On 25 July 2016 at 18:27, Steve Ebersole <steve at hibernate.org> wrote:
>> >> > I wanted to start a consolidated discussion about multi-load support.
>> >> > This
>> >> > relates to a few Jiras, questioning a few different aspects of its
>> >> > current
>> >> > behavior:
>> >> >
>> >> > https://hibernate.atlassian.net/browse/HHH-10984
>> >> > https://hibernate.atlassian.net/browse/HHH-10617
>> >> >
>> >> > Basically this comes down to the following questions/requests...
>> >> >
>> >> >
>> >> > ## Handling locally deleted entities
>> >> >
>> >> > First (from HHH-10984) is the idea that locally deleted entities are
>> >> > currently returned from multi-load calls.  The background here is
>> >> > that
>> >> > multi-load support was designed based on
>> >> > IdentifierLoadAccess#getReference
>> >> > (Session#load).  So its outcome follows what is done for
>> >> > #getReference
>> >> > in
>> >> > terms of behavior and results.  Now one of the behaviors of
>> >> > #getReference
>> >> > that differs from IdentifierLoadAccess#load (Session#get) is how
>> >> > locally
>> >> > deleted entities are treated: #getReference will return them, whereas
>> >> > #load
>> >> > will not.
>> >> >
>> >> > So as I see it we have 3 options:
>> >> >
>> >> >    1. Continue to expose just the one form on
>> >> > MultiIdentifierLoadAccess
>> >> > and
>> >> >    either have this filter out the locally deleted objects, or add a
>> >> > new
>> >> >    option to specify whether locally deleted objects ought to be
>> >> > returned in
>> >> >    the results.
>> >> >    2. Expose 2 distinct forms on MultiIdentifierLoadAccess:
>> >> >       1. Plural form of #getReference (current behavior, more or
>> >> > less)
>> >> >       2. Plural form of #load
>> >> >    3. Expose 3 distinct forms on MultiIdentifierLoadAccess:
>> >> >       1. Plural form of #getReference
>> >> >       2. Plural form of #load
>> >> >       3. "Hybrid" form
>> >>
>> >> Regarding locally deleted entities, I understand the underlying logic
>> >> but as a user I think I'd be surprised for it to return them.
>> >> Is there a good use case to return these?
>> >
>> >
>> > I think its just more efficient in many cases.  Meaning, in some cases
>> > filtering out the deleted ones would mean a performance overhead mainly
>> > because we'd have to ascertain whether they are deleted or not.  Which
>> > means
>> > going to check the related EntityEntry, which has an overhead going the
>> > reference to via creation of an EntityKey and then the
>> > "EntityEntryContext
>> > lookup".  So I think in the case of #getReference (allow proxy creation)
>> > it
>> > might be more of a significant overhead .
>> >
>> > If we go with the proposed "2 distinct forms" approach, the current
>> > behavior
>> > would align with "plural form of #getReference (current behavior, more
>> > or
>> > less)".  We'd just offer another solution that aligns with "plural form
>> > of
>> > #load".  However, see the caveat wrt nulls as discussed below...
>> >
>> >
>> >> > Much of the discussion on HHH-10984 revolves around the (poorly
>> >> > based,
>> >> > imo)
>> >> > assumption that because a List/array of ids is passed in and because
>> >> > a
>> >> > List
>> >> > is returned that we ought to return the results in the order
>> >> > indicated
>> >> > by
>> >> > the incoming List/array of ids.
>> >>
>> >> As discussed on chat, in lack of any explicit documentation I also
>> >> would have expected the order to be preserved, but stating otherwise
>> >> in javadoc seems good enough to me.
>> >>
>> >> +1 to change the parameter type from List to Collection as you
>> >> suggested; the return should also be changed from List so to not
>> >> suggest any ordering guarantee but since that's breaking we'll do it
>> >> later.
>> >>
>> >> > While I do not agree with the assumption there, I can see that that
>> >> > behavior might sometimes be beneficial.  Is this something we want to
>> >> > support?  There is certainly a performance overhead, and so I think
>> >> > we
>> >> > definitely do not want to support it by default.  But do we want to
>> >> > expose
>> >> > an option to allow users to request this?
>> >>
>> >> Yes I think there would be performance benefits to allow the consumer
>> >> to push the sorting guarantee to ORM:
>> >> in worst case, ORM will do it in the same inefficient way that the
>> >> consumer would need to, but there might be cases in which ORM can do
>> >> something smarter.
>> >>
>> >> In Hibernate Search we have two different situations in which we'd
>> >> load by "byMultipleIds";
>> >> in one case we'll need strict sorting, in the other we actually don't
>> >> care at all for the order.. so yes we'd benefit from an option.
>> >>
>> >> Considering that the current API takes a List as parameter, and
>> >> returns a List, and that we seem to agree that there's value in
>> >> maintaining ordering.. maybe we should keep this API as is and make it
>> >> always ordered?
>> >> One could add the variation based on Collections as the alternative
>> >> API to use when ordering is not needed, by adding it as a new API we'd
>> >> not be breaking anything and still providing both options.
>> >
>> >
>> > I'd instead opt then to keep the current API taking and returning Lists,
>> > but
>> > with a sorting option (#enabledOrderedResults) that controls whether we
>> > sort
>> > or not.
>> >
>> > Keep in mind too that this Jira also then asserts (and I'd have to agree
>> > with, if we accept ordering) that nulls should be pushed into the
>> > resulting
>> > List at the correct spot.  So the List consumer would have to handle for
>> > null elements, which would be a change in behavior as well.  Sanne -
>> > could
>> > Search, as the List consumer, deal with null elements?
>>
>> Yes, not a problem.
>>
>> >
>> > That is why I would allow to control this via the switch.  I could agree
>> > either way about the default here.

From sanne at hibernate.org  Tue Jul 26 14:03:24 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 26 Jul 2016 19:03:24 +0100
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <20160722163333.GI11493@hibernate.org>
References: <CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>
	<CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
	<20160721120706.GD75699@hibernate.org>
	<CALt0+o-kHeeK2sb64gx0_WHBQwJjTRy47RJxh=tz8KnUTRodDg@mail.gmail.com>
	<20160721123809.GE75699@hibernate.org>
	<CALt0+o8+-9-9rpRwEPduB_=s6SePGdgDJRHTBJcdsa8wX_Wx5w@mail.gmail.com>
	<CANoTJYMbkJa_0GZoZEmwsp5AQEq-vnTu_yKV8LgrbMrQzYzU4g@mail.gmail.com>
	<CAFm4XO3_wC2TDwX6rqC4+yQmKS-VcWjg0e_ad=z52z3JbsYfyQ@mail.gmail.com>
	<CALt0+o-xq0at6C7pTeNnyQLTycjmE+v5Z5a4XQxDx8dC0pd8MQ@mail.gmail.com>
	<CANoTJYNa4=9wv5zJf5o77J3Yg7Yb4G_qwsHB8pZmhrXL81V87w@mail.gmail.com>
	<20160722163333.GI11493@hibernate.org>
Message-ID: <CAFm4XO1P_swsXT0JpNzLnFQu7rcXyhHTDs+YAZZJsQnbXwz3fA@mail.gmail.com>

The SEO expert liked the results :)

On 22 July 2016 at 17:33, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> Hibernate is fine.
>
> On Fri 2016-07-22 16:57, Davide D'Alto wrote:
>> I've updated the microdata on our blog.
>> I  used the google validation page to check the result:
>> https://search.google.com/structured-data/testing-tool/u/0/?hl=EN#url=http%3A%2F%2Fin.relation.to%2F
>>
>> I'm not familiar with microdata, if you think that something is wrong
>> let me know.
>>
>> I have a question about the organization, should I put Red Hat or Hibernate?
>> At the moment I'm using Hibernate and hibernate.org as organizarion
>> url, but let me know.
>>
>> Cheers,
>> Davide
>>
>> On Thu, Jul 21, 2016 at 11:26 PM, Guillaume Smet
>> <guillaume.smet at gmail.com> wrote:
>> > On Thu, Jul 21, 2016 at 3:06 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>> >> Maybe we could move that to the website, as similar metadata is
>> >> already being deployed, e.g.
>> >>  - https://github.com/hibernate/hibernate.org/tree/staging/_data/projects/search/releases
>> >
>> > We already need to update the /stable/ symlink on the doc server so we
>> > might as well do it when we push the doc.
>> >
>> > I got something like this:
>> > https://gist.github.com/gsmet/8c8e29c46337f69bfbc9e84f108d951f . I'll
>> > push a PR tomorrow.
>> >
>> > I pushed the JS and the metadata to all known doc versions of Search and OGM.
>> >
>> > --
>> > Guillaume
>> > _______________________________________________
>> > 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 daltodavide at gmail.com  Wed Jul 27 02:56:38 2016
From: daltodavide at gmail.com (Davide D'Alto)
Date: Wed, 27 Jul 2016 07:56:38 +0100
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <CAFm4XO1P_swsXT0JpNzLnFQu7rcXyhHTDs+YAZZJsQnbXwz3fA@mail.gmail.com>
References: <CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>
	<CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
	<20160721120706.GD75699@hibernate.org>
	<CALt0+o-kHeeK2sb64gx0_WHBQwJjTRy47RJxh=tz8KnUTRodDg@mail.gmail.com>
	<20160721123809.GE75699@hibernate.org>
	<CALt0+o8+-9-9rpRwEPduB_=s6SePGdgDJRHTBJcdsa8wX_Wx5w@mail.gmail.com>
	<CANoTJYMbkJa_0GZoZEmwsp5AQEq-vnTu_yKV8LgrbMrQzYzU4g@mail.gmail.com>
	<CAFm4XO3_wC2TDwX6rqC4+yQmKS-VcWjg0e_ad=z52z3JbsYfyQ@mail.gmail.com>
	<CALt0+o-xq0at6C7pTeNnyQLTycjmE+v5Z5a4XQxDx8dC0pd8MQ@mail.gmail.com>
	<CANoTJYNa4=9wv5zJf5o77J3Yg7Yb4G_qwsHB8pZmhrXL81V87w@mail.gmail.com>
	<20160722163333.GI11493@hibernate.org>
	<CAFm4XO1P_swsXT0JpNzLnFQu7rcXyhHTDs+YAZZJsQnbXwz3fA@mail.gmail.com>
Message-ID: <CANoTJYPJoVfbiGuKAVvp6Rd332sX4+33EPXDd-Hkd5zsxvZd2w@mail.gmail.com>

Great :)

now I need to do the same with hibernate.org.


On Tue, Jul 26, 2016 at 7:03 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> The SEO expert liked the results :)
>
> On 22 July 2016 at 17:33, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> Hibernate is fine.
>>
>> On Fri 2016-07-22 16:57, Davide D'Alto wrote:
>>> I've updated the microdata on our blog.
>>> I  used the google validation page to check the result:
>>> https://search.google.com/structured-data/testing-tool/u/0/?hl=EN#url=http%3A%2F%2Fin.relation.to%2F
>>>
>>> I'm not familiar with microdata, if you think that something is wrong
>>> let me know.
>>>
>>> I have a question about the organization, should I put Red Hat or Hibernate?
>>> At the moment I'm using Hibernate and hibernate.org as organizarion
>>> url, but let me know.
>>>
>>> Cheers,
>>> Davide
>>>
>>> On Thu, Jul 21, 2016 at 11:26 PM, Guillaume Smet
>>> <guillaume.smet at gmail.com> wrote:
>>> > On Thu, Jul 21, 2016 at 3:06 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>>> >> Maybe we could move that to the website, as similar metadata is
>>> >> already being deployed, e.g.
>>> >>  - https://github.com/hibernate/hibernate.org/tree/staging/_data/projects/search/releases
>>> >
>>> > We already need to update the /stable/ symlink on the doc server so we
>>> > might as well do it when we push the doc.
>>> >
>>> > I got something like this:
>>> > https://gist.github.com/gsmet/8c8e29c46337f69bfbc9e84f108d951f . I'll
>>> > push a PR tomorrow.
>>> >
>>> > I pushed the JS and the metadata to all known doc versions of Search and OGM.
>>> >
>>> > --
>>> > Guillaume
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Wed Jul 27 03:09:05 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 27 Jul 2016 10:09:05 +0300
Subject: [hibernate-dev] People can't find our docs
In-Reply-To: <CANoTJYPJoVfbiGuKAVvp6Rd332sX4+33EPXDd-Hkd5zsxvZd2w@mail.gmail.com>
References: <CANoTJYPx_yv18bXiZX5h4m-nN5TGYqpcqPxtK9iaOM-6p_oemg@mail.gmail.com>
	<CALt0+o_fi4jBhSxe4gpF=usBvJ3KVJCtqJX+=PFRCr1HtvdgFQ@mail.gmail.com>
	<20160721120706.GD75699@hibernate.org>
	<CALt0+o-kHeeK2sb64gx0_WHBQwJjTRy47RJxh=tz8KnUTRodDg@mail.gmail.com>
	<20160721123809.GE75699@hibernate.org>
	<CALt0+o8+-9-9rpRwEPduB_=s6SePGdgDJRHTBJcdsa8wX_Wx5w@mail.gmail.com>
	<CANoTJYMbkJa_0GZoZEmwsp5AQEq-vnTu_yKV8LgrbMrQzYzU4g@mail.gmail.com>
	<CAFm4XO3_wC2TDwX6rqC4+yQmKS-VcWjg0e_ad=z52z3JbsYfyQ@mail.gmail.com>
	<CALt0+o-xq0at6C7pTeNnyQLTycjmE+v5Z5a4XQxDx8dC0pd8MQ@mail.gmail.com>
	<CANoTJYNa4=9wv5zJf5o77J3Yg7Yb4G_qwsHB8pZmhrXL81V87w@mail.gmail.com>
	<20160722163333.GI11493@hibernate.org>
	<CAFm4XO1P_swsXT0JpNzLnFQu7rcXyhHTDs+YAZZJsQnbXwz3fA@mail.gmail.com>
	<CANoTJYPJoVfbiGuKAVvp6Rd332sX4+33EPXDd-Hkd5zsxvZd2w@mail.gmail.com>
Message-ID: <CA+gWKMBiJigK2L6CPMzk51h0C6aMNQ1tXDoWH9mmogcXdGn1_g@mail.gmail.com>

Great news!

On Wed, Jul 27, 2016 at 9:56 AM, Davide D'Alto <daltodavide at gmail.com>
wrote:

> Great :)
>
> now I need to do the same with hibernate.org.
>
>
> On Tue, Jul 26, 2016 at 7:03 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
> > The SEO expert liked the results :)
> >
> > On 22 July 2016 at 17:33, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >> Hibernate is fine.
> >>
> >> On Fri 2016-07-22 16:57, Davide D'Alto wrote:
> >>> I've updated the microdata on our blog.
> >>> I  used the google validation page to check the result:
> >>>
> https://search.google.com/structured-data/testing-tool/u/0/?hl=EN#url=http%3A%2F%2Fin.relation.to%2F
> >>>
> >>> I'm not familiar with microdata, if you think that something is wrong
> >>> let me know.
> >>>
> >>> I have a question about the organization, should I put Red Hat or
> Hibernate?
> >>> At the moment I'm using Hibernate and hibernate.org as organizarion
> >>> url, but let me know.
> >>>
> >>> Cheers,
> >>> Davide
> >>>
> >>> On Thu, Jul 21, 2016 at 11:26 PM, Guillaume Smet
> >>> <guillaume.smet at gmail.com> wrote:
> >>> > On Thu, Jul 21, 2016 at 3:06 PM, Sanne Grinovero <
> sanne at hibernate.org> wrote:
> >>> >> Maybe we could move that to the website, as similar metadata is
> >>> >> already being deployed, e.g.
> >>> >>  -
> https://github.com/hibernate/hibernate.org/tree/staging/_data/projects/search/releases
> >>> >
> >>> > We already need to update the /stable/ symlink on the doc server so
> we
> >>> > might as well do it when we push the doc.
> >>> >
> >>> > I got something like this:
> >>> > https://gist.github.com/gsmet/8c8e29c46337f69bfbc9e84f108d951f .
> I'll
> >>> > push a PR tomorrow.
> >>> >
> >>> > I pushed the JS and the metadata to all known doc versions of Search
> and OGM.
> >>> >
> >>> > --
> >>> > Guillaume
> >>> > _______________________________________________
> >>> > hibernate-dev mailing list
> >>> > hibernate-dev at lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From flemming.harms at gmail.com  Wed Jul 27 12:55:29 2016
From: flemming.harms at gmail.com (Flemming Harms)
Date: Wed, 27 Jul 2016 18:55:29 +0200
Subject: [hibernate-dev] [OGM][HSEARCH] Hibernate OGM and Hibernate Search
	samples
Message-ID: <CAFP3+ynz6sVLc0ZaCHxwi=UViciRD9dm-KdQMBCyabyJwwAKQA@mail.gmail.com>

Folks,

Is there something similar to javaee7-samples for Hibernate OGM and HSEARCH
today? I know the Hibernate Demo repo exist, but from what I can read this
is demos you have created for various talk and presentations.

If not I would suggest a new repository is created with samples showing how
to use OGM, HSEARCH in various ways and configurations. The Hibernate Demo
repo could be a good starting point, but I?m thinking a new repo where we
divide into modules to make it easy to upgrade and maintain the samples
from a parent configuration file etc.

I personally learn much more from examples and then I can use the
documentation as reference point. And this will also be good reference
repository for testing against when releasing a new version.

I would like to contribute with various samples to help build the repository

What do you think?

/Flemming

From mark at lawinegevaar.nl  Thu Jul 28 05:54:11 2016
From: mark at lawinegevaar.nl (Mark Rotteveel)
Date: Thu, 28 Jul 2016 11:54:11 +0200
Subject: [hibernate-dev] SchemaCreatorImpl always creating a poolable
	sequence
Message-ID: <609731e9-dddc-afad-2f3d-ace9e15b3703@lawinegevaar.nl>

I'm working on improving support for Firebird in Hibernate, and I have 
run into a problem where 
org.hibernate.tool.schema.internal.SchemaCreatorImpl is always trying to 
create a pooled sequence.

Specifically:

applySqlStrings(
         dialect.getCreateSequenceStrings(
 
jdbcEnvironment.getQualifiedObjectNameFormatter().format( 
sequence.getName(), dialect ),
                 sequence.getInitialValue(),
                 sequence.getIncrementSize()
         ),
         formatter,
         options,
         targets
);

With the default implementation this results in a 
org.hibernate.MappingException: org.hibernate.dialect.FirebirdDialect 
does not support pooled sequences (or at least: not by specifying it in 
the DDL).

I'd like to know if I should just override
protected String getCreateSequenceString(String sequenceName, int 
initialValue, int incrementSize)

and ignore the initialValue and incrementSize and just return the result 
of getCreateSequenceString(sequenceName)

or if I should change the above code to call the deprecated(!) method 
getCreateSequenceStrings(String sequenceName) is 
supportsPooledSequences() is false:

dialect.supportsPooledSequences()
	? dialect.getCreateSequenceStrings(
 
jdbcEnvironment.getQualifiedObjectNameFormatter().format( 
sequence.getName(), dialect ),
                 sequence.getInitialValue(),
                 sequence.getIncrementSize()
         ) : dialect.getCreateSequenceStrings(
 
jdbcEnvironment.getQualifiedObjectNameFormatter().format( 
sequence.getName(), dialect )
         ),

Kind regards,
Mark Rotteveel
-- 
Mark Rotteveel

From mihalcea.vlad at gmail.com  Thu Jul 28 06:22:52 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 28 Jul 2016 13:22:52 +0300
Subject: [hibernate-dev] SchemaCreatorImpl always creating a poolable
	sequence
In-Reply-To: <609731e9-dddc-afad-2f3d-ace9e15b3703@lawinegevaar.nl>
References: <609731e9-dddc-afad-2f3d-ace9e15b3703@lawinegevaar.nl>
Message-ID: <CA+gWKMBs7qGshCvO8ft0f-soyWuC3U1i8K1bjveT_uv+_HsZUA@mail.gmail.com>

Hi Mark,

I've just run the PooledHiLoSequenceIdentifierTest test after modifying the
TABLE to SEQUENCE to see how it works and this is what I found:

1. SchemaCreatorImpl calls String[] getCreateSequenceStrings(String
sequenceName, int initialValue, int incrementSize)
2. The String getCreateSequenceString(String sequenceName, int initialValue,
int incrementSize) is then called which does this:

if ( supportsPooledSequences() ) {
   return getCreateSequenceString( sequenceName ) + " start with " +
initialValue + " increment by " + incrementSize;
}
throw new MappingException( getClass().getName() + " does not support
pooled sequences" );

Now, this method is overridden in PostgreSQL and HSQLDB dialects.

I think we should create the sequence generator as indicated in this
Firebird documentation:

http://firebirdsql.org/manual/generatorguide-sqlsyntax.html

Shouldn't we use GEN_ID for the pooled optimizers?

Vlad

On Thu, Jul 28, 2016 at 12:54 PM, Mark Rotteveel <mark at lawinegevaar.nl>
wrote:

> I'm working on improving support for Firebird in Hibernate, and I have
> run into a problem where
> org.hibernate.tool.schema.internal.SchemaCreatorImpl is always trying to
> create a pooled sequence.
>
> Specifically:
>
> applySqlStrings(
>          dialect.getCreateSequenceStrings(
>
> jdbcEnvironment.getQualifiedObjectNameFormatter().format(
> sequence.getName(), dialect ),
>                  sequence.getInitialValue(),
>                  sequence.getIncrementSize()
>          ),
>          formatter,
>          options,
>          targets
> );
>
> With the default implementation this results in a
> org.hibernate.MappingException: org.hibernate.dialect.FirebirdDialect
> does not support pooled sequences (or at least: not by specifying it in
> the DDL).
>
> I'd like to know if I should just override
> protected String getCreateSequenceString(String sequenceName, int
> initialValue, int incrementSize)
>
> and ignore the initialValue and incrementSize and just return the result
> of getCreateSequenceString(sequenceName)
>
> or if I should change the above code to call the deprecated(!) method
> getCreateSequenceStrings(String sequenceName) is
> supportsPooledSequences() is false:
>
> dialect.supportsPooledSequences()
>         ? dialect.getCreateSequenceStrings(
>
> jdbcEnvironment.getQualifiedObjectNameFormatter().format(
> sequence.getName(), dialect ),
>                  sequence.getInitialValue(),
>                  sequence.getIncrementSize()
>          ) : dialect.getCreateSequenceStrings(
>
> jdbcEnvironment.getQualifiedObjectNameFormatter().format(
> sequence.getName(), dialect )
>          ),
>
> Kind regards,
> Mark Rotteveel
> --
> Mark Rotteveel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mark at lawinegevaar.nl  Thu Jul 28 06:57:49 2016
From: mark at lawinegevaar.nl (Mark Rotteveel)
Date: Thu, 28 Jul 2016 12:57:49 +0200
Subject: [hibernate-dev] SchemaCreatorImpl always creating a poolable
 sequence
In-Reply-To: <CA+gWKMBs7qGshCvO8ft0f-soyWuC3U1i8K1bjveT_uv+_HsZUA@mail.gmail.com>
References: <609731e9-dddc-afad-2f3d-ace9e15b3703@lawinegevaar.nl>
	<CA+gWKMBs7qGshCvO8ft0f-soyWuC3U1i8K1bjveT_uv+_HsZUA@mail.gmail.com>
Message-ID: <3b153159-2170-a7e6-f8ed-fb7e250bbe3b@lawinegevaar.nl>

On 28-7-2016 12:22, Vlad Mihalcea wrote:
> Hi Mark,
>
> I've just run the PooledHiLoSequenceIdentifierTest test after modifying
> the TABLE to SEQUENCE to see how it works and this is what I found:
>
> 1. SchemaCreatorImpl calls String[] getCreateSequenceStrings(String
> sequenceName, int initialValue, int incrementSize)
> 2. The String getCreateSequenceString(String sequenceName, int
> initialValue, int incrementSize) is then called which does this:
>
> if ( supportsPooledSequences() ) {
>    return getCreateSequenceString( sequenceName ) + " start with " + initialValue + " increment by " + incrementSize;
> }
> throw new MappingException( getClass().getName() + " does not support pooled sequences" );

Yes, and the above exception is my problem, however this default 
implementation suggests that this method should only be called if pooled 
sequences are supported (quod non), but in the current code it is called 
always in org.hibernate.tool.schema.internal.SchemaCreatorImpl.

> Now, this method is overridden in PostgreSQL and HSQLDB dialects.

Yes, but both support pooled sequences.

> I think we should create the sequence generator as indicated in this
> Firebird documentation:
>
> http://firebirdsql.org/manual/generatorguide-sqlsyntax.html

The current dialect already does that, but it isn't working because of 
above code. Providing the following override does seem to work, but this 
seems at odds with the exception thrown in the default implementation.

@Override
protected String getCreateSequenceString(String sequenceName, int 
initialValue, int incrementSize) throws MappingException {
	// Ignore initialValue and incrementSize
	return getCreateSequenceString( sequenceName );
}

For Firebird 2.5, 
http://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-ddl-sequence.html 
is more up-to-date.

I'm currently creating a new Firebird 2.5 specific dialect, and then I'm 
going to add a Firebird 3.0 dialect.

I might clean up the old InterbaseDialect and FirebirdDialect, but I 
don't want to touch those too much (especially since Firebird and 
Interbase should now be considered two distinct databases).

> Shouldn't we use GEN_ID for the pooled optimizers?

Yes GEN_ID could be used for that, but as far as I can tell the current 
support for pooled sequences seems to require specifying the increment 
size in the sequence DDL, which is not supported by Firebird.

Is there a specific extension point to override this, is it the 
getDefaultMultiTableBulkIdStrategy()?

Mark
-- 
Mark Rotteveel

From mihalcea.vlad at gmail.com  Thu Jul 28 07:02:43 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 28 Jul 2016 14:02:43 +0300
Subject: [hibernate-dev] SchemaCreatorImpl always creating a poolable
	sequence
In-Reply-To: <3b153159-2170-a7e6-f8ed-fb7e250bbe3b@lawinegevaar.nl>
References: <609731e9-dddc-afad-2f3d-ace9e15b3703@lawinegevaar.nl>
	<CA+gWKMBs7qGshCvO8ft0f-soyWuC3U1i8K1bjveT_uv+_HsZUA@mail.gmail.com>
	<3b153159-2170-a7e6-f8ed-fb7e250bbe3b@lawinegevaar.nl>
Message-ID: <CA+gWKMBT7ZkLPL+1Ocyz4DzOVr8VS-mWhpKV+SffdsqpaHKx0w@mail.gmail.com>

Is it that you get the exception even if the incrementSize is 1? I guess
this is an issue that we need to open a Jira ticket for it.

On Thu, Jul 28, 2016 at 1:57 PM, Mark Rotteveel <mark at lawinegevaar.nl>
wrote:

> On 28-7-2016 12:22, Vlad Mihalcea wrote:
>
>> Hi Mark,
>>
>> I've just run the PooledHiLoSequenceIdentifierTest test after modifying
>> the TABLE to SEQUENCE to see how it works and this is what I found:
>>
>> 1. SchemaCreatorImpl calls String[] getCreateSequenceStrings(String
>> sequenceName, int initialValue, int incrementSize)
>> 2. The String getCreateSequenceString(String sequenceName, int
>> initialValue, int incrementSize) is then called which does this:
>>
>> if ( supportsPooledSequences() ) {
>>    return getCreateSequenceString( sequenceName ) + " start with " +
>> initialValue + " increment by " + incrementSize;
>> }
>> throw new MappingException( getClass().getName() + " does not support
>> pooled sequences" );
>>
>
> Yes, and the above exception is my problem, however this default
> implementation suggests that this method should only be called if pooled
> sequences are supported (quod non), but in the current code it is called
> always in org.hibernate.tool.schema.internal.SchemaCreatorImpl.
>
> Now, this method is overridden in PostgreSQL and HSQLDB dialects.
>>
>
> Yes, but both support pooled sequences.
>
> I think we should create the sequence generator as indicated in this
>> Firebird documentation:
>>
>> http://firebirdsql.org/manual/generatorguide-sqlsyntax.html
>>
>
> The current dialect already does that, but it isn't working because of
> above code. Providing the following override does seem to work, but this
> seems at odds with the exception thrown in the default implementation.
>
> @Override
> protected String getCreateSequenceString(String sequenceName, int
> initialValue, int incrementSize) throws MappingException {
>         // Ignore initialValue and incrementSize
>         return getCreateSequenceString( sequenceName );
> }
>
> For Firebird 2.5,
> http://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-ddl-sequence.html
> is more up-to-date.
>
> I'm currently creating a new Firebird 2.5 specific dialect, and then I'm
> going to add a Firebird 3.0 dialect.
>
> I might clean up the old InterbaseDialect and FirebirdDialect, but I don't
> want to touch those too much (especially since Firebird and Interbase
> should now be considered two distinct databases).
>
> Shouldn't we use GEN_ID for the pooled optimizers?
>>
>
> Yes GEN_ID could be used for that, but as far as I can tell the current
> support for pooled sequences seems to require specifying the increment size
> in the sequence DDL, which is not supported by Firebird.
>
> Is there a specific extension point to override this, is it the
> getDefaultMultiTableBulkIdStrategy()?
>
> Mark
> --
> Mark Rotteveel
>

From mark at lawinegevaar.nl  Thu Jul 28 07:12:29 2016
From: mark at lawinegevaar.nl (Mark Rotteveel)
Date: Thu, 28 Jul 2016 13:12:29 +0200
Subject: [hibernate-dev] SchemaCreatorImpl always creating a poolable
 sequence
In-Reply-To: <CA+gWKMBT7ZkLPL+1Ocyz4DzOVr8VS-mWhpKV+SffdsqpaHKx0w@mail.gmail.com>
References: <609731e9-dddc-afad-2f3d-ace9e15b3703@lawinegevaar.nl>
	<CA+gWKMBs7qGshCvO8ft0f-soyWuC3U1i8K1bjveT_uv+_HsZUA@mail.gmail.com>
	<3b153159-2170-a7e6-f8ed-fb7e250bbe3b@lawinegevaar.nl>
	<CA+gWKMBT7ZkLPL+1Ocyz4DzOVr8VS-mWhpKV+SffdsqpaHKx0w@mail.gmail.com>
Message-ID: <5f4b9733-b1e6-f569-52b7-a3c79028cfbc@lawinegevaar.nl>

On 28-7-2016 13:02, Vlad Mihalcea wrote:
> Is it that you get the exception even if the incrementSize is 1? I guess
> this is an issue that we need to open a Jira ticket for it.

Yes, see the code in my initial email: SchemaCreatorImpl always tries to 
create a pooled sequence.

Mark
-- 
Mark Rotteveel

From sanne at hibernate.org  Thu Jul 28 11:38:45 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 28 Jul 2016 16:38:45 +0100
Subject: [hibernate-dev] [OGM][HSEARCH] Hibernate OGM and Hibernate
	Search samples
In-Reply-To: <CAFP3+ynz6sVLc0ZaCHxwi=UViciRD9dm-KdQMBCyabyJwwAKQA@mail.gmail.com>
References: <CAFP3+ynz6sVLc0ZaCHxwi=UViciRD9dm-KdQMBCyabyJwwAKQA@mail.gmail.com>
Message-ID: <CAFm4XO1PJhxm07Q3VTbf=HLhMKPUR2O8Bm28uLPccBv=TRoF9Q@mail.gmail.com>

Hi Flemming,

I agree on the importance to have some runnable examples, but I'm
afraid that the "demos" repository wouldn't be kept up to date with
every single release.
Introducing more tasks to perform during a release is not desirable,
as the release process is quite complex already.

So I propose that such examples belong in the integration tests of the
projects; specifically, a JavaEE7 example using both Hibernate Search
and Hibernate OGM would need to be maintained by the OGM project (as
OGM depends on Search, we don't want to introduce a dependency from
Search to OGM).

In fact there are some integration tests already, running on WildFly
for each single build of OGM:
 - https://github.com/hibernate/hibernate-ogm/blob/master/integrationtest/src/test/java/org/hibernate/ogm/test/integration/infinispan/SearchIntegrationIT.java

I guess these are too simple for your needs? Happy to extend these,
especially if you have specific pointers or - even better - willing to
send PRs.

Secondary aspect: let's assume we had good enough integration tests in
OGM. Should we advertise these more prominently in documentation?

Thanks,
Sanne


On 27 July 2016 at 17:55, Flemming Harms <flemming.harms at gmail.com> wrote:
> Folks,
>
> Is there something similar to javaee7-samples for Hibernate OGM and HSEARCH
> today? I know the Hibernate Demo repo exist, but from what I can read this
> is demos you have created for various talk and presentations.
>
> If not I would suggest a new repository is created with samples showing how
> to use OGM, HSEARCH in various ways and configurations. The Hibernate Demo
> repo could be a good starting point, but I?m thinking a new repo where we
> divide into modules to make it easy to upgrade and maintain the samples
> from a parent configuration file etc.
>
> I personally learn much more from examples and then I can use the
> documentation as reference point. And this will also be good reference
> repository for testing against when releasing a new version.
>
> I would like to contribute with various samples to help build the repository
>
> What do you think?
>
> /Flemming
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Thu Jul 28 12:07:15 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 28 Jul 2016 16:07:15 +0000
Subject: [hibernate-dev] SchemaCreatorImpl always creating a poolable
	sequence
In-Reply-To: <5f4b9733-b1e6-f569-52b7-a3c79028cfbc@lawinegevaar.nl>
References: <609731e9-dddc-afad-2f3d-ace9e15b3703@lawinegevaar.nl>
	<CA+gWKMBs7qGshCvO8ft0f-soyWuC3U1i8K1bjveT_uv+_HsZUA@mail.gmail.com>
	<3b153159-2170-a7e6-f8ed-fb7e250bbe3b@lawinegevaar.nl>
	<CA+gWKMBT7ZkLPL+1Ocyz4DzOVr8VS-mWhpKV+SffdsqpaHKx0w@mail.gmail.com>
	<5f4b9733-b1e6-f569-52b7-a3c79028cfbc@lawinegevaar.nl>
Message-ID: <CAFdSV9sXFv_7ZPd6fPXgyewjoeYZjgZR4bDoeC1CNPuGU2VN=g@mail.gmail.com>

I do think this is an error.  I think the proper fix is to first make use
of Exporter<Sequence>#getSqlCreateStrings via Dialect#getSequenceExporter.

>From there, either:

   1. Change the standard Exporter<Sequence> to look at
   Dialect#supportsPooledSequences and deciding which
   Dialect#getCreateSequenceStrings form to call
   2. Change Firebird's Exporter<Sequence> impl

I'd also suggest we properly deprecate Dialect#supportsPooledSequences,
Dialect#getCreateSequenceStrings directing to Dialect#getSequenceExporter.


On Thu, Jul 28, 2016 at 6:15 AM Mark Rotteveel <mark at lawinegevaar.nl> wrote:

> On 28-7-2016 13:02, Vlad Mihalcea wrote:
> > Is it that you get the exception even if the incrementSize is 1? I guess
> > this is an issue that we need to open a Jira ticket for it.
>
> Yes, see the code in my initial email: SchemaCreatorImpl always tries to
> create a pooled sequence.
>
> Mark
> --
> Mark Rotteveel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From daltodavide at gmail.com  Thu Jul 28 12:35:44 2016
From: daltodavide at gmail.com (Davide D'Alto)
Date: Thu, 28 Jul 2016 17:35:44 +0100
Subject: [hibernate-dev] [OGM][HSEARCH] Hibernate OGM and Hibernate
	Search samples
In-Reply-To: <CAFm4XO1PJhxm07Q3VTbf=HLhMKPUR2O8Bm28uLPccBv=TRoF9Q@mail.gmail.com>
References: <CAFP3+ynz6sVLc0ZaCHxwi=UViciRD9dm-KdQMBCyabyJwwAKQA@mail.gmail.com>
	<CAFm4XO1PJhxm07Q3VTbf=HLhMKPUR2O8Bm28uLPccBv=TRoF9Q@mail.gmail.com>
Message-ID: <CANoTJYOg=Ze0HLx9YVwZJZvEP37qPROMPb1T4Q79Sr6jLcoU_w@mail.gmail.com>

> Secondary aspect: let's assume we had good enough integration tests in
> OGM. Should we advertise these more prominently in documentation?

I don't think we should, an integration test is different from an example.
I'm afraid will be harder for people to recognize what it is required
and what it is part of the test.
Also an example should have additional comments describing what's
going on and what can be changed (IMHO).

I think we need an additional module with proper examples with proper
separation of project sources, configuration and tests.

We should also consider working on the Stack Overflow documentation:
http://stackoverflow.com/documentation/improvement-requests/view/907

Flemming, if you have already some example project on your github we
can have a look and think about the best way to integrate it.

Thanks,
Davide


On Thu, Jul 28, 2016 at 4:38 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> Hi Flemming,
>
> I agree on the importance to have some runnable examples, but I'm
> afraid that the "demos" repository wouldn't be kept up to date with
> every single release.
> Introducing more tasks to perform during a release is not desirable,
> as the release process is quite complex already.
>
> So I propose that such examples belong in the integration tests of the
> projects; specifically, a JavaEE7 example using both Hibernate Search
> and Hibernate OGM would need to be maintained by the OGM project (as
> OGM depends on Search, we don't want to introduce a dependency from
> Search to OGM).
>
> In fact there are some integration tests already, running on WildFly
> for each single build of OGM:
>  - https://github.com/hibernate/hibernate-ogm/blob/master/integrationtest/src/test/java/org/hibernate/ogm/test/integration/infinispan/SearchIntegrationIT.java
>
> I guess these are too simple for your needs? Happy to extend these,
> especially if you have specific pointers or - even better - willing to
> send PRs.
>
> Secondary aspect: let's assume we had good enough integration tests in
> OGM. Should we advertise these more prominently in documentation?
>
> Thanks,
> Sanne
>
>
> On 27 July 2016 at 17:55, Flemming Harms <flemming.harms at gmail.com> wrote:
>> Folks,
>>
>> Is there something similar to javaee7-samples for Hibernate OGM and HSEARCH
>> today? I know the Hibernate Demo repo exist, but from what I can read this
>> is demos you have created for various talk and presentations.
>>
>> If not I would suggest a new repository is created with samples showing how
>> to use OGM, HSEARCH in various ways and configurations. The Hibernate Demo
>> repo could be a good starting point, but I?m thinking a new repo where we
>> divide into modules to make it easy to upgrade and maintain the samples
>> from a parent configuration file etc.
>>
>> I personally learn much more from examples and then I can use the
>> documentation as reference point. And this will also be good reference
>> repository for testing against when releasing a new version.
>>
>> I would like to contribute with various samples to help build the repository
>>
>> What do you think?
>>
>> /Flemming
>> _______________________________________________
>> 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 flemming.harms at gmail.com  Fri Jul 29 07:31:58 2016
From: flemming.harms at gmail.com (Flemming Harms)
Date: Fri, 29 Jul 2016 13:31:58 +0200
Subject: [hibernate-dev] [OGM][HSEARCH] Hibernate OGM and Hibernate
	Search samples
In-Reply-To: <CANoTJYOg=Ze0HLx9YVwZJZvEP37qPROMPb1T4Q79Sr6jLcoU_w@mail.gmail.com>
References: <CAFP3+ynz6sVLc0ZaCHxwi=UViciRD9dm-KdQMBCyabyJwwAKQA@mail.gmail.com>
	<CAFm4XO1PJhxm07Q3VTbf=HLhMKPUR2O8Bm28uLPccBv=TRoF9Q@mail.gmail.com>
	<CANoTJYOg=Ze0HLx9YVwZJZvEP37qPROMPb1T4Q79Sr6jLcoU_w@mail.gmail.com>
Message-ID: <CAFP3+ynYB-n0_nV+bRamRgVU8OFU38+bEReFm95LbnAXVWZKBg@mail.gmail.com>

Hi Sanne & Davide

I didn?t mean to imply the integration test wasn?t good enough, and the
main purpose was not to use examples as test cover, but if we build a rich
collection of examples it might be a good source for testing as a extra
bonus in the future.

I think integration tests serves different purpose in my mind. Integrations
tests is used for testing a very specific use case or issues. They are part
of the source code and will require you to check out the hibernate source
code for running and understand how they works. IMHO not very end user
friendly.

An example serve the purpose of showing how you use the a specific feature
/ combination, eg ?Mongodb with Hibernate OGM? or ?Query data with
Hibernate OGM? from an end user point aka Developer. It?s a small isolated
Arquillian / Unit tests which is better documented and easy to run without
the need of check out all the Hibernate source code.

The reason I suggested a new examples/samples repository is because you
work around the dependency problem Sanne mention, and it becomes a joint
venture between the different Hibernate projects and the community. I also
believe it will be easier to get people to contribute examples if this is
separated from the hibernate source code.

Davide,  I only have one Hibernate OGM example(
https://github.com/fharms/java-examples/tree/upgrade_ogm_wildfly10) and
this is not well documented because it is explained in a blog post. But I
like how the JavaEE 7 -  https://github.com/javaee-samples/javaee7-samples
do it

But i?m willing to help creating more examples :-)

Thanks,
Flemming

2016-07-28 18:35 GMT+02:00 Davide D'Alto <daltodavide at gmail.com>:

> > Secondary aspect: let's assume we had good enough integration tests in
> > OGM. Should we advertise these more prominently in documentation?
>
> I don't think we should, an integration test is different from an example.
> I'm afraid will be harder for people to recognize what it is required
> and what it is part of the test.
> Also an example should have additional comments describing what's
> going on and what can be changed (IMHO).
>
> I think we need an additional module with proper examples with proper
> separation of project sources, configuration and tests.
>
> We should also consider working on the Stack Overflow documentation:
> http://stackoverflow.com/documentation/improvement-requests/view/907
>
> Flemming, if you have already some example project on your github we
> can have a look and think about the best way to integrate it.
>
> Thanks,
> Davide
>
>
> On Thu, Jul 28, 2016 at 4:38 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
> > Hi Flemming,
> >
> > I agree on the importance to have some runnable examples, but I'm
> > afraid that the "demos" repository wouldn't be kept up to date with
> > every single release.
> > Introducing more tasks to perform during a release is not desirable,
> > as the release process is quite complex already.
> >
> > So I propose that such examples belong in the integration tests of the
> > projects; specifically, a JavaEE7 example using both Hibernate Search
> > and Hibernate OGM would need to be maintained by the OGM project (as
> > OGM depends on Search, we don't want to introduce a dependency from
> > Search to OGM).
> >
> > In fact there are some integration tests already, running on WildFly
> > for each single build of OGM:
> >  -
> https://github.com/hibernate/hibernate-ogm/blob/master/integrationtest/src/test/java/org/hibernate/ogm/test/integration/infinispan/SearchIntegrationIT.java
> >
> > I guess these are too simple for your needs? Happy to extend these,
> > especially if you have specific pointers or - even better - willing to
> > send PRs.
> >
> > Secondary aspect: let's assume we had good enough integration tests in
> > OGM. Should we advertise these more prominently in documentation?
> >
> > Thanks,
> > Sanne
> >
> >
> > On 27 July 2016 at 17:55, Flemming Harms <flemming.harms at gmail.com>
> wrote:
> >> Folks,
> >>
> >> Is there something similar to javaee7-samples for Hibernate OGM and
> HSEARCH
> >> today? I know the Hibernate Demo repo exist, but from what I can read
> this
> >> is demos you have created for various talk and presentations.
> >>
> >> If not I would suggest a new repository is created with samples showing
> how
> >> to use OGM, HSEARCH in various ways and configurations. The Hibernate
> Demo
> >> repo could be a good starting point, but I?m thinking a new repo where
> we
> >> divide into modules to make it easy to upgrade and maintain the samples
> >> from a parent configuration file etc.
> >>
> >> I personally learn much more from examples and then I can use the
> >> documentation as reference point. And this will also be good reference
> >> repository for testing against when releasing a new version.
> >>
> >> I would like to contribute with various samples to help build the
> repository
> >>
> >> What do you think?
> >>
> >> /Flemming
> >> _______________________________________________
> >> 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
>



-- 

Kind regards / Med Venlig Hilsen
Flemming Harms

   -

https://twitter.com/fnharms
https://dk.linkedin.com/in/fharms

From mark at lawinegevaar.nl  Fri Jul 29 07:53:04 2016
From: mark at lawinegevaar.nl (Mark Rotteveel)
Date: Fri, 29 Jul 2016 12:53:04 +0100
Subject: [hibernate-dev] SchemaCreatorImpl always creating a poolable
 sequence
In-Reply-To: <CAFdSV9sXFv_7ZPd6fPXgyewjoeYZjgZR4bDoeC1CNPuGU2VN=g@mail.gmail.com>
References: <609731e9-dddc-afad-2f3d-ace9e15b3703@lawinegevaar.nl>
	<CA+gWKMBs7qGshCvO8ft0f-soyWuC3U1i8K1bjveT_uv+_HsZUA@mail.gmail.com>
	<3b153159-2170-a7e6-f8ed-fb7e250bbe3b@lawinegevaar.nl>
	<CA+gWKMBT7ZkLPL+1Ocyz4DzOVr8VS-mWhpKV+SffdsqpaHKx0w@mail.gmail.com>
	<5f4b9733-b1e6-f569-52b7-a3c79028cfbc@lawinegevaar.nl>
	<CAFdSV9sXFv_7ZPd6fPXgyewjoeYZjgZR4bDoeC1CNPuGU2VN=g@mail.gmail.com>
Message-ID: <c7c5e4001bb26e2a4692a3e29fdf702c@lawinegevaar.nl>

On 2016-07-28 17:07, Steve Ebersole wrote:
> I do think this is an error.? I think the proper fix is to first
> make?use of Exporter<Sequence>#getSqlCreateStrings via
> Dialect#getSequenceExporter. ?
>
> From there, either:
>
> 	* Change the standard?Exporter<Sequence> to look at
> Dialect#supportsPooledSequences and deciding which
> Dialect#getCreateSequenceStrings form to call
> 	* Change Firebirds?Exporter<Sequence> impl
>
> Id also suggest we properly deprecate 
> Dialect#supportsPooledSequences,
> Dialect#getCreateSequenceStrings directing to
> Dialect#getSequenceExporter. ?

I will look this weekend if I can do that as part of my dialect 
implementation; I will likely do it with a separate pull request.

Mark

From gbadner at redhat.com  Fri Jul 29 19:52:49 2016
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 29 Jul 2016 16:52:49 -0700
Subject: [hibernate-dev] Preparing for 5.0.10 and 5.1.1 releases
Message-ID: <CAFDzhiTPjko4mpEMdDK2Ak20qV-HEM2tn1e8JypGsKx6WQph6Q@mail.gmail.com>

I'm wrapping things up to release 5.0.10 and possibly 5.1.1 this weekend.

Please do not push any commits to 5.0 or 5.1 branches.

Thanks,
Gail

From mark at lawinegevaar.nl  Sat Jul 30 04:31:49 2016
From: mark at lawinegevaar.nl (Mark Rotteveel)
Date: Sat, 30 Jul 2016 10:31:49 +0200
Subject: [hibernate-dev] SchemaCreatorImpl always creating a poolable
 sequence
In-Reply-To: <CAFdSV9sXFv_7ZPd6fPXgyewjoeYZjgZR4bDoeC1CNPuGU2VN=g@mail.gmail.com>
References: <609731e9-dddc-afad-2f3d-ace9e15b3703@lawinegevaar.nl>
	<CA+gWKMBs7qGshCvO8ft0f-soyWuC3U1i8K1bjveT_uv+_HsZUA@mail.gmail.com>
	<3b153159-2170-a7e6-f8ed-fb7e250bbe3b@lawinegevaar.nl>
	<CA+gWKMBT7ZkLPL+1Ocyz4DzOVr8VS-mWhpKV+SffdsqpaHKx0w@mail.gmail.com>
	<5f4b9733-b1e6-f569-52b7-a3c79028cfbc@lawinegevaar.nl>
	<CAFdSV9sXFv_7ZPd6fPXgyewjoeYZjgZR4bDoeC1CNPuGU2VN=g@mail.gmail.com>
Message-ID: <8eca4cc2-df9f-c2bf-e793-e852eeaa5596@lawinegevaar.nl>

On 28-7-2016 18:07, Steve Ebersole wrote:
> I do think this is an error.  I think the proper fix is to first
> make use of Exporter<Sequence>#getSqlCreateStrings via
> Dialect#getSequenceExporter.
>
> From there, either:
>
>  1. Change the standard Exporter<Sequence> to look at
>     Dialect#supportsPooledSequences and deciding which
>     Dialect#getCreateSequenceStrings form to call
>  2. Change Firebird's Exporter<Sequence> impl

I have fixed the immediate problem by implementing the 
getCreateSequenceStrings(String, int, int) and 
getCreateSequenceString(String, int, int) as:

@Override
public String[] getCreateSequenceStrings(String sequenceName, int 
initialValue, int incrementSize) throws MappingException {
     return new String[] {
         getCreateSequenceString( sequenceName, initialValue, 
incrementSize ),
         "alter sequence " + sequenceName + " restart with " + 
(initialValue - 1)
     };
}

@Override
protected String getCreateSequenceString(String sequenceName, int 
initialValue, int incrementSize)
         throws MappingException {
     if (incrementSize > 1) {
         throw new MappingException( getClass().getName() + " does not 
support pooled sequences" );
     }
     // Ignore initialValue and incrementSize
     return getCreateSequenceString( sequenceName );
}

So as long as a non-pooled sequence (incrementSize = 1) is requested the 
Firebird25Dialect will happily oblige. I will add a similar solution to 
the InterbaseDialect and FirebirdDialect.

> I'd also suggest we properly deprecate Dialect#supportsPooledSequences,
> Dialect#getCreateSequenceStrings directing to Dialect#getSequenceExporter.

The problem with that is that the StandardSequenceExporter uses 
getCreateSequenceStrings to do its work, so deprecating that would 
require more rework.

Mark
-- 
Mark Rotteveel

From steve at hibernate.org  Sat Jul 30 08:11:40 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 30 Jul 2016 12:11:40 +0000
Subject: [hibernate-dev] SchemaCreatorImpl always creating a poolable
	sequence
In-Reply-To: <8eca4cc2-df9f-c2bf-e793-e852eeaa5596@lawinegevaar.nl>
References: <609731e9-dddc-afad-2f3d-ace9e15b3703@lawinegevaar.nl>
	<CA+gWKMBs7qGshCvO8ft0f-soyWuC3U1i8K1bjveT_uv+_HsZUA@mail.gmail.com>
	<3b153159-2170-a7e6-f8ed-fb7e250bbe3b@lawinegevaar.nl>
	<CA+gWKMBT7ZkLPL+1Ocyz4DzOVr8VS-mWhpKV+SffdsqpaHKx0w@mail.gmail.com>
	<5f4b9733-b1e6-f569-52b7-a3c79028cfbc@lawinegevaar.nl>
	<CAFdSV9sXFv_7ZPd6fPXgyewjoeYZjgZR4bDoeC1CNPuGU2VN=g@mail.gmail.com>
	<8eca4cc2-df9f-c2bf-e793-e852eeaa5596@lawinegevaar.nl>
Message-ID: <CAFdSV9umPjGW=OoWWw8nqgxBOxR5Abv7R_vo_dw+1Q10ycvPQw@mail.gmail.com>

Moving this functionality into the Exporter is the correct answer.
Eventually those DIalect methods will go away.

On Sat, Jul 30, 2016 at 3:32 AM Mark Rotteveel <mark at lawinegevaar.nl> wrote:

> On 28-7-2016 18:07, Steve Ebersole wrote:
> > I do think this is an error.  I think the proper fix is to first
> > make use of Exporter<Sequence>#getSqlCreateStrings via
> > Dialect#getSequenceExporter.
> >
> > From there, either:
> >
> >  1. Change the standard Exporter<Sequence> to look at
> >     Dialect#supportsPooledSequences and deciding which
> >     Dialect#getCreateSequenceStrings form to call
> >  2. Change Firebird's Exporter<Sequence> impl
>
> I have fixed the immediate problem by implementing the
> getCreateSequenceStrings(String, int, int) and
> getCreateSequenceString(String, int, int) as:
>
> @Override
> public String[] getCreateSequenceStrings(String sequenceName, int
> initialValue, int incrementSize) throws MappingException {
>      return new String[] {
>          getCreateSequenceString( sequenceName, initialValue,
> incrementSize ),
>          "alter sequence " + sequenceName + " restart with " +
> (initialValue - 1)
>      };
> }
>
> @Override
> protected String getCreateSequenceString(String sequenceName, int
> initialValue, int incrementSize)
>          throws MappingException {
>      if (incrementSize > 1) {
>          throw new MappingException( getClass().getName() + " does not
> support pooled sequences" );
>      }
>      // Ignore initialValue and incrementSize
>      return getCreateSequenceString( sequenceName );
> }
>
> So as long as a non-pooled sequence (incrementSize = 1) is requested the
> Firebird25Dialect will happily oblige. I will add a similar solution to
> the InterbaseDialect and FirebirdDialect.
>
> > I'd also suggest we properly deprecate Dialect#supportsPooledSequences,
> > Dialect#getCreateSequenceStrings directing to
> Dialect#getSequenceExporter.
>
> The problem with that is that the StandardSequenceExporter uses
> getCreateSequenceStrings to do its work, so deprecating that would
> require more rework.
>
> Mark
> --
> Mark Rotteveel
>

From steve at hibernate.org  Sat Jul 30 08:36:48 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 30 Jul 2016 12:36:48 +0000
Subject: [hibernate-dev] Preparing for 5.0.10 and 5.1.1 releases
In-Reply-To: <CAFDzhiTPjko4mpEMdDK2Ak20qV-HEM2tn1e8JypGsKx6WQph6Q@mail.gmail.com>
References: <CAFDzhiTPjko4mpEMdDK2Ak20qV-HEM2tn1e8JypGsKx6WQph6Q@mail.gmail.com>
Message-ID: <CAFdSV9sqNgMmMzBtzzRmk3tUqjpBvyecABHbS_nesZxJyqguKw@mail.gmail.com>

Do you need me to do anything in regards to HHH-10896 for these?


On Fri, Jul 29, 2016 at 6:55 PM Gail Badner <gbadner at redhat.com> wrote:

> I'm wrapping things up to release 5.0.10 and possibly 5.1.1 this weekend.
>
> Please do not push any commits to 5.0 or 5.1 branches.
>
> Thanks,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Sat Jul 30 08:51:59 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 30 Jul 2016 12:51:59 +0000
Subject: [hibernate-dev] SchemaCreatorImpl always creating a poolable
	sequence
In-Reply-To: <CAFdSV9umPjGW=OoWWw8nqgxBOxR5Abv7R_vo_dw+1Q10ycvPQw@mail.gmail.com>
References: <609731e9-dddc-afad-2f3d-ace9e15b3703@lawinegevaar.nl>
	<CA+gWKMBs7qGshCvO8ft0f-soyWuC3U1i8K1bjveT_uv+_HsZUA@mail.gmail.com>
	<3b153159-2170-a7e6-f8ed-fb7e250bbe3b@lawinegevaar.nl>
	<CA+gWKMBT7ZkLPL+1Ocyz4DzOVr8VS-mWhpKV+SffdsqpaHKx0w@mail.gmail.com>
	<5f4b9733-b1e6-f569-52b7-a3c79028cfbc@lawinegevaar.nl>
	<CAFdSV9sXFv_7ZPd6fPXgyewjoeYZjgZR4bDoeC1CNPuGU2VN=g@mail.gmail.com>
	<8eca4cc2-df9f-c2bf-e793-e852eeaa5596@lawinegevaar.nl>
	<CAFdSV9umPjGW=OoWWw8nqgxBOxR5Abv7R_vo_dw+1Q10ycvPQw@mail.gmail.com>
Message-ID: <CAFdSV9tHk4nRox6ZcBGCABQhu8XirQh15Yf2isfDerZ1-zHKww@mail.gmail.com>

FYI... https://hibernate.atlassian.net/browse/HHH-11010

ATM I have this scheduled for 6.0.  In an ideal world we would have
performed these deprecations in 5.2 also and removed the deprecated methods
in 6.0.  I can certainly be convinced to do this deprecation in 5.2 however
:)


On Sat, Jul 30, 2016 at 7:11 AM Steve Ebersole <steve at hibernate.org> wrote:

> Moving this functionality into the Exporter is the correct answer.
> Eventually those DIalect methods will go away.
>
>
> On Sat, Jul 30, 2016 at 3:32 AM Mark Rotteveel <mark at lawinegevaar.nl>
> wrote:
>
>> On 28-7-2016 18:07, Steve Ebersole wrote:
>> > I do think this is an error.  I think the proper fix is to first
>> > make use of Exporter<Sequence>#getSqlCreateStrings via
>> > Dialect#getSequenceExporter.
>> >
>> > From there, either:
>> >
>> >  1. Change the standard Exporter<Sequence> to look at
>> >     Dialect#supportsPooledSequences and deciding which
>> >     Dialect#getCreateSequenceStrings form to call
>> >  2. Change Firebird's Exporter<Sequence> impl
>>
>> I have fixed the immediate problem by implementing the
>> getCreateSequenceStrings(String, int, int) and
>> getCreateSequenceString(String, int, int) as:
>>
>> @Override
>> public String[] getCreateSequenceStrings(String sequenceName, int
>> initialValue, int incrementSize) throws MappingException {
>>      return new String[] {
>>          getCreateSequenceString( sequenceName, initialValue,
>> incrementSize ),
>>          "alter sequence " + sequenceName + " restart with " +
>> (initialValue - 1)
>>      };
>> }
>>
>> @Override
>> protected String getCreateSequenceString(String sequenceName, int
>> initialValue, int incrementSize)
>>          throws MappingException {
>>      if (incrementSize > 1) {
>>          throw new MappingException( getClass().getName() + " does not
>> support pooled sequences" );
>>      }
>>      // Ignore initialValue and incrementSize
>>      return getCreateSequenceString( sequenceName );
>> }
>>
>> So as long as a non-pooled sequence (incrementSize = 1) is requested the
>> Firebird25Dialect will happily oblige. I will add a similar solution to
>> the InterbaseDialect and FirebirdDialect.
>>
>> > I'd also suggest we properly deprecate Dialect#supportsPooledSequences,
>> > Dialect#getCreateSequenceStrings directing to
>> Dialect#getSequenceExporter.
>>
>> The problem with that is that the StandardSequenceExporter uses
>> getCreateSequenceStrings to do its work, so deprecating that would
>> require more rework.
>>
>> Mark
>> --
>> Mark Rotteveel
>>
>