From paranoiabla at gmail.com  Mon Jan  5 11:03:04 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Mon, 5 Jan 2015 18:03:04 +0200
Subject: [hibernate-dev] Can I have some help with HHH-9306
Message-ID: <CAKnbemV_ciGcAs=H9DJSL-pU0eXaT=FghWuz1a2y0oGQP8HnPg@mail.gmail.com>

Hello everyone,

and a happy new year :) I'm having troubles with this issue:

https://hibernate.atlassian.net/browse/HHH-9306

and I have also created a pull-request for it:

https://github.com/hibernate/hibernate-orm/pull/863

However, I'm not 100% sure if this is the correct way to fix it. Can
someone please review the pull request and if you have some comments, let
me know. This issue is blocking me at the moment.

Thanks a lot and keep up the good work.

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From gunnar at hibernate.org  Mon Jan  5 12:22:07 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 5 Jan 2015 18:22:07 +0100
Subject: [hibernate-dev] [OGM] Mapping discussions for OGM 5.0
Message-ID: <CADGJaX_GHNwKKVFKp5cJqB06xZfZreJhC3ovou8H8NAt+dabsA@mail.gmail.com>

Hi,

Now that 4.1 is out and we cannot easily change persistent mappings
anymore, a future OGM 5.0 will probably be the right occasion to re-visit
certain persistent mappings in a more general form.

I've created a wiki page to gather any questions, discussions etc. around
this topic:
https://developer.jboss.org/wiki/DesignAndMappingConsiderationsForHibernateOGM50

Cheers,

--Gunnar

From gbadner at redhat.com  Mon Jan  5 16:10:08 2015
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 5 Jan 2015 16:10:08 -0500 (EST)
Subject: [hibernate-dev] Preparing to release  4.3.8 and  4.2.17
In-Reply-To: <724922860.3991845.1420487837016.JavaMail.zimbra@redhat.com>
Message-ID: <338135314.4022546.1420492208445.JavaMail.zimbra@redhat.com>

I'm getting ready to release 4.3.8 and 4.2.17. Please do not push any new fixes until they are released.

Thanks!
Gail

From gbadner at redhat.com  Tue Jan  6 03:37:41 2015
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 6 Jan 2015 03:37:41 -0500 (EST)
Subject: [hibernate-dev] Preparing to release  4.3.8 and  4.2.17
In-Reply-To: <338135314.4022546.1420492208445.JavaMail.zimbra@redhat.com>
References: <338135314.4022546.1420492208445.JavaMail.zimbra@redhat.com>
Message-ID: <233638682.4691371.1420533461682.JavaMail.zimbra@redhat.com>

I've finished building and taggind for 4.2.17.Final. I'm getting some final fixes in for 4.3.8.Final, then I'll release that version. I'll finish these up on Tuesday.
Gail

----- Original Message -----
> From: "Gail Badner" <gbadner at redhat.com>
> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Monday, January 5, 2015 1:10:08 PM
> Subject: [hibernate-dev] Preparing to release  4.3.8 and  4.2.17
> 
> I'm getting ready to release 4.3.8 and 4.2.17. Please do not push any new
> fixes until they are released.
> 
> Thanks!
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From paranoiabla at gmail.com  Tue Jan  6 03:47:11 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Tue, 6 Jan 2015 10:47:11 +0200
Subject: [hibernate-dev] Preparing to release 4.3.8 and 4.2.17
In-Reply-To: <233638682.4691371.1420533461682.JavaMail.zimbra@redhat.com>
References: <338135314.4022546.1420492208445.JavaMail.zimbra@redhat.com>
	<233638682.4691371.1420533461682.JavaMail.zimbra@redhat.com>
Message-ID: <CAKnbemXky2ZZ6qYvSYLBq9NGTiwY7f4VX-uPY32ZFA=aLkyRBg@mail.gmail.com>

Any chance to get this included
https://github.com/hibernate/hibernate-orm/pull/863 ?


2015-01-06 10:37 GMT+02:00 Gail Badner <gbadner at redhat.com>:

> I've finished building and taggind for 4.2.17.Final. I'm getting some
> final fixes in for 4.3.8.Final, then I'll release that version. I'll finish
> these up on Tuesday.
> Gail
>
> ----- Original Message -----
> > From: "Gail Badner" <gbadner at redhat.com>
> > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > Sent: Monday, January 5, 2015 1:10:08 PM
> > Subject: [hibernate-dev] Preparing to release  4.3.8 and  4.2.17
> >
> > I'm getting ready to release 4.3.8 and 4.2.17. Please do not push any new
> > fixes until they are released.
> >
> > Thanks!
> > Gail
> > _______________________________________________
> > 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
>



-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From gbadner at redhat.com  Tue Jan  6 04:00:56 2015
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 6 Jan 2015 04:00:56 -0500 (EST)
Subject: [hibernate-dev] Preparing to release 4.3.8 and 4.2.17
In-Reply-To: <CAKnbemXky2ZZ6qYvSYLBq9NGTiwY7f4VX-uPY32ZFA=aLkyRBg@mail.gmail.com>
References: <338135314.4022546.1420492208445.JavaMail.zimbra@redhat.com>
	<233638682.4691371.1420533461682.JavaMail.zimbra@redhat.com>
	<CAKnbemXky2ZZ6qYvSYLBq9NGTiwY7f4VX-uPY32ZFA=aLkyRBg@mail.gmail.com>
Message-ID: <15027560.4697003.1420534856853.JavaMail.zimbra@redhat.com>

Hi Peter,

It looks like your pull request changed tabs to spaces, so there are a lot of diffs. I can't tell what exactly you changed. Please recreate the pull request without changing tabs to spaces.

I'm sorry, this will not make it into 4.3.8. I'll consider it for 4.3.9.

Regards,
Gail

----- Original Message -----
> From: "Petar Tahchiev" <paranoiabla at gmail.com>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Tuesday, January 6, 2015 12:47:11 AM
> Subject: Re: [hibernate-dev] Preparing to release 4.3.8 and 4.2.17
> 
> Any chance to get this included
> https://github.com/hibernate/hibernate-orm/pull/863 ?
> 
> 
> 2015-01-06 10:37 GMT+02:00 Gail Badner <gbadner at redhat.com>:
> 
> > I've finished building and taggind for 4.2.17.Final. I'm getting some
> > final fixes in for 4.3.8.Final, then I'll release that version. I'll finish
> > these up on Tuesday.
> > Gail
> >
> > ----- Original Message -----
> > > From: "Gail Badner" <gbadner at redhat.com>
> > > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > > Sent: Monday, January 5, 2015 1:10:08 PM
> > > Subject: [hibernate-dev] Preparing to release  4.3.8 and  4.2.17
> > >
> > > I'm getting ready to release 4.3.8 and 4.2.17. Please do not push any new
> > > fixes until they are released.
> > >
> > > Thanks!
> > > Gail
> > > _______________________________________________
> > > 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
> >
> 
> 
> 
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> 

From paranoiabla at gmail.com  Tue Jan  6 04:50:15 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Tue, 6 Jan 2015 11:50:15 +0200
Subject: [hibernate-dev] Preparing to release 4.3.8 and 4.2.17
In-Reply-To: <15027560.4697003.1420534856853.JavaMail.zimbra@redhat.com>
References: <338135314.4022546.1420492208445.JavaMail.zimbra@redhat.com>
	<233638682.4691371.1420533461682.JavaMail.zimbra@redhat.com>
	<CAKnbemXky2ZZ6qYvSYLBq9NGTiwY7f4VX-uPY32ZFA=aLkyRBg@mail.gmail.com>
	<15027560.4697003.1420534856853.JavaMail.zimbra@redhat.com>
Message-ID: <CAKnbemUyMLAf6DzZ0mYnxYSvk+2y_cdr5FY3ow_kJ6CifTABxA@mail.gmail.com>

Hi Gail,

can you point me to the Hibernate code formatter file (for eclipse or
intellij idea)? I'm trying to find it but i cannot.

2015-01-06 11:00 GMT+02:00 Gail Badner <gbadner at redhat.com>:

> Hi Peter,
>
> It looks like your pull request changed tabs to spaces, so there are a lot
> of diffs. I can't tell what exactly you changed. Please recreate the pull
> request without changing tabs to spaces.
>
> I'm sorry, this will not make it into 4.3.8. I'll consider it for 4.3.9.
>
> Regards,
> Gail
>
> ----- Original Message -----
> > From: "Petar Tahchiev" <paranoiabla at gmail.com>
> > To: "Gail Badner" <gbadner at redhat.com>
> > Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > Sent: Tuesday, January 6, 2015 12:47:11 AM
> > Subject: Re: [hibernate-dev] Preparing to release 4.3.8 and 4.2.17
> >
> > Any chance to get this included
> > https://github.com/hibernate/hibernate-orm/pull/863 ?
> >
> >
> > 2015-01-06 10:37 GMT+02:00 Gail Badner <gbadner at redhat.com>:
> >
> > > I've finished building and taggind for 4.2.17.Final. I'm getting some
> > > final fixes in for 4.3.8.Final, then I'll release that version. I'll
> finish
> > > these up on Tuesday.
> > > Gail
> > >
> > > ----- Original Message -----
> > > > From: "Gail Badner" <gbadner at redhat.com>
> > > > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > > > Sent: Monday, January 5, 2015 1:10:08 PM
> > > > Subject: [hibernate-dev] Preparing to release  4.3.8 and  4.2.17
> > > >
> > > > I'm getting ready to release 4.3.8 and 4.2.17. Please do not push
> any new
> > > > fixes until they are released.
> > > >
> > > > Thanks!
> > > > Gail
> > > > _______________________________________________
> > > > 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
> > >
> >
> >
> >
> > --
> > Regards, Petar!
> > Karlovo, Bulgaria.
> > ---
> > Public PGP Key at:
> >
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> >
>



-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From sanne at hibernate.org  Tue Jan  6 06:25:26 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 6 Jan 2015 11:25:26 +0000
Subject: [hibernate-dev] Preparing to release 4.3.8 and 4.2.17
In-Reply-To: <CAKnbemUyMLAf6DzZ0mYnxYSvk+2y_cdr5FY3ow_kJ6CifTABxA@mail.gmail.com>
References: <338135314.4022546.1420492208445.JavaMail.zimbra@redhat.com>
	<233638682.4691371.1420533461682.JavaMail.zimbra@redhat.com>
	<CAKnbemXky2ZZ6qYvSYLBq9NGTiwY7f4VX-uPY32ZFA=aLkyRBg@mail.gmail.com>
	<15027560.4697003.1420534856853.JavaMail.zimbra@redhat.com>
	<CAKnbemUyMLAf6DzZ0mYnxYSvk+2y_cdr5FY3ow_kJ6CifTABxA@mail.gmail.com>
Message-ID: <CAFm4XO2DornLrwKS0E4OLq4JsQPKDO7i7Ed2iF8WLvqOweiZmA@mail.gmail.com>

Hi Petar,
we have different instructions for Eclipse or IntelliJ users; here you
should find general contribution guidelines and also the code styles
attached:
 - https://developer.jboss.org/wiki/ContributingToHibernateUsingEclipse
 - https://developer.jboss.org/wiki/ContributingToHibernateUsingIntelliJ

And another hint: while we'd love new patches to follow the formatting
and style conventions, please never reformat existing code so that
patches are as small as needed for the fix/feature.
That makes it far easier to understand the patch, and possibly avoid
some pain if eventually someone wants to port your fix to a different
branch.

Also, could you please sign the contributor's agreement?
 https://cla.jboss.org -> pick "Hibernate" in the drop down menu.

Thanks for your help!

Sanne

On 6 January 2015 at 09:50, Petar Tahchiev <paranoiabla at gmail.com> wrote:
> Hi Gail,
>
> can you point me to the Hibernate code formatter file (for eclipse or
> intellij idea)? I'm trying to find it but i cannot.
>
> 2015-01-06 11:00 GMT+02:00 Gail Badner <gbadner at redhat.com>:
>
>> Hi Peter,
>>
>> It looks like your pull request changed tabs to spaces, so there are a lot
>> of diffs. I can't tell what exactly you changed. Please recreate the pull
>> request without changing tabs to spaces.
>>
>> I'm sorry, this will not make it into 4.3.8. I'll consider it for 4.3.9.
>>
>> Regards,
>> Gail
>>
>> ----- Original Message -----
>> > From: "Petar Tahchiev" <paranoiabla at gmail.com>
>> > To: "Gail Badner" <gbadner at redhat.com>
>> > Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>> > Sent: Tuesday, January 6, 2015 12:47:11 AM
>> > Subject: Re: [hibernate-dev] Preparing to release 4.3.8 and 4.2.17
>> >
>> > Any chance to get this included
>> > https://github.com/hibernate/hibernate-orm/pull/863 ?
>> >
>> >
>> > 2015-01-06 10:37 GMT+02:00 Gail Badner <gbadner at redhat.com>:
>> >
>> > > I've finished building and taggind for 4.2.17.Final. I'm getting some
>> > > final fixes in for 4.3.8.Final, then I'll release that version. I'll
>> finish
>> > > these up on Tuesday.
>> > > Gail
>> > >
>> > > ----- Original Message -----
>> > > > From: "Gail Badner" <gbadner at redhat.com>
>> > > > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>> > > > Sent: Monday, January 5, 2015 1:10:08 PM
>> > > > Subject: [hibernate-dev] Preparing to release  4.3.8 and  4.2.17
>> > > >
>> > > > I'm getting ready to release 4.3.8 and 4.2.17. Please do not push
>> any new
>> > > > fixes until they are released.
>> > > >
>> > > > Thanks!
>> > > > Gail
>> > > > _______________________________________________
>> > > > 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
>> > >
>> >
>> >
>> >
>> > --
>> > Regards, Petar!
>> > Karlovo, Bulgaria.
>> > ---
>> > Public PGP Key at:
>> >
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> >
>>
>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From paranoiabla at gmail.com  Tue Jan  6 07:06:17 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Tue, 6 Jan 2015 14:06:17 +0200
Subject: [hibernate-dev] Preparing to release 4.3.8 and 4.2.17
In-Reply-To: <CAFm4XO2DornLrwKS0E4OLq4JsQPKDO7i7Ed2iF8WLvqOweiZmA@mail.gmail.com>
References: <338135314.4022546.1420492208445.JavaMail.zimbra@redhat.com>
	<233638682.4691371.1420533461682.JavaMail.zimbra@redhat.com>
	<CAKnbemXky2ZZ6qYvSYLBq9NGTiwY7f4VX-uPY32ZFA=aLkyRBg@mail.gmail.com>
	<15027560.4697003.1420534856853.JavaMail.zimbra@redhat.com>
	<CAKnbemUyMLAf6DzZ0mYnxYSvk+2y_cdr5FY3ow_kJ6CifTABxA@mail.gmail.com>
	<CAFm4XO2DornLrwKS0E4OLq4JsQPKDO7i7Ed2iF8WLvqOweiZmA@mail.gmail.com>
Message-ID: <CAKnbemVJ_9Cr79oWCiBmH05oBQ0WsRgWX17gSxQZ9cq+wAzxUA@mail.gmail.com>

Thank you all,

I'm using now the codestyles that were attached in the wiki and this time I
think it looks better. Here's the new pull-request

https://github.com/hibernate/hibernate-orm/pull/864

and I have also signed the CLA. My changes are really simple - I have added
2 new methods with delegate to the old ones and inside the old ones I have
added a null-check.

Cheers, Petar.

2015-01-06 13:25 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Hi Petar,
> we have different instructions for Eclipse or IntelliJ users; here you
> should find general contribution guidelines and also the code styles
> attached:
>  - https://developer.jboss.org/wiki/ContributingToHibernateUsingEclipse
>  - https://developer.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
>
> And another hint: while we'd love new patches to follow the formatting
> and style conventions, please never reformat existing code so that
> patches are as small as needed for the fix/feature.
> That makes it far easier to understand the patch, and possibly avoid
> some pain if eventually someone wants to port your fix to a different
> branch.
>
> Also, could you please sign the contributor's agreement?
>  https://cla.jboss.org -> pick "Hibernate" in the drop down menu.
>
> Thanks for your help!
>
> Sanne
>
> On 6 January 2015 at 09:50, Petar Tahchiev <paranoiabla at gmail.com> wrote:
> > Hi Gail,
> >
> > can you point me to the Hibernate code formatter file (for eclipse or
> > intellij idea)? I'm trying to find it but i cannot.
> >
> > 2015-01-06 11:00 GMT+02:00 Gail Badner <gbadner at redhat.com>:
> >
> >> Hi Peter,
> >>
> >> It looks like your pull request changed tabs to spaces, so there are a
> lot
> >> of diffs. I can't tell what exactly you changed. Please recreate the
> pull
> >> request without changing tabs to spaces.
> >>
> >> I'm sorry, this will not make it into 4.3.8. I'll consider it for 4.3.9.
> >>
> >> Regards,
> >> Gail
> >>
> >> ----- Original Message -----
> >> > From: "Petar Tahchiev" <paranoiabla at gmail.com>
> >> > To: "Gail Badner" <gbadner at redhat.com>
> >> > Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> >> > Sent: Tuesday, January 6, 2015 12:47:11 AM
> >> > Subject: Re: [hibernate-dev] Preparing to release 4.3.8 and 4.2.17
> >> >
> >> > Any chance to get this included
> >> > https://github.com/hibernate/hibernate-orm/pull/863 ?
> >> >
> >> >
> >> > 2015-01-06 10:37 GMT+02:00 Gail Badner <gbadner at redhat.com>:
> >> >
> >> > > I've finished building and taggind for 4.2.17.Final. I'm getting
> some
> >> > > final fixes in for 4.3.8.Final, then I'll release that version. I'll
> >> finish
> >> > > these up on Tuesday.
> >> > > Gail
> >> > >
> >> > > ----- Original Message -----
> >> > > > From: "Gail Badner" <gbadner at redhat.com>
> >> > > > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> >> > > > Sent: Monday, January 5, 2015 1:10:08 PM
> >> > > > Subject: [hibernate-dev] Preparing to release  4.3.8 and  4.2.17
> >> > > >
> >> > > > I'm getting ready to release 4.3.8 and 4.2.17. Please do not push
> >> any new
> >> > > > fixes until they are released.
> >> > > >
> >> > > > Thanks!
> >> > > > Gail
> >> > > > _______________________________________________
> >> > > > 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
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Regards, Petar!
> >> > Karlovo, Bulgaria.
> >> > ---
> >> > Public PGP Key at:
> >> >
> >>
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> >> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> >> >
> >>
> >
> >
> >
> > --
> > Regards, Petar!
> > Karlovo, Bulgaria.
> > ---
> > Public PGP Key at:
> >
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>



-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From gbadner at redhat.com  Tue Jan  6 21:33:46 2015
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 6 Jan 2015 21:33:46 -0500 (EST)
Subject: [hibernate-dev] Hibernate ORM 4.3.8.Final and 4.2.17.Final Released
In-Reply-To: <920650153.5610855.1420597994093.JavaMail.zimbra@redhat.com>
Message-ID: <324711526.5610947.1420598026797.JavaMail.zimbra@redhat.com>

For details, see http://in.relation.to/Bloggers/HibernateORM438FinalAnd4217FinalReleased.

Gail Badner
Red Hat, Hibernate ORM

From sanne at hibernate.org  Thu Jan  8 17:21:10 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 8 Jan 2015 22:21:10 +0000
Subject: [hibernate-dev] Slot name for modules of Hibernate OGM
Message-ID: <CAFm4XO0WLmoqo2w_DD5LET4X54YqXy4tyFuSsnZJxML-=g124w@mail.gmail.com>

I just noticed that the main module for Hibernate OGM has slot="ogm",
while the various dialect extension modules use the "main" slot.

My understanding is that "main" should be reserved for the version
included in a specific application server version, so we'd better
avoid it to make it possible to eventually include OGM in WildFly and
still be able to differentiate versions.

The "ogm" slot also doesn't make it possible to use multiple versions,
which is ok now that there's a single release but won't be
sustainable.

Could we use the same label for all modules in a specific release, and
encode version in it too?
I propose using "ogm-{Major.Minor.Micro}".

Using the ".Micro" postfix might seem overzealous as micro versions
are supposed to be drop-in compatible but I'd rather be safe and be
able to be explicit; we could in addition provide an alias like we do
with Hibernate Search and Infinispan; this seems to be working quite
well so far.
Such an alias deploys a module which defines for say "ogm-4.1" should
look for "ogm-4.1.1": then applications can generally refer to
"ogm-4.1" and let the alias resolve it, or be more explicit if they
like so.

Sanne

From davide at hibernate.org  Fri Jan  9 04:39:08 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Fri, 9 Jan 2015 09:39:08 +0000
Subject: [hibernate-dev] Slot name for modules of Hibernate OGM
In-Reply-To: <CAFm4XO0WLmoqo2w_DD5LET4X54YqXy4tyFuSsnZJxML-=g124w@mail.gmail.com>
References: <CAFm4XO0WLmoqo2w_DD5LET4X54YqXy4tyFuSsnZJxML-=g124w@mail.gmail.com>
Message-ID: <CANoTJYP5ABGFpUHA=-r6exLNAoZzpwiOasS=3trFbSm_MGS-+Q@mail.gmail.com>

+1
There is already a JIRA open to rename the module:
https://hibernate.atlassian.net/browse/OGM-698

We can update it with more details.

On Thu, Jan 8, 2015 at 10:21 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> I just noticed that the main module for Hibernate OGM has slot="ogm",
> while the various dialect extension modules use the "main" slot.
>
> My understanding is that "main" should be reserved for the version
> included in a specific application server version, so we'd better
> avoid it to make it possible to eventually include OGM in WildFly and
> still be able to differentiate versions.
>
> The "ogm" slot also doesn't make it possible to use multiple versions,
> which is ok now that there's a single release but won't be
> sustainable.
>
> Could we use the same label for all modules in a specific release, and
> encode version in it too?
> I propose using "ogm-{Major.Minor.Micro}".
>
> Using the ".Micro" postfix might seem overzealous as micro versions
> are supposed to be drop-in compatible but I'd rather be safe and be
> able to be explicit; we could in addition provide an alias like we do
> with Hibernate Search and Infinispan; this seems to be working quite
> well so far.
> Such an alias deploys a module which defines for say "ogm-4.1" should
> look for "ogm-4.1.1": then applications can generally refer to
> "ogm-4.1" and let the alias resolve it, or be more explicit if they
> like so.
>
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Fri Jan  9 04:56:01 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 9 Jan 2015 10:56:01 +0100
Subject: [hibernate-dev] Slot name for modules of Hibernate OGM
In-Reply-To: <CAFm4XO0WLmoqo2w_DD5LET4X54YqXy4tyFuSsnZJxML-=g124w@mail.gmail.com>
References: <CAFm4XO0WLmoqo2w_DD5LET4X54YqXy4tyFuSsnZJxML-=g124w@mail.gmail.com>
Message-ID: <CADGJaX_ng=DNcBroyjbQiRKAQvi67BPJVzEo52wiwjYkWFNsKA@mail.gmail.com>

2015-01-08 23:21 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> I just noticed that the main module for Hibernate OGM has slot="ogm",
> while the various dialect extension modules use the "main" slot.
>

I think this stems from the fact that we just use "org.hibernate" as module
name which conflicts with the ORM module. I'd like to use
"org.hibernate.ogm" instead, because OGM is no special version of ORM (as
indicated by the current name/slot) but a separate project.

Any change to this needs to be synched with Scott / JipiJapa because IIRC
there is some code relying on this very name / slot.

My understanding is that "main" should be reserved for the version
> included in a specific application server version, so we'd better
> avoid it to make it possible to eventually include OGM in WildFly and
> still be able to differentiate versions.
>

Yes, should OGM ever be part of WF, it'd be nice to be able to control
whether bringing in a new OGM version just is added (and referable via its
specific slot value) or whether its supposed to update whatever "main" is
at this point. I can see both being useful.

The "ogm" slot also doesn't make it possible to use multiple versions,
> which is ok now that there's a single release but won't be
> sustainable.
>
> Could we use the same label for all modules in a specific release, and
> encode version in it too?
> I propose using "ogm-{Major.Minor.Micro}".
>
> Using the ".Micro" postfix might seem overzealous as micro versions
> are supposed to be drop-in compatible but I'd rather be safe and be
> able to be explicit; we could in addition provide an alias like we do
> with Hibernate Search and Infinispan; this seems to be working quite
> well so far.
> Such an alias deploys a module which defines for say "ogm-4.1" should
> look for "ogm-4.1.1": then applications can generally refer to
> "ogm-4.1" and let the alias resolve it, or be more explicit if they
> like so.
>

The aliasing is a nice idea.

Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri Jan  9 05:26:57 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 9 Jan 2015 10:26:57 +0000
Subject: [hibernate-dev] Slot name for modules of Hibernate OGM
In-Reply-To: <CADGJaX_ng=DNcBroyjbQiRKAQvi67BPJVzEo52wiwjYkWFNsKA@mail.gmail.com>
References: <CAFm4XO0WLmoqo2w_DD5LET4X54YqXy4tyFuSsnZJxML-=g124w@mail.gmail.com>
	<CADGJaX_ng=DNcBroyjbQiRKAQvi67BPJVzEo52wiwjYkWFNsKA@mail.gmail.com>
Message-ID: <CAFm4XO21HpQuN8YiM4jojD7EUU18jT_c3NBbMZ1k8cFL27LVFw@mail.gmail.com>

On 9 January 2015 at 09:56, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2015-01-08 23:21 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> I just noticed that the main module for Hibernate OGM has slot="ogm",
>> while the various dialect extension modules use the "main" slot.

Good point. So let's use "org.hibernate.ogm" slot="4.1.1." for the next release,
and optionally add an alias as well to overwrite slot "4.1".

>
> I think this stems from the fact that we just use "org.hibernate" as module
> name which conflicts with the ORM module. I'd like to use
> "org.hibernate.ogm" instead, because OGM is no special version of ORM (as
> indicated by the current name/slot) but a separate project.
>
> Any change to this needs to be synched with Scott / JipiJapa because IIRC
> there is some code relying on this very name / slot.
>
>> My understanding is that "main" should be reserved for the version
>> included in a specific application server version, so we'd better
>> avoid it to make it possible to eventually include OGM in WildFly and
>> still be able to differentiate versions.
>
>
> Yes, should OGM ever be part of WF, it'd be nice to be able to control
> whether bringing in a new OGM version just is added (and referable via its
> specific slot value) or whether its supposed to update whatever "main" is at
> this point. I can see both being useful.
>
>> The "ogm" slot also doesn't make it possible to use multiple versions,
>> which is ok now that there's a single release but won't be
>> sustainable.
>>
>> Could we use the same label for all modules in a specific release, and
>> encode version in it too?
>> I propose using "ogm-{Major.Minor.Micro}".
>>
>> Using the ".Micro" postfix might seem overzealous as micro versions
>> are supposed to be drop-in compatible but I'd rather be safe and be
>> able to be explicit; we could in addition provide an alias like we do
>> with Hibernate Search and Infinispan; this seems to be working quite
>> well so far.
>> Such an alias deploys a module which defines for say "ogm-4.1" should
>> look for "ogm-4.1.1": then applications can generally refer to
>> "ogm-4.1" and let the alias resolve it, or be more explicit if they
>> like so.
>
>
> The aliasing is a nice idea.
>
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From gunnar at hibernate.org  Fri Jan  9 05:33:49 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 9 Jan 2015 11:33:49 +0100
Subject: [hibernate-dev] Slot name for modules of Hibernate OGM
In-Reply-To: <CAFm4XO21HpQuN8YiM4jojD7EUU18jT_c3NBbMZ1k8cFL27LVFw@mail.gmail.com>
References: <CAFm4XO0WLmoqo2w_DD5LET4X54YqXy4tyFuSsnZJxML-=g124w@mail.gmail.com>
	<CADGJaX_ng=DNcBroyjbQiRKAQvi67BPJVzEo52wiwjYkWFNsKA@mail.gmail.com>
	<CAFm4XO21HpQuN8YiM4jojD7EUU18jT_c3NBbMZ1k8cFL27LVFw@mail.gmail.com>
Message-ID: <CADGJaX8MSnL2kCHGc748=J9DJ4FJ4vyZkU2D893d=e8ich-cGg@mail.gmail.com>

2015-01-09 11:26 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> On 9 January 2015 at 09:56, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2015-01-08 23:21 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> I just noticed that the main module for Hibernate OGM has slot="ogm",
> >> while the various dialect extension modules use the "main" slot.
>
> Good point. So let's use "org.hibernate.ogm" slot="4.1.1." for the next
> release,
> and optionally add an alias as well to overwrite slot "4.1".
>

Would you really change it in a micro release? When discussing the matter
in OGM-698, we came to the conclusion it should be 4.2 so not to be too
disruptive. It's a bit like changing a Maven group id in a micro release,
that'd come to the surprise of many people.


> >
> > I think this stems from the fact that we just use "org.hibernate" as
> module
> > name which conflicts with the ORM module. I'd like to use
> > "org.hibernate.ogm" instead, because OGM is no special version of ORM (as
> > indicated by the current name/slot) but a separate project.
> >
> > Any change to this needs to be synched with Scott / JipiJapa because IIRC
> > there is some code relying on this very name / slot.
> >
> >> My understanding is that "main" should be reserved for the version
> >> included in a specific application server version, so we'd better
> >> avoid it to make it possible to eventually include OGM in WildFly and
> >> still be able to differentiate versions.
> >
> >
> > Yes, should OGM ever be part of WF, it'd be nice to be able to control
> > whether bringing in a new OGM version just is added (and referable via
> its
> > specific slot value) or whether its supposed to update whatever "main"
> is at
> > this point. I can see both being useful.
> >
> >> The "ogm" slot also doesn't make it possible to use multiple versions,
> >> which is ok now that there's a single release but won't be
> >> sustainable.
> >>
> >> Could we use the same label for all modules in a specific release, and
> >> encode version in it too?
> >> I propose using "ogm-{Major.Minor.Micro}".
> >>
> >> Using the ".Micro" postfix might seem overzealous as micro versions
> >> are supposed to be drop-in compatible but I'd rather be safe and be
> >> able to be explicit; we could in addition provide an alias like we do
> >> with Hibernate Search and Infinispan; this seems to be working quite
> >> well so far.
> >> Such an alias deploys a module which defines for say "ogm-4.1" should
> >> look for "ogm-4.1.1": then applications can generally refer to
> >> "ogm-4.1" and let the alias resolve it, or be more explicit if they
> >> like so.
> >
> >
> > The aliasing is a nice idea.
> >
> >> Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>

From sanne at hibernate.org  Fri Jan  9 06:25:42 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 9 Jan 2015 11:25:42 +0000
Subject: [hibernate-dev] Slot name for modules of Hibernate OGM
In-Reply-To: <CADGJaX8MSnL2kCHGc748=J9DJ4FJ4vyZkU2D893d=e8ich-cGg@mail.gmail.com>
References: <CAFm4XO0WLmoqo2w_DD5LET4X54YqXy4tyFuSsnZJxML-=g124w@mail.gmail.com>
	<CADGJaX_ng=DNcBroyjbQiRKAQvi67BPJVzEo52wiwjYkWFNsKA@mail.gmail.com>
	<CAFm4XO21HpQuN8YiM4jojD7EUU18jT_c3NBbMZ1k8cFL27LVFw@mail.gmail.com>
	<CADGJaX8MSnL2kCHGc748=J9DJ4FJ4vyZkU2D893d=e8ich-cGg@mail.gmail.com>
Message-ID: <CAFm4XO3+S8E4Ymm+FOzz1nvPmDj_rDd7rEe7q9_oV2kv2nsW2A@mail.gmail.com>

On 9 January 2015 at 10:33, Gunnar Morling <gunnar at hibernate.org> wrote:
>
>
> 2015-01-09 11:26 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> On 9 January 2015 at 09:56, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > 2015-01-08 23:21 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>
>> >> I just noticed that the main module for Hibernate OGM has slot="ogm",
>> >> while the various dialect extension modules use the "main" slot.
>>
>> Good point. So let's use "org.hibernate.ogm" slot="4.1.1." for the next
>> release,
>> and optionally add an alias as well to overwrite slot "4.1".
>
>
> Would you really change it in a micro release? When discussing the matter in
> OGM-698, we came to the conclusion it should be 4.2 so not to be too
> disruptive. It's a bit like changing a Maven group id in a micro release,
> that'd come to the surprise of many people.

I'm not trying to push this as a priorty, just something we better do
soon than late as people get used to ids and will be in trouble as
soon as we'll have multiple stable versions available.

It's not the same as Maven since you can drop an alias to keep
backwards compatibility.

>
>>
>> >
>> > I think this stems from the fact that we just use "org.hibernate" as
>> > module
>> > name which conflicts with the ORM module. I'd like to use
>> > "org.hibernate.ogm" instead, because OGM is no special version of ORM
>> > (as
>> > indicated by the current name/slot) but a separate project.
>> >
>> > Any change to this needs to be synched with Scott / JipiJapa because
>> > IIRC
>> > there is some code relying on this very name / slot.
>> >
>> >> My understanding is that "main" should be reserved for the version
>> >> included in a specific application server version, so we'd better
>> >> avoid it to make it possible to eventually include OGM in WildFly and
>> >> still be able to differentiate versions.
>> >
>> >
>> > Yes, should OGM ever be part of WF, it'd be nice to be able to control
>> > whether bringing in a new OGM version just is added (and referable via
>> > its
>> > specific slot value) or whether its supposed to update whatever "main"
>> > is at
>> > this point. I can see both being useful.
>> >
>> >> The "ogm" slot also doesn't make it possible to use multiple versions,
>> >> which is ok now that there's a single release but won't be
>> >> sustainable.
>> >>
>> >> Could we use the same label for all modules in a specific release, and
>> >> encode version in it too?
>> >> I propose using "ogm-{Major.Minor.Micro}".
>> >>
>> >> Using the ".Micro" postfix might seem overzealous as micro versions
>> >> are supposed to be drop-in compatible but I'd rather be safe and be
>> >> able to be explicit; we could in addition provide an alias like we do
>> >> with Hibernate Search and Infinispan; this seems to be working quite
>> >> well so far.
>> >> Such an alias deploys a module which defines for say "ogm-4.1" should
>> >> look for "ogm-4.1.1": then applications can generally refer to
>> >> "ogm-4.1" and let the alias resolve it, or be more explicit if they
>> >> like so.
>> >
>> >
>> > The aliasing is a nice idea.
>> >
>> >> Sanne
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>
>

From smarlow at redhat.com  Fri Jan  9 10:35:00 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 09 Jan 2015 10:35:00 -0500
Subject: [hibernate-dev] Slot name for modules of Hibernate OGM
In-Reply-To: <CAFm4XO0WLmoqo2w_DD5LET4X54YqXy4tyFuSsnZJxML-=g124w@mail.gmail.com>
References: <CAFm4XO0WLmoqo2w_DD5LET4X54YqXy4tyFuSsnZJxML-=g124w@mail.gmail.com>
Message-ID: <54AFF524.8050203@redhat.com>

Not a big deal to change the WildFly default which is in code, since we 
don't have a suitable configuration file for the setting.

We should update 
org.jboss.as.jpa.config.Configuration.PROVIDER_MODULE_HIBERNATE_OGM, 
which currently is set to "org.hibernate:ogm".  WildFly 8.x is already 
final, so WildFly 9.0 would be the place to make this minor change.

On 01/08/2015 05:21 PM, Sanne Grinovero wrote:
> I just noticed that the main module for Hibernate OGM has slot="ogm",
> while the various dialect extension modules use the "main" slot.
>
> My understanding is that "main" should be reserved for the version
> included in a specific application server version, so we'd better
> avoid it to make it possible to eventually include OGM in WildFly and
> still be able to differentiate versions.
>
> The "ogm" slot also doesn't make it possible to use multiple versions,
> which is ok now that there's a single release but won't be
> sustainable.
>
> Could we use the same label for all modules in a specific release, and
> encode version in it too?
> I propose using "ogm-{Major.Minor.Micro}".

I hate seeing the micro version, but if that can be ignored by users, as 
you suggest, by using the "ogm-{Major.Minor}" instead, not a big deal to 
me.  The hate comes from my past experience with dynamic link modules 
that changed module names like the wind (some database companies did 
this in the past).

Having said that, do what you want but it could be a pita for other 
static modules that need to depend on OGM.

>
> Using the ".Micro" postfix might seem overzealous as micro versions
> are supposed to be drop-in compatible but I'd rather be safe and be
> able to be explicit; we could in addition provide an alias like we do
> with Hibernate Search and Infinispan; this seems to be working quite
> well so far.
> Such an alias deploys a module which defines for say "ogm-4.1" should
> look for "ogm-4.1.1": then applications can generally refer to
> "ogm-4.1" and let the alias resolve it, or be more explicit if they
> like so.

The alias is static, so nothing is looked for.  I don't think anyone 
thinks otherwise but wanted to be clear, that no search is performed. 
By no search, I mean we do not look for a set of possible "ogm-4.1.*" 
matches, instead the "ogm-4.1" alias is hard coded to reference a 
specific "ogm-4.1.minor".

>
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri Jan  9 13:57:27 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 9 Jan 2015 18:57:27 +0000
Subject: [hibernate-dev] GSOC ideas
Message-ID: <CAFm4XO2i+74ayWZJBi2v7RXzADereA=3rRjx5Zjr=t1+Y8BqAg@mail.gmail.com>

Do we have any suggestion for Google Summer of Code ideas?
We might be able to get sponsored (paid) students; as usual it's hard
to find tasks at the right level of difficulty.

For example, I'd love to get some help in the Solr/ElasticSearch
integration area but it would need to be a very good student for that.

My ideas so far:
 # Migration of our new JPQL parser to latest ANTLR version (as an experiment)
 # JBoss Forge integration for Hibernate Search
 # CDI extensions
 # New Faceting engine
 # Automated performance regressions tests (develop benchmarks & setup
infrastructure)
 # Taking advantage of efficient loading profiles (the JPA 2.1
feature): auto-generate the ones Search needs

We also need volunteers to mentor students in this area;
I'm happy to take one, but can't survive taking more :)

Sanne

From sanne at hibernate.org  Mon Jan 12 06:28:47 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 12 Jan 2015 11:28:47 +0000
Subject: [hibernate-dev] Two more Hibernate Search releases
Message-ID: <CAFm4XO00c4q4+F2ZDpMYgM5AW8GPOErLwFQHZXPW-XO2rxF=mw@mail.gmail.com>

Hello all,
today two more Hibernate Search releases are available:
 - Hibernate Search 5.0.1.Final
 - Hibernate Search 4.5.3.Final

More details:
http://in.relation.to/Bloggers/SomeMoreHibernateSearch5

Regards,
Sanne

From emmanuel at hibernate.org  Tue Jan 13 08:29:57 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 13 Jan 2015 14:29:57 +0100
Subject: [hibernate-dev] GSOC ideas
In-Reply-To: <CAFm4XO2i+74ayWZJBi2v7RXzADereA=3rRjx5Zjr=t1+Y8BqAg@mail.gmail.com>
References: <CAFm4XO2i+74ayWZJBi2v7RXzADereA=3rRjx5Zjr=t1+Y8BqAg@mail.gmail.com>
Message-ID: <0073582D-5D48-43B3-B97A-0981EE7D93C7@hibernate.org>


> On 09 Jan 2015, at 19:57, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> # JBoss Forge integration for Hibernate Search
> # CDI extensions
> # Taking advantage of efficient loading profiles (the JPA 2.1
> feature): auto-generate the ones Search needs

I quite like these three. Especially the first two.

From emmanuel at hibernate.org  Tue Jan 13 12:06:26 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 13 Jan 2015 18:06:26 +0100
Subject: [hibernate-dev] [OGM] Store objects as actual typed objects via the
	native grid format
Message-ID: <F453D8DC-C273-40F9-B5E6-6479BA0A5A91@hibernate.org>

In the forum came an interesting proposal for Hibernate OGM.
https://forum.hibernate.org/viewtopic.php?f=31&t=1037739&sid=9ee9d4772ac6dfaa67a37ec02b2c330c&p=2482498#p2482498

Today I think OGM works quite well for document store and even Neo4J because they don?t have any schema and thus we can store the data in a natural fashion.

For k/v stores, it is so flexible that OGM imposes its tuple structure to represent the object. This is good enough but has a few drawbacks:

- to read the data back you need the OGM classes around or at least how they are structured
- being detyped, they tend to be hard to query by the k/v query capability
- we store more data than we could as we copy the column names in each entry

Some k/v stores do have the notion of ?schema?. Infinispan uses Protobuf and ask the user t provide the proto schema. Coherence and Hazelcast uses the Portable Object Format (invented by the coherence guys AFAIK). Hibernate OGM makes no use of these. We could use these schema to express the Tuple (which is essentially a Map) but that?s not what people are looking for I think.

What people are looking for is a way to defined a set of schemas (protobuf or POF) corresponding to the entities and have OGM use the schema to store a given serialized entity. This solves the problems above, in particular the capability to use the native query options of the k/v store and the compactness.

I can see that being conceptually possible as long as we ignore associations. The schema would describe the properties, even the embeddable and collection of embeddable objects. As long as these ?schema? library let us write the data in a untyped fashion, something akin to:

    entityStructure = schemaLib.as(schemaId);
    entityStructure.putProperty(?firstname?, tuple.get(?firstname?) );
    addressStructure = entityStructure.addNestedObject(?address?);
    addressStructure.addProperty(?city?, tuple.get(?address.city?) );
    

Note that the user here (see question c), also asks for the ability to denormalize the data and store a full object graph as one key and only a subset as a second key which is something we want to do but that we don?t have right now.

Thoughts?

Emmanuel

From emmanuel at hibernate.org  Tue Jan 13 12:24:31 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 13 Jan 2015 18:24:31 +0100
Subject: [hibernate-dev] [OGM] Store objects as actual typed objects via
	the native grid format
In-Reply-To: <F453D8DC-C273-40F9-B5E6-6479BA0A5A91@hibernate.org>
References: <F453D8DC-C273-40F9-B5E6-6479BA0A5A91@hibernate.org>
Message-ID: <0EF9C65F-7F2F-4250-9EA8-F43DA5D20371@hibernate.org>


> On 13 Jan 2015, at 18:06, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
> Note that the user here (see question c), also asks for the ability to denormalize the data and store a full object graph as one key and only a subset as a second key which is something we want to do but that we don?t have right now.

Actually, even that could be done by an ad-hoc dialect which would store the full entity graph in one schema / cache and the normal (according to OGM) entity in another schema/cache. The Dialect does not give you the entity graph but since we now know how to batch work, we could apply all changes on the virtual entry about to be persisted. This is essentially what we do in MongoDB?s dialect that we could replicate here.

Also, the POF(s) / Protobuf(s) for a given entity could be defined via the option system at the entity level

    @Entity @UsingSchema(?someSchemaId?)
    public Foo { ? }

How to chose one vs the other at query time (via OGM) is what we are the farthest from I suspect.

Emmanuel

From gunnar at hibernate.org  Tue Jan 13 13:18:15 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 13 Jan 2015 19:18:15 +0100
Subject: [hibernate-dev] [OGM] Transaction type "RESOURCE_LOCAL",
	still JTA is required
Message-ID: <CADGJaX9WiH0mxHf3uTHED_=3dyoDJKF19-goRs5LfunizwSqsA@mail.gmail.com>

Hi,

For a demo I have an OGM application which defines a persistence unit with
transaction type RESOURCE_LOCAL.

I thus assumed I wouldn't have to add a JTA implementation to the class
path, but actually I'm getting a CNFE (see [1] for the complete trace):

    ClassNotFoundException: Could not load requested class :
com.arjuna.ats.jta.TransactionManager

Indeed Arjuna is what we use as TM by default. It is set by OGM's
JtaPlatform implementation which in turn is used by transactions created by
OGM's default TransactionFactory [2].

Unless I'm doing something wrong configuration-wise, I feel that requiring
a JTA implementation for a non-transactional backend such as MongoDB is
confusing and may make users ask whether OGM is doing the right thing.

Would it be feasible to to provide an "OGM local" TransactionImplementor +
TransactionFactory to be used in such cases where the store does not
support transactions (so no rollbacks etc.), but we'd "only" need a trigger
for writing out changes to the datastore?

Any thoughts?

--Gunnar

[1] https://gist.github.com/gunnarmorling/ba193caecb7d5cdbd0a4
[2]
https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/transaction/impl/OgmTransactionFactoryInitiator.java#L42

From steve at hibernate.org  Tue Jan 13 13:43:37 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 13 Jan 2015 12:43:37 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
Message-ID: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>

As I am working on 5.0, one of the things I am trying to accomplish is to
make the handling of table/column names more consistent and better
defined.  The first step in that is to properly define the terms used often
throughout the codebase.

The first level of naming is the "given" name of a table/column.  The given
name might be:
* explicit - explicitly specified by the user, as in @Table(
name="explicit_name" )
* implicit - not explicitly specified by the user and thus implicitly
determined (by JPA rules, "naming strategy", etc).

Next, we have a logical name which is a normalized form of the "given"
name.  This is the form used to reference tables/columns internally.  E.g.,
its how we resolve @Column(..., table="xyz").  More on this form later.

Finally we have the physical name of the thing, which is the actual name of
the table/column in the database.  Again, this is generally a normalization
of the given name based on Dialect, "naming strategy", etc.

Today, we have a very messy concept called a NamingStrategy.  I say it is
messy because it tries to combine unrelated concerns.  So I still plan to
split this as I have outlined elsewhere into:
1) ImplicitNamingStrategy
2) PhysicalNamingStrategy

Which brings up my first question to y'all.  Do we need a contract for
LogicalNamingStrategy?  As I have said, the logical names are the things
used to resolve references.  Allowing people to plug in custom strategies
for how that normalization works could be very dangerous.  But even more
than that, is it really interesting to be able to hook into that process?

Historically, these names are all represented by String.  So I also propose
to shift this to use that Identifier class we developed for the metamodel
redesign.  For those that may be unfamiliar, it essentially combines the
String name with a "quoted" boolean:

public class Identifier {
  private final String text;
  private final boolean isQuoted;
    ...
}

Table names, then, are an aggregation of 3 Identifiers: one for catalog,
one for schema, one for table name.  Same for named constraints
(ultimately, which is part of a improvement for 6.0 to allow indexes,
constraints, etc to be created in a separate schema from tables).

Since a major goal for 5.0 is to continue to use the org.hibernate.mapping
package as the representation of the mapping information, we obviously want
to minimize changes there to only what is completely essential.  To that
end, if we are going to use Identifier over String stuff in the
org.hibernate.mapping package will need to deal with both; internally they
will hold the Identifier and use that to implement the String-based
name-related methods they expose.

Lastly I wanted to discuss the details of the logical names.  For tables,
we currently qualify the table name with the catalog/schema info.  There is
a mismatch in this regard when it comes to remaining a pure JPA
implementation.  Consider @Column( ..., table="some_table").  Ultimately we
need to be able to qualify that with catalog/schema in order to be able to
construct a matching logical name (to be able to pair that with the
referenced org.hibernate.mapping.Table later).  This is trivial when table
names are unique across all the catalogs/schemas (when there is only one
"some_table" in all the mapped catalogs/schemas).  But is poses a problem
when the same table name is used from different schemas (e.g., when
"some_table" is mapped from both "schema1" and "schema2").  So we have a
choice.  Since JPA does not say what is legal/illegal for the @Column.table
attribute, it is feasible for us to allow @Column.table to contain the
catalog/schema information in these cases as a selector.  The only other
option I can see is to define a limitation that says that a table name must
be unique for a given entity across all catalogs/schemas.  I don't think
that is generally a restrictive limitation.  What are y'alls thoughts?
Perhaps this is one argument for allowing pluggable LogicalNamingStrategy?

From steve at hibernate.org  Tue Jan 13 13:49:17 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 13 Jan 2015 12:49:17 -0600
Subject: [hibernate-dev] [OGM] Transaction type "RESOURCE_LOCAL",
 still JTA is required
In-Reply-To: <CADGJaX9WiH0mxHf3uTHED_=3dyoDJKF19-goRs5LfunizwSqsA@mail.gmail.com>
References: <CADGJaX9WiH0mxHf3uTHED_=3dyoDJKF19-goRs5LfunizwSqsA@mail.gmail.com>
Message-ID: <CAFdSV9u8nHCYF=FBMu5OFWq36utVepqPPkGfruj+h0HCut843g@mail.gmail.com>

You'd need to not specify the JtaPlatform service stuff.

On Tue, Jan 13, 2015 at 12:18 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> For a demo I have an OGM application which defines a persistence unit with
> transaction type RESOURCE_LOCAL.
>
> I thus assumed I wouldn't have to add a JTA implementation to the class
> path, but actually I'm getting a CNFE (see [1] for the complete trace):
>
>     ClassNotFoundException: Could not load requested class :
> com.arjuna.ats.jta.TransactionManager
>
> Indeed Arjuna is what we use as TM by default. It is set by OGM's
> JtaPlatform implementation which in turn is used by transactions created by
> OGM's default TransactionFactory [2].
>
> Unless I'm doing something wrong configuration-wise, I feel that requiring
> a JTA implementation for a non-transactional backend such as MongoDB is
> confusing and may make users ask whether OGM is doing the right thing.
>
> Would it be feasible to to provide an "OGM local" TransactionImplementor +
> TransactionFactory to be used in such cases where the store does not
> support transactions (so no rollbacks etc.), but we'd "only" need a trigger
> for writing out changes to the datastore?
>
> Any thoughts?
>
> --Gunnar
>
> [1] https://gist.github.com/gunnarmorling/ba193caecb7d5cdbd0a4
> [2]
>
> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/transaction/impl/OgmTransactionFactoryInitiator.java#L42
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Tue Jan 13 16:03:40 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 13 Jan 2015 21:03:40 +0000
Subject: [hibernate-dev] [OGM] Store objects as actual typed objects via
 the native grid format
In-Reply-To: <0EF9C65F-7F2F-4250-9EA8-F43DA5D20371@hibernate.org>
References: <F453D8DC-C273-40F9-B5E6-6479BA0A5A91@hibernate.org>
	<0EF9C65F-7F2F-4250-9EA8-F43DA5D20371@hibernate.org>
Message-ID: <CAFm4XO2kcRStp9UvHLPvJiTORbFPRK_jMFbBx6TiSxv7Z25rjQ@mail.gmail.com>

Many interesting ideas.

Is the culprit not simply to be able to store the same entry into
multiple (different) representations?
I'd like to see the separation into "different representations" not
being handled at the level of the dialect but higher up at level of
OGM/ORM core, so that one could have - for example - some entities
stored into a relational database, some other entities into MongoDB,
and some entities into *both*.
So configuration wise I'd have a section for each dialect, and then a
way to tag each entity - possibly multiple times - to have then
included into one of the configured databases.

You'd have two consequences:
 - you can have multiple instances of the same dialect type - for
example two Coherence instances using a different POF encoding
strategies
 - the Query engine can pick the best strategy among all storage
options, across both differences of representation into the same
database but also across query technologies / capabilities

    @Entity @PersistenceGroup(?mongo-cluster-of-foos?, "cassandra-times")
    public Foo { ? }

A limitation is that I'd probably want to be able to mark various
additional mapping annotations as belonging to a specific database
only. For example I think a relation annotation like @ManyToOne should
be the same on all - as it's related to the structure of the Java
domain model - but other annotations such as @Column would need to
have a qualifier so I can pick multiple different ones. The obvious
solution is that such mapping solutions need to be externalized into
mapping files (exclusively).
In practice this might not be a too strong limitation, in all places
I've worked the "@Column" annotation was the quick and dirty solution
but people would prefer to make a corporate standard NamingStrategy
which would consolidate such decisions out of the model.

However you decide on those, the Query execution would need the smart
planner we've fantasized about a bit.

Somehow related: remember Adrian Nistor from the Infinispan team
developed a mapping tool based on annotations to map POJOs to
Protobuf. This is ready for general usage now, and could be useful
here.

-- Sanne



On 13 January 2015 at 17:24, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
>> On 13 Jan 2015, at 18:06, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>
>> Note that the user here (see question c), also asks for the ability to denormalize the data and store a full object graph as one key and only a subset as a second key which is something we want to do but that we don?t have right now.
>
> Actually, even that could be done by an ad-hoc dialect which would store the full entity graph in one schema / cache and the normal (according to OGM) entity in another schema/cache. The Dialect does not give you the entity graph but since we now know how to batch work, we could apply all changes on the virtual entry about to be persisted. This is essentially what we do in MongoDB?s dialect that we could replicate here.
>
> Also, the POF(s) / Protobuf(s) for a given entity could be defined via the option system at the entity level
>
>     @Entity @UsingSchema(?someSchemaId?)
>     public Foo { ? }
>
> How to chose one vs the other at query time (via OGM) is what we are the farthest from I suspect.
>
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Tue Jan 13 16:30:29 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 13 Jan 2015 21:30:29 +0000
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
Message-ID: <CAFm4XO0C187F6j6w6z2z2oi7tugWRo6+7CDe76amPMKGfuyN4Q@mail.gmail.com>

Funny I just praised the "NamingStrategy" in the OGM thread. So I
agree people badly want to specify their own "physical" naming
strategy but I don't see any value into making the logical
representation pluggable.
It's probably important to make sure all code uses the same thing
anyway for consistency; so I'd make it public so that extending
frameworks / advanced tooling can comply to the same rules but not
public as in a replaceable component.

If we agree on that, the user will probably not be aware of us using a
logical strategy which is different. So I'd hope we could keep the
"NamingStrategy" name to mean the physical one? Because that's how
what a lot of people call it today.

Great idea to use typesafety like the Indentifier. But could you make
it an interface instead? The presence of the boolean will otherwise
double the size of the object in memory (24 bytes instead of 12), so
I'd hope that we could actually use two different implementations. I'm
assuming we'll have many such Identifier instances around. N.B. even
in the case of just 12 bytes, it's 12 bytes on top of those of the
pure-string representation.. but probably worth it in terms of better
code.

public interface Identifier {
   String getText();
   boolean isQuoted();
   QuotedIdentifier quote(); //optional: we could add this if you
think it's going to be a common operation as we'd be able to reuse the
instances.
   UnquotedIdentifier unquote(); //as above
}

public interface QuotedIdentifier extends Identifier {
...

I'm a bit lost about the LogicalNaming proposal. Why do these need to
be strings at all?
I think I'd organize them into some form of immutable matrix and then
use them primarily based on references. The elements of the matrix
would possibly be able to have nice debug-friendly toString
implementations and possibly render the physical names as well so that
users - aware only of the physical representation - aren't completely
clueless when reading errors in logs.
But I probably missed the purpose.

Sanne

On 13 January 2015 at 18:43, Steve Ebersole <steve at hibernate.org> wrote:
> As I am working on 5.0, one of the things I am trying to accomplish is to
> make the handling of table/column names more consistent and better
> defined.  The first step in that is to properly define the terms used often
> throughout the codebase.
>
> The first level of naming is the "given" name of a table/column.  The given
> name might be:
> * explicit - explicitly specified by the user, as in @Table(
> name="explicit_name" )
> * implicit - not explicitly specified by the user and thus implicitly
> determined (by JPA rules, "naming strategy", etc).
>
> Next, we have a logical name which is a normalized form of the "given"
> name.  This is the form used to reference tables/columns internally.  E.g.,
> its how we resolve @Column(..., table="xyz").  More on this form later.
>
> Finally we have the physical name of the thing, which is the actual name of
> the table/column in the database.  Again, this is generally a normalization
> of the given name based on Dialect, "naming strategy", etc.
>
> Today, we have a very messy concept called a NamingStrategy.  I say it is
> messy because it tries to combine unrelated concerns.  So I still plan to
> split this as I have outlined elsewhere into:
> 1) ImplicitNamingStrategy
> 2) PhysicalNamingStrategy
>
> Which brings up my first question to y'all.  Do we need a contract for
> LogicalNamingStrategy?  As I have said, the logical names are the things
> used to resolve references.  Allowing people to plug in custom strategies
> for how that normalization works could be very dangerous.  But even more
> than that, is it really interesting to be able to hook into that process?
>
> Historically, these names are all represented by String.  So I also propose
> to shift this to use that Identifier class we developed for the metamodel
> redesign.  For those that may be unfamiliar, it essentially combines the
> String name with a "quoted" boolean:
>
> public class Identifier {
>   private final String text;
>   private final boolean isQuoted;
>     ...
> }
>
> Table names, then, are an aggregation of 3 Identifiers: one for catalog,
> one for schema, one for table name.  Same for named constraints
> (ultimately, which is part of a improvement for 6.0 to allow indexes,
> constraints, etc to be created in a separate schema from tables).
>
> Since a major goal for 5.0 is to continue to use the org.hibernate.mapping
> package as the representation of the mapping information, we obviously want
> to minimize changes there to only what is completely essential.  To that
> end, if we are going to use Identifier over String stuff in the
> org.hibernate.mapping package will need to deal with both; internally they
> will hold the Identifier and use that to implement the String-based
> name-related methods they expose.
>
> Lastly I wanted to discuss the details of the logical names.  For tables,
> we currently qualify the table name with the catalog/schema info.  There is
> a mismatch in this regard when it comes to remaining a pure JPA
> implementation.  Consider @Column( ..., table="some_table").  Ultimately we
> need to be able to qualify that with catalog/schema in order to be able to
> construct a matching logical name (to be able to pair that with the
> referenced org.hibernate.mapping.Table later).  This is trivial when table
> names are unique across all the catalogs/schemas (when there is only one
> "some_table" in all the mapped catalogs/schemas).  But is poses a problem
> when the same table name is used from different schemas (e.g., when
> "some_table" is mapped from both "schema1" and "schema2").  So we have a
> choice.  Since JPA does not say what is legal/illegal for the @Column.table
> attribute, it is feasible for us to allow @Column.table to contain the
> catalog/schema information in these cases as a selector.  The only other
> option I can see is to define a limitation that says that a table name must
> be unique for a given entity across all catalogs/schemas.  I don't think
> that is generally a restrictive limitation.  What are y'alls thoughts?
> Perhaps this is one argument for allowing pluggable LogicalNamingStrategy?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Tue Jan 13 19:44:20 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 13 Jan 2015 18:44:20 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFm4XO0C187F6j6w6z2z2oi7tugWRo6+7CDe76amPMKGfuyN4Q@mail.gmail.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
	<CAFm4XO0C187F6j6w6z2z2oi7tugWRo6+7CDe76amPMKGfuyN4Q@mail.gmail.com>
Message-ID: <CAFdSV9uOV01q_E-uGQbbTJOff5P4-==xo4dmThsiWvUkonfSQg@mail.gmail.com>

See inline...

On Tue, Jan 13, 2015 at 3:30 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Funny I just praised the "NamingStrategy" in the OGM thread. So I
> agree people badly want to specify their own "physical" naming
> strategy but I don't see any value into making the logical
> representation pluggable.
> It's probably important to make sure all code uses the same thing
> anyway for consistency; so I'd make it public so that extending
> frameworks / advanced tooling can comply to the same rules but not
> public as in a replaceable component.
>
> If we agree on that, the user will probably not be aware of us using a
> logical strategy which is different. So I'd hope we could keep the
> "NamingStrategy" name to mean the physical one? Because that's how
> what a lot of people call it today.
>

Well the *concept* of being able to hook in to the either the implicit and
physical naming processes is certainly awesome.  By "a mess", I just mean
specifically how it is currently done.

And, see, I *think* you are proving my point about how confusing this all
is.  There are actually 3 different types of strategies represented in the
current NamingStrategy:
* implicit naming
* logical naming
* physical naming

I agree that *most* people care about hooking into the physical naming
process.  However, I think that some users also care about implicit
naming.  But this is why I think it makes the most sense to split these out.

I disagree that reusing the name NamingStrategy for "physical naming
strategy" is the right thing to do.  For a few reasons.  First, its
confusing imo to long-time users (same name, completely different methods).
Also, I'd be confused if I was presented with a NamingStrategy, but then an
ImplicitNamingStrategy (and possibly a LogicalNamingStrategy); "what's the
difference?"



> Great idea to use typesafety like the Indentifier. But could you make
> it an interface instead? The presence of the boolean will otherwise
> double the size of the object in memory (24 bytes instead of 12), so
> I'd hope that we could actually use two different implementations. I'm
> assuming we'll have many such Identifier instances around. N.B. even
> in the case of just 12 bytes, it's 12 bytes on top of those of the
> pure-string representation.. but probably worth it in terms of better
> code.
>
> public interface Identifier {
>    String getText();
>    boolean isQuoted();
>    QuotedIdentifier quote(); //optional: we could add this if you
> think it's going to be a common operation as we'd be able to reuse the
> instances.
>    UnquotedIdentifier unquote(); //as above
> }
>
> public interface QuotedIdentifier extends Identifier {
>

I really dislike this idea of split quoted/unquoted identifier contract.
It just feels like leaking an awful lot of impl details just for some
premature optimization.


> ...
>
> I'm a bit lost about the LogicalNaming proposal. Why do these need to
> be strings at all?
> I think I'd organize them into some form of immutable matrix and then
> use them primarily based on references. The elements of the matrix
> would possibly be able to have nice debug-friendly toString
> implementations and possibly render the physical names as well so that
> users - aware only of the physical representation - aren't completely
> clueless when reading errors in logs.
> But I probably missed the purpose.
>

First, I am really not sure what you mean by "some form of immutable
matrix".  As for why the representation as Strings... well, one of the
state goals for 5.0 was to continue to use org.hibernate.mapping package to
represent the result of processing the mappings and to minimize any changes
to that model.  Objects in org.hibernate.mapping represents these as
Strings, ergo...

Their "purpose" mainly is essentially in maintaining a set of
cross-references.  Going back to the original example: @Column(...,
table="some_table") obviously we need some form of cross-referencing to be
able to resolve the *string* "some_table" to a org.hibernate.mapping.Table
reference.

From emmanuel at hibernate.org  Wed Jan 14 03:24:49 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 14 Jan 2015 09:24:49 +0100
Subject: [hibernate-dev] [OGM] Store objects as actual typed objects via
	the native grid format
In-Reply-To: <CAFm4XO2kcRStp9UvHLPvJiTORbFPRK_jMFbBx6TiSxv7Z25rjQ@mail.gmail.com>
References: <F453D8DC-C273-40F9-B5E6-6479BA0A5A91@hibernate.org>
	<0EF9C65F-7F2F-4250-9EA8-F43DA5D20371@hibernate.org>
	<CAFm4XO2kcRStp9UvHLPvJiTORbFPRK_jMFbBx6TiSxv7Z25rjQ@mail.gmail.com>
Message-ID: <5B132319-A849-4728-BCB6-B8300A9F4CEC@hibernate.org>

What you are describing is what we want to do at some point but it is definitely a few steps further.
Usually, in the maturation cycle, we code things in the dialect and then we try to extract the logic out into core.

And since it?s a non trivial set of new features, I?d rather we go by reasonable steps:
1. dialect level POF/protobuf support
2. dialect level multi storage support
3. ability to express JPA mapping with a programmatic API (for multi mappings expression)
4. core level multi storage support
5. query level use of the multi storage support

Gunnar mentioned that at least for Hazelcast, you cannot necessarily pass the POF data directly to the grid, you might be in need of a 1-1 mapping between a POJO and a POF which is making the whole idea of step 1 more convoluted already if true.

Emmanuel

> On 13 Jan 2015, at 22:03, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> Many interesting ideas.
> 
> Is the culprit not simply to be able to store the same entry into
> multiple (different) representations?
> I'd like to see the separation into "different representations" not
> being handled at the level of the dialect but higher up at level of
> OGM/ORM core, so that one could have - for example - some entities
> stored into a relational database, some other entities into MongoDB,
> and some entities into *both*.
> So configuration wise I'd have a section for each dialect, and then a
> way to tag each entity - possibly multiple times - to have then
> included into one of the configured databases.
> 
> You'd have two consequences:
> - you can have multiple instances of the same dialect type - for
> example two Coherence instances using a different POF encoding
> strategies
> - the Query engine can pick the best strategy among all storage
> options, across both differences of representation into the same
> database but also across query technologies / capabilities
> 
>    @Entity @PersistenceGroup(?mongo-cluster-of-foos?, "cassandra-times")
>    public Foo { ? }
> 
> A limitation is that I'd probably want to be able to mark various
> additional mapping annotations as belonging to a specific database
> only. For example I think a relation annotation like @ManyToOne should
> be the same on all - as it's related to the structure of the Java
> domain model - but other annotations such as @Column would need to
> have a qualifier so I can pick multiple different ones. The obvious
> solution is that such mapping solutions need to be externalized into
> mapping files (exclusively).
> In practice this might not be a too strong limitation, in all places
> I've worked the "@Column" annotation was the quick and dirty solution
> but people would prefer to make a corporate standard NamingStrategy
> which would consolidate such decisions out of the model.
> 
> However you decide on those, the Query execution would need the smart
> planner we've fantasized about a bit.
> 
> Somehow related: remember Adrian Nistor from the Infinispan team
> developed a mapping tool based on annotations to map POJOs to
> Protobuf. This is ready for general usage now, and could be useful
> here.
> 
> -- Sanne
> 
> 
> 
> On 13 January 2015 at 17:24, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> 
>>> On 13 Jan 2015, at 18:06, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>> 
>>> Note that the user here (see question c), also asks for the ability to denormalize the data and store a full object graph as one key and only a subset as a second key which is something we want to do but that we don?t have right now.
>> 
>> Actually, even that could be done by an ad-hoc dialect which would store the full entity graph in one schema / cache and the normal (according to OGM) entity in another schema/cache. The Dialect does not give you the entity graph but since we now know how to batch work, we could apply all changes on the virtual entry about to be persisted. This is essentially what we do in MongoDB?s dialect that we could replicate here.
>> 
>> Also, the POF(s) / Protobuf(s) for a given entity could be defined via the option system at the entity level
>> 
>>    @Entity @UsingSchema(?someSchemaId?)
>>    public Foo { ? }
>> 
>> How to chose one vs the other at query time (via OGM) is what we are the farthest from I suspect.
>> 
>> Emmanuel
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From emmanuel at hibernate.org  Wed Jan 14 03:27:36 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 14 Jan 2015 09:27:36 +0100
Subject: [hibernate-dev] [OGM] Transaction type "RESOURCE_LOCAL",
	still JTA is required
In-Reply-To: <CADGJaX9WiH0mxHf3uTHED_=3dyoDJKF19-goRs5LfunizwSqsA@mail.gmail.com>
References: <CADGJaX9WiH0mxHf3uTHED_=3dyoDJKF19-goRs5LfunizwSqsA@mail.gmail.com>
Message-ID: <72E2C41F-81BE-4DBB-9BB0-13F660A0CADA@hibernate.org>

Probably. Needs exploring.

> On 13 Jan 2015, at 19:18, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Hi,
> 
> For a demo I have an OGM application which defines a persistence unit with
> transaction type RESOURCE_LOCAL.
> 
> I thus assumed I wouldn't have to add a JTA implementation to the class
> path, but actually I'm getting a CNFE (see [1] for the complete trace):
> 
>    ClassNotFoundException: Could not load requested class :
> com.arjuna.ats.jta.TransactionManager
> 
> Indeed Arjuna is what we use as TM by default. It is set by OGM's
> JtaPlatform implementation which in turn is used by transactions created by
> OGM's default TransactionFactory [2].
> 
> Unless I'm doing something wrong configuration-wise, I feel that requiring
> a JTA implementation for a non-transactional backend such as MongoDB is
> confusing and may make users ask whether OGM is doing the right thing.
> 
> Would it be feasible to to provide an "OGM local" TransactionImplementor +
> TransactionFactory to be used in such cases where the store does not
> support transactions (so no rollbacks etc.), but we'd "only" need a trigger
> for writing out changes to the datastore?
> 
> Any thoughts?
> 
> --Gunnar
> 
> [1] https://gist.github.com/gunnarmorling/ba193caecb7d5cdbd0a4
> [2]
> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/transaction/impl/OgmTransactionFactoryInitiator.java#L42
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From gunnar at hibernate.org  Wed Jan 14 03:53:12 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 14 Jan 2015 09:53:12 +0100
Subject: [hibernate-dev] [OGM] Store objects as actual typed objects via
 the native grid format
In-Reply-To: <CAFm4XO2kcRStp9UvHLPvJiTORbFPRK_jMFbBx6TiSxv7Z25rjQ@mail.gmail.com>
References: <F453D8DC-C273-40F9-B5E6-6479BA0A5A91@hibernate.org>
	<0EF9C65F-7F2F-4250-9EA8-F43DA5D20371@hibernate.org>
	<CAFm4XO2kcRStp9UvHLPvJiTORbFPRK_jMFbBx6TiSxv7Z25rjQ@mail.gmail.com>
Message-ID: <CADGJaX9bN=X=FHSPkpYDJcPATBbaKVyDxRg2LtDVPtqUyPFgLg@mail.gmail.com>

To me the user's problem appears to be that the POF approach mixes a data
type and its (de-)serialization logic within one class. Specifically, you
need to implement a Hazelcast interface to do so:

    public class MyEntity implements Portable {

        Long id;
        String name;

        ...

        @Override public void writePortable( PortableWriter writer ) throws
IOException { ... }
        @Override public void readPortable( PortableReader reader ) throws
IOException { ... }
    }

In my understanding that's where the request for passing the entity object
to the dialect as is comes from; without the actual entity available, you
can't get hold of the (de-)serialization routine needed to put the stuff
into the datastore and get it back.

IMO that'd not be the right approach, though. a) Implementing
store-specific interfaces in entities seems against the whole nature of OGM
(esp. when taking polyglot persistence into the picture), b) it circumvents
things such as @Column names, type conversion (which may be needed to
convert property types allowed by JPA but not naturally supported by the
store) etc.

So instead of letting the entity types implement Portable, the dialect
should deal with this. Question is how it can be done in a generic fashion
with the given APIs. Yes, there could be a single Portable implementation
employed by the dialect which can serialize a given entity tuple. But upon
read-back that generic implementation wouldn't know which properties to
read from the persisted stream.

One approach would be to automatically generate the Portable
implementations, based on the entity types present. Either up-front via
some kind of build plug-in or dynamically at runtime (it may be challenging
to ensure constant "class ids" required by portables). This approach could
be implemented with OGM as is, it only puts the burdens of schema
management etc. entirely to the dialect.

But I'd start like that, see how it flies and then examine how more logic
could be moved onto the OGM core side.

--Gunnar



2015-01-13 22:03 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> Many interesting ideas.
>
> Is the culprit not simply to be able to store the same entry into
> multiple (different) representations?
> I'd like to see the separation into "different representations" not
> being handled at the level of the dialect but higher up at level of
> OGM/ORM core, so that one could have - for example - some entities
> stored into a relational database, some other entities into MongoDB,
> and some entities into *both*.
> So configuration wise I'd have a section for each dialect, and then a
> way to tag each entity - possibly multiple times - to have then
> included into one of the configured databases.
>
> You'd have two consequences:
>  - you can have multiple instances of the same dialect type - for
> example two Coherence instances using a different POF encoding
> strategies
>  - the Query engine can pick the best strategy among all storage
> options, across both differences of representation into the same
> database but also across query technologies / capabilities
>
>     @Entity @PersistenceGroup(?mongo-cluster-of-foos?, "cassandra-times")
>     public Foo { ? }
>
> A limitation is that I'd probably want to be able to mark various
> additional mapping annotations as belonging to a specific database
> only. For example I think a relation annotation like @ManyToOne should
> be the same on all - as it's related to the structure of the Java
> domain model - but other annotations such as @Column would need to
> have a qualifier so I can pick multiple different ones. The obvious
> solution is that such mapping solutions need to be externalized into
> mapping files (exclusively).
> In practice this might not be a too strong limitation, in all places
> I've worked the "@Column" annotation was the quick and dirty solution
> but people would prefer to make a corporate standard NamingStrategy
> which would consolidate such decisions out of the model.
>
> However you decide on those, the Query execution would need the smart
> planner we've fantasized about a bit.
>
> Somehow related: remember Adrian Nistor from the Infinispan team
> developed a mapping tool based on annotations to map POJOs to
> Protobuf. This is ready for general usage now, and could be useful
> here.
>
> -- Sanne
>
>
>
> On 13 January 2015 at 17:24, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >
> >> On 13 Jan 2015, at 18:06, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >>
> >> Note that the user here (see question c), also asks for the ability to
> denormalize the data and store a full object graph as one key and only a
> subset as a second key which is something we want to do but that we don?t
> have right now.
> >
> > Actually, even that could be done by an ad-hoc dialect which would store
> the full entity graph in one schema / cache and the normal (according to
> OGM) entity in another schema/cache. The Dialect does not give you the
> entity graph but since we now know how to batch work, we could apply all
> changes on the virtual entry about to be persisted. This is essentially
> what we do in MongoDB?s dialect that we could replicate here.
> >
> > Also, the POF(s) / Protobuf(s) for a given entity could be defined via
> the option system at the entity level
> >
> >     @Entity @UsingSchema(?someSchemaId?)
> >     public Foo { ? }
> >
> > How to chose one vs the other at query time (via OGM) is what we are the
> farthest from I suspect.
> >
> > Emmanuel
> > _______________________________________________
> > 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 Jan 14 04:08:20 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 14 Jan 2015 10:08:20 +0100
Subject: [hibernate-dev] [OGM] Transaction type "RESOURCE_LOCAL",
 still JTA is required
In-Reply-To: <CAFdSV9u8nHCYF=FBMu5OFWq36utVepqPPkGfruj+h0HCut843g@mail.gmail.com>
References: <CADGJaX9WiH0mxHf3uTHED_=3dyoDJKF19-goRs5LfunizwSqsA@mail.gmail.com>
	<CAFdSV9u8nHCYF=FBMu5OFWq36utVepqPPkGfruj+h0HCut843g@mail.gmail.com>
Message-ID: <CADGJaX8wXPF_6Z+RtV3Ew-crnhKAwtQSX7CE1E-cYBxNtU6GiA@mail.gmail.com>

2015-01-13 19:49 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> You'd need to not specify the JtaPlatform service stuff.
>

Yes, but which org.hibernate.Transaction implementation to use? We'd need a
"fake" implementation which triggers the grid dialect upon flush()/commit()
invocations.

On Tue, Jan 13, 2015 at 12:18 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Hi,
>>
>> For a demo I have an OGM application which defines a persistence unit with
>> transaction type RESOURCE_LOCAL.
>>
>> I thus assumed I wouldn't have to add a JTA implementation to the class
>> path, but actually I'm getting a CNFE (see [1] for the complete trace):
>>
>>     ClassNotFoundException: Could not load requested class :
>> com.arjuna.ats.jta.TransactionManager
>>
>> Indeed Arjuna is what we use as TM by default. It is set by OGM's
>> JtaPlatform implementation which in turn is used by transactions created
>> by
>> OGM's default TransactionFactory [2].
>>
>> Unless I'm doing something wrong configuration-wise, I feel that requiring
>> a JTA implementation for a non-transactional backend such as MongoDB is
>> confusing and may make users ask whether OGM is doing the right thing.
>>
>> Would it be feasible to to provide an "OGM local" TransactionImplementor +
>> TransactionFactory to be used in such cases where the store does not
>> support transactions (so no rollbacks etc.), but we'd "only" need a
>> trigger
>> for writing out changes to the datastore?
>>
>> Any thoughts?
>>
>> --Gunnar
>>
>> [1] https://gist.github.com/gunnarmorling/ba193caecb7d5cdbd0a4
>> [2]
>>
>> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/transaction/impl/OgmTransactionFactoryInitiator.java#L42
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From gunnar at hibernate.org  Wed Jan 14 04:10:33 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 14 Jan 2015 10:10:33 +0100
Subject: [hibernate-dev] [OGM] Transaction type "RESOURCE_LOCAL",
 still JTA is required
In-Reply-To: <72E2C41F-81BE-4DBB-9BB0-13F660A0CADA@hibernate.org>
References: <CADGJaX9WiH0mxHf3uTHED_=3dyoDJKF19-goRs5LfunizwSqsA@mail.gmail.com>
	<72E2C41F-81BE-4DBB-9BB0-13F660A0CADA@hibernate.org>
Message-ID: <CADGJaX_87DKbUOhSQV1cTQ6=27r9Je3c5gA_ei+TyRG2etftpQ@mail.gmail.com>

2015-01-14 9:27 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> Probably. Needs exploring.
>

https://hibernate.atlassian.net/browse/OGM-718

Btw. why has OGM its own JTATransactionManagerTransaction instead of using
ORM's existing JtaTransaction?


> > On 13 Jan 2015, at 19:18, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> > Hi,
> >
> > For a demo I have an OGM application which defines a persistence unit
> with
> > transaction type RESOURCE_LOCAL.
> >
> > I thus assumed I wouldn't have to add a JTA implementation to the class
> > path, but actually I'm getting a CNFE (see [1] for the complete trace):
> >
> >    ClassNotFoundException: Could not load requested class :
> > com.arjuna.ats.jta.TransactionManager
> >
> > Indeed Arjuna is what we use as TM by default. It is set by OGM's
> > JtaPlatform implementation which in turn is used by transactions created
> by
> > OGM's default TransactionFactory [2].
> >
> > Unless I'm doing something wrong configuration-wise, I feel that
> requiring
> > a JTA implementation for a non-transactional backend such as MongoDB is
> > confusing and may make users ask whether OGM is doing the right thing.
> >
> > Would it be feasible to to provide an "OGM local" TransactionImplementor
> +
> > TransactionFactory to be used in such cases where the store does not
> > support transactions (so no rollbacks etc.), but we'd "only" need a
> trigger
> > for writing out changes to the datastore?
> >
> > Any thoughts?
> >
> > --Gunnar
> >
> > [1] https://gist.github.com/gunnarmorling/ba193caecb7d5cdbd0a4
> > [2]
> >
> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/transaction/impl/OgmTransactionFactoryInitiator.java#L42
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From emmanuel at hibernate.org  Wed Jan 14 04:37:23 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 14 Jan 2015 10:37:23 +0100
Subject: [hibernate-dev] [OGM] Transaction type "RESOURCE_LOCAL",
	still JTA is required
In-Reply-To: <CADGJaX_87DKbUOhSQV1cTQ6=27r9Je3c5gA_ei+TyRG2etftpQ@mail.gmail.com>
References: <CADGJaX9WiH0mxHf3uTHED_=3dyoDJKF19-goRs5LfunizwSqsA@mail.gmail.com>
	<72E2C41F-81BE-4DBB-9BB0-13F660A0CADA@hibernate.org>
	<CADGJaX_87DKbUOhSQV1cTQ6=27r9Je3c5gA_ei+TyRG2etftpQ@mail.gmail.com>
Message-ID: <A01071AC-F608-40EF-8AF0-0A3D6D5E145B@hibernate.org>

I don?t quite remember but looking at it, it looks like I needed something that would work on all cases: CMT or non CMT (excludes the use of UserTransaction), be able to start a transaction if none has been started already.
It?s rooted in https://hibernate.atlassian.net/browse/OGM-56 <https://hibernate.atlassian.net/browse/OGM-56>


> On 14 Jan 2015, at 10:10, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> 2015-01-14 9:27 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org <mailto:emmanuel at hibernate.org>>:
> Probably. Needs exploring.
> 
> https://hibernate.atlassian.net/browse/OGM-718 <https://hibernate.atlassian.net/browse/OGM-718>
> 
> Btw. why has OGM its own JTATransactionManagerTransaction instead of using ORM's existing JtaTransaction?
> 
> 
> > On 13 Jan 2015, at 19:18, Gunnar Morling <gunnar at hibernate.org <mailto:gunnar at hibernate.org>> wrote:
> >
> > Hi,
> >
> > For a demo I have an OGM application which defines a persistence unit with
> > transaction type RESOURCE_LOCAL.
> >
> > I thus assumed I wouldn't have to add a JTA implementation to the class
> > path, but actually I'm getting a CNFE (see [1] for the complete trace):
> >
> >    ClassNotFoundException: Could not load requested class :
> > com.arjuna.ats.jta.TransactionManager
> >
> > Indeed Arjuna is what we use as TM by default. It is set by OGM's
> > JtaPlatform implementation which in turn is used by transactions created by
> > OGM's default TransactionFactory [2].
> >
> > Unless I'm doing something wrong configuration-wise, I feel that requiring
> > a JTA implementation for a non-transactional backend such as MongoDB is
> > confusing and may make users ask whether OGM is doing the right thing.
> >
> > Would it be feasible to to provide an "OGM local" TransactionImplementor +
> > TransactionFactory to be used in such cases where the store does not
> > support transactions (so no rollbacks etc.), but we'd "only" need a trigger
> > for writing out changes to the datastore?
> >
> > Any thoughts?
> >
> > --Gunnar
> >
> > [1] https://gist.github.com/gunnarmorling/ba193caecb7d5cdbd0a4 <https://gist.github.com/gunnarmorling/ba193caecb7d5cdbd0a4>
> > [2]
> > https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/transaction/impl/OgmTransactionFactoryInitiator.java#L42 <https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/transaction/impl/OgmTransactionFactoryInitiator.java#L42>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> 
> 


From emmanuel at hibernate.org  Wed Jan 14 04:39:07 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 14 Jan 2015 10:39:07 +0100
Subject: [hibernate-dev] [OGM] Transaction type "RESOURCE_LOCAL",
	still JTA is required
In-Reply-To: <CADGJaX8wXPF_6Z+RtV3Ew-crnhKAwtQSX7CE1E-cYBxNtU6GiA@mail.gmail.com>
References: <CADGJaX9WiH0mxHf3uTHED_=3dyoDJKF19-goRs5LfunizwSqsA@mail.gmail.com>
	<CAFdSV9u8nHCYF=FBMu5OFWq36utVepqPPkGfruj+h0HCut843g@mail.gmail.com>
	<CADGJaX8wXPF_6Z+RtV3Ew-crnhKAwtQSX7CE1E-cYBxNtU6GiA@mail.gmail.com>
Message-ID: <DE5277D7-C0AF-48A4-B60B-BE43B1FE62FF@hibernate.org>


> On 14 Jan 2015, at 10:08, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> 2015-01-13 19:49 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> 
>> You'd need to not specify the JtaPlatform service stuff.
>> 
> 
> Yes, but which org.hibernate.Transaction implementation to use? We'd need a
> "fake" implementation which triggers the grid dialect upon flush()/commit()
> invocations.

I think I originally replaced it so that it worked for Infinispan. Which mandates a JTA TM all the time (for transactions).
Looks like it was still working for the other datastores and no one bothered to improve a working bit until you discovered the extra dependency issue.

From gunnar at hibernate.org  Wed Jan 14 05:35:57 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 14 Jan 2015 11:35:57 +0100
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
Message-ID: <CADGJaX81Am5+oRcxU6EJEUFZsRcGFzv0tZA_B7XDbk_PweujWQ@mail.gmail.com>

> Do we need a contract for LogicalNamingStrategy?

As you say it's an internal concept only. Based on your description I don't
see why a user would want to customize it. So I'd internally make
consistently use of the LogicalNamingStrategy for resolving references, but
I'd not make it pluggable. Should someone really need this, it's easy to
make it pluggable later on.

> So I also propose to shift this to use that Identifier class

I like that idea.

Is it correct to say it represents a logical name basically? If so, how
about naming it "LogicalName"? "Identifier" seems too generic to me (e.g.
easily to be mixed up with entity identifiers). Would that class/interface
define a method String getPhysicalName()? That should nicely encapsulate
the quote handling.

> But is poses a problem when the same table name is used from different
schemas. [... ] The only other option I can see is to define a limitation
that says that a table name must
be unique for a given entity across all catalogs/schemas. [...] that is
generally a restrictive limitation.  What are y'alls thoughts? Perhaps this
is one argument for allowing pluggable LogicalNamingStrategy?

I'd work with that restriction. I would not make LogicalNamingStrategy
pluggable just for this, until someone comes up with really compelling use
case why they'd need that sort of mapping.

--Gunnar


2015-01-13 19:43 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> As I am working on 5.0, one of the things I am trying to accomplish is to
> make the handling of table/column names more consistent and better
> defined.  The first step in that is to properly define the terms used often
> throughout the codebase.
>
> The first level of naming is the "given" name of a table/column.  The given
> name might be:
> * explicit - explicitly specified by the user, as in @Table(
> name="explicit_name" )
> * implicit - not explicitly specified by the user and thus implicitly
> determined (by JPA rules, "naming strategy", etc).
>
> Next, we have a logical name which is a normalized form of the "given"
> name.  This is the form used to reference tables/columns internally.  E.g.,
> its how we resolve @Column(..., table="xyz").  More on this form later.
>
> Finally we have the physical name of the thing, which is the actual name of
> the table/column in the database.  Again, this is generally a normalization
> of the given name based on Dialect, "naming strategy", etc.
>
> Today, we have a very messy concept called a NamingStrategy.  I say it is
> messy because it tries to combine unrelated concerns.  So I still plan to
> split this as I have outlined elsewhere into:
> 1) ImplicitNamingStrategy
> 2) PhysicalNamingStrategy
>
> Which brings up my first question to y'all.  Do we need a contract for
> LogicalNamingStrategy?  As I have said, the logical names are the things
> used to resolve references.  Allowing people to plug in custom strategies
> for how that normalization works could be very dangerous.  But even more
> than that, is it really interesting to be able to hook into that process?
>
> Historically, these names are all represented by String.  So I also propose
> to shift this to use that Identifier class we developed for the metamodel
> redesign.  For those that may be unfamiliar, it essentially combines the
> String name with a "quoted" boolean:
>
> public class Identifier {
>   private final String text;
>   private final boolean isQuoted;
>     ...
> }
>
> Table names, then, are an aggregation of 3 Identifiers: one for catalog,
> one for schema, one for table name.  Same for named constraints
> (ultimately, which is part of a improvement for 6.0 to allow indexes,
> constraints, etc to be created in a separate schema from tables).
>
> Since a major goal for 5.0 is to continue to use the org.hibernate.mapping
> package as the representation of the mapping information, we obviously want
> to minimize changes there to only what is completely essential.  To that
> end, if we are going to use Identifier over String stuff in the
> org.hibernate.mapping package will need to deal with both; internally they
> will hold the Identifier and use that to implement the String-based
> name-related methods they expose.
>
> Lastly I wanted to discuss the details of the logical names.  For tables,
> we currently qualify the table name with the catalog/schema info.  There is
> a mismatch in this regard when it comes to remaining a pure JPA
> implementation.  Consider @Column( ..., table="some_table").  Ultimately we
> need to be able to qualify that with catalog/schema in order to be able to
> construct a matching logical name (to be able to pair that with the
> referenced org.hibernate.mapping.Table later).  This is trivial when table
> names are unique across all the catalogs/schemas (when there is only one
> "some_table" in all the mapped catalogs/schemas).  But is poses a problem
> when the same table name is used from different schemas (e.g., when
> "some_table" is mapped from both "schema1" and "schema2").  So we have a
> choice.  Since JPA does not say what is legal/illegal for the @Column.table
> attribute, it is feasible for us to allow @Column.table to contain the
> catalog/schema information in these cases as a selector.  The only other
> option I can see is to define a limitation that says that a table name must
> be unique for a given entity across all catalogs/schemas.  I don't think
> that is generally a restrictive limitation.  What are y'alls thoughts?
> Perhaps this is one argument for allowing pluggable LogicalNamingStrategy?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Wed Jan 14 05:38:48 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 14 Jan 2015 11:38:48 +0100
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
Message-ID: <20150114103848.GB75173@Sarmakand-4.local>

Hi,

+1 for ImplicitNamingStrategy and PhysicalNamingStrategy
What would be the contract of these strategies?

I don't think LogicalNamingStrategy is necessary. I think this might 
just get too complicated for a user. Also, iiuc the logical name is for
internal lookups. 

+1 for actual identifier classes. I think the code would become easier to understand
and hopefully safer with these typed classes. I liked this approach when working
on the metamodel branch. I would, however, not make it an interface. I also see
this as a pre-mature optimisation

> Since JPA does not say what is legal/illegal for the @Column.table
> attribute, it is feasible for us to allow @Column.table to contain the
> catalog/schema information in these cases as a selector..

What exactly do you mean with 'selector'?

--Hardy



On Tue, Jan 13, 2015 at 12:43:37PM -0600, Steve Ebersole wrote:
> As I am working on 5.0, one of the things I am trying to accomplish is to
> make the handling of table/column names more consistent and better
> defined.  The first step in that is to properly define the terms used often
> throughout the codebase.
> 
> The first level of naming is the "given" name of a table/column.  The given
> name might be:
> * explicit - explicitly specified by the user, as in @Table(
> name="explicit_name" )
> * implicit - not explicitly specified by the user and thus implicitly
> determined (by JPA rules, "naming strategy", etc).
> 
> Next, we have a logical name which is a normalized form of the "given"
> name.  This is the form used to reference tables/columns internally.  E.g.,
> its how we resolve @Column(..., table="xyz").  More on this form later.
> 
> Finally we have the physical name of the thing, which is the actual name of
> the table/column in the database.  Again, this is generally a normalization
> of the given name based on Dialect, "naming strategy", etc.
> 
> Today, we have a very messy concept called a NamingStrategy.  I say it is
> messy because it tries to combine unrelated concerns.  So I still plan to
> split this as I have outlined elsewhere into:
> 1) ImplicitNamingStrategy
> 2) PhysicalNamingStrategy
> 
> Which brings up my first question to y'all.  Do we need a contract for
> LogicalNamingStrategy?  As I have said, the logical names are the things
> used to resolve references.  Allowing people to plug in custom strategies
> for how that normalization works could be very dangerous.  But even more
> than that, is it really interesting to be able to hook into that process?
> 
> Historically, these names are all represented by String.  So I also propose
> to shift this to use that Identifier class we developed for the metamodel
> redesign.  For those that may be unfamiliar, it essentially combines the
> String name with a "quoted" boolean:
> 
> public class Identifier {
>   private final String text;
>   private final boolean isQuoted;
>     ...
> }
> 
> Table names, then, are an aggregation of 3 Identifiers: one for catalog,
> one for schema, one for table name.  Same for named constraints
> (ultimately, which is part of a improvement for 6.0 to allow indexes,
> constraints, etc to be created in a separate schema from tables).
> 
> Since a major goal for 5.0 is to continue to use the org.hibernate.mapping
> package as the representation of the mapping information, we obviously want
> to minimize changes there to only what is completely essential.  To that
> end, if we are going to use Identifier over String stuff in the
> org.hibernate.mapping package will need to deal with both; internally they
> will hold the Identifier and use that to implement the String-based
> name-related methods they expose.
> 
> Lastly I wanted to discuss the details of the logical names.  For tables,
> we currently qualify the table name with the catalog/schema info.  There is
> a mismatch in this regard when it comes to remaining a pure JPA
> implementation.  Consider @Column( ..., table="some_table").  Ultimately we
> need to be able to qualify that with catalog/schema in order to be able to
> construct a matching logical name (to be able to pair that with the
> referenced org.hibernate.mapping.Table later).  This is trivial when table
> names are unique across all the catalogs/schemas (when there is only one
> "some_table" in all the mapped catalogs/schemas).  But is poses a problem
> when the same table name is used from different schemas (e.g., when
> "some_table" is mapped from both "schema1" and "schema2").  So we have a
> choice.  Since JPA does not say what is legal/illegal for the @Column.table
> attribute, it is feasible for us to allow @Column.table to contain the
> catalog/schema information in these cases as a selector.  The only other
> option I can see is to define a limitation that says that a table name must
> be unique for a given entity across all catalogs/schemas.  I don't think
> that is generally a restrictive limitation.  What are y'alls thoughts?
> Perhaps this is one argument for allowing pluggable LogicalNamingStrategy?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150114/d07c68ad/attachment.bin 

From steve at hibernate.org  Wed Jan 14 10:06:46 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 14 Jan 2015 09:06:46 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CADGJaX81Am5+oRcxU6EJEUFZsRcGFzv0tZA_B7XDbk_PweujWQ@mail.gmail.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
	<CADGJaX81Am5+oRcxU6EJEUFZsRcGFzv0tZA_B7XDbk_PweujWQ@mail.gmail.com>
Message-ID: <CAFdSV9tpWbck722J9YNT65TY1MB4Z0LKMb86LScMJizK+x5uww@mail.gmail.com>

>
> > So I also propose to shift this to use that Identifier class
>
> I like that idea.
>
> Is it correct to say it represents a logical name basically? If so, how
> about naming it "LogicalName"? "Identifier" seems too generic to me (e.g.
> easily to be mixed up with entity identifiers). Would that class/interface
> define a method String getPhysicalName()? That should nicely encapsulate
> the quote handling.
>

Well that depends on how we interpret "logical name".  Take a table named
"my_table" in the "my_schema" schema as part of the "my_catalog" catalog.
Now, each of those individual "names" would be an
* tableName = new Identifier( "my_table", false );
* schemaName = new Identifier( "my_schema", false );
* catalogName = new Identifier( "my_catalog", false );

So Identifier really just represents the parts of a "object name" (in SQL
terms).

Now historically, the logical name of a table is represented by this
qualified form.  Remember though that "historically" points specifically to
growing from hbm.xml  mapping where this is not really an issue.

As an aside, in that metamodel branch there is also an aggregated form to
represent the qualified table name by composing all 3 components together,
as well as physically grouping them into Schema objects.  But there is no
natural corollary to these concepts in org.hibernate.mapping, and so I will
not pull them over.  Although... I will say that it might be better to use
that typed form (QualifiedTableName class aggregating the 3 compoment
names) as the "cross reference key".

From steve at hibernate.org  Wed Jan 14 10:19:40 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 14 Jan 2015 09:19:40 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <20150114103848.GB75173@Sarmakand-4.local>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
	<20150114103848.GB75173@Sarmakand-4.local>
Message-ID: <CAFdSV9sfaYn9sXUhEHHWg7oMUDLXk9cb38257xq51dYdwZ==cw@mail.gmail.com>

Something like:


public interface ImplicitNamingStrategy {
  public Identifier determinePrimaryTableName(ImplicitEntityNameSource
source);

  public Identifier determineJoinTableName(ImplicitJoinTableNameSource
source);

  public Identifier
determineCollectionTableName(ImplicitCollectionTableNameSource
source);

  public Identifier
determineDiscriminatorColumnName(ImplicitDiscriminatorColumnNameSource
source);

    public Identifier
determineTenantIdColumnName(ImplicitTenantIdColumnNameSource
source);

  public Identifier
determineAttributeColumnName(ImplicitAttributeColumnNameSource
source);

  public Identifier
determineCollectionJoinColumnName(ImplicitCollectionJoinColumnNameSource
source);

    ...
}


The sources are simply parameter objects providing access to information
needed to determine the implicit name.  For example:

/**
 * Defines the source for entity naming.  Between legacy Hibernate
requirements and
 * JPA requirements this is, unfortunately, multi-sourced.  This contract
allows
 * access to all source values.
 *
 * @author Steve Ebersole
 */
public interface ImplicitEntityNamingSource {
    /**
     * The FQN of the entity class.  Note, this may be {@code null} in the
case
     * of (non-JPA-compliant) dynamic entities).
  *
     * @return The entity class FQN, or {@code null} if a dynamic entity.
  */
  public String getEntityClassName();

  /**
     * Get the explicitly specified Hibernate entity name.  The Hibernate
name is
  * very much different from the JPA concept of entity name.
  *
  * @return The explicitly specified entity name
  */
  public String getExplicitEntityName();

  /**
  * The Hibernate entity name.  This might be either:<ul>
  *     <li>The explicitly specified entity name, if one</li>
  *     <li>The unqualified entity class name if no entity name was
explicitly specified</li>
  * </ul>
  *
   * @return The Hibernate entity name
  */
  public String getEntityName();

  /**
 * The JPA-specific entity name.  See {@link
javax.persistence.Entity#name()} for details.
     *
  * @return The JPA entity name, if one was specified.  May return {@code
null} if one
  * was not explicitly specified.
  */
  public String getJpaEntityName();
}

etc...

And then:

public interface PhysicalNamingStrategy {
    public Identifier toPhysicalCatalogName(Identifier name);

    public Identifier toPhysicalSchemaName(Identifier name);

    public Identifier toPhysicalTableName(Identifier name);

    public Identifier toPhysicalColumnName(Identifier name);
}

I think ultimately it makes sense to pass some additional information
into PhysicalNamingStrategy to give access to Dialect, etc.

On Wed, Jan 14, 2015 at 4:38 AM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> +1 for ImplicitNamingStrategy and PhysicalNamingStrategy
> What would be the contract of these strategies?
>
> I don't think LogicalNamingStrategy is necessary. I think this might
> just get too complicated for a user. Also, iiuc the logical name is for
> internal lookups.
>
> +1 for actual identifier classes. I think the code would become easier to
> understand
> and hopefully safer with these typed classes. I liked this approach when
> working
> on the metamodel branch. I would, however, not make it an interface. I
> also see
> this as a pre-mature optimisation
>
> > Since JPA does not say what is legal/illegal for the @Column.table
> > attribute, it is feasible for us to allow @Column.table to contain the
> > catalog/schema information in these cases as a selector..
>
> What exactly do you mean with 'selector'?
>
> --Hardy
>
>
>
> On Tue, Jan 13, 2015 at 12:43:37PM -0600, Steve Ebersole wrote:
> > As I am working on 5.0, one of the things I am trying to accomplish is to
> > make the handling of table/column names more consistent and better
> > defined.  The first step in that is to properly define the terms used
> often
> > throughout the codebase.
> >
> > The first level of naming is the "given" name of a table/column.  The
> given
> > name might be:
> > * explicit - explicitly specified by the user, as in @Table(
> > name="explicit_name" )
> > * implicit - not explicitly specified by the user and thus implicitly
> > determined (by JPA rules, "naming strategy", etc).
> >
> > Next, we have a logical name which is a normalized form of the "given"
> > name.  This is the form used to reference tables/columns internally.
> E.g.,
> > its how we resolve @Column(..., table="xyz").  More on this form later.
> >
> > Finally we have the physical name of the thing, which is the actual name
> of
> > the table/column in the database.  Again, this is generally a
> normalization
> > of the given name based on Dialect, "naming strategy", etc.
> >
> > Today, we have a very messy concept called a NamingStrategy.  I say it is
> > messy because it tries to combine unrelated concerns.  So I still plan to
> > split this as I have outlined elsewhere into:
> > 1) ImplicitNamingStrategy
> > 2) PhysicalNamingStrategy
> >
> > Which brings up my first question to y'all.  Do we need a contract for
> > LogicalNamingStrategy?  As I have said, the logical names are the things
> > used to resolve references.  Allowing people to plug in custom strategies
> > for how that normalization works could be very dangerous.  But even more
> > than that, is it really interesting to be able to hook into that process?
> >
> > Historically, these names are all represented by String.  So I also
> propose
> > to shift this to use that Identifier class we developed for the metamodel
> > redesign.  For those that may be unfamiliar, it essentially combines the
> > String name with a "quoted" boolean:
> >
> > public class Identifier {
> >   private final String text;
> >   private final boolean isQuoted;
> >     ...
> > }
> >
> > Table names, then, are an aggregation of 3 Identifiers: one for catalog,
> > one for schema, one for table name.  Same for named constraints
> > (ultimately, which is part of a improvement for 6.0 to allow indexes,
> > constraints, etc to be created in a separate schema from tables).
> >
> > Since a major goal for 5.0 is to continue to use the
> org.hibernate.mapping
> > package as the representation of the mapping information, we obviously
> want
> > to minimize changes there to only what is completely essential.  To that
> > end, if we are going to use Identifier over String stuff in the
> > org.hibernate.mapping package will need to deal with both; internally
> they
> > will hold the Identifier and use that to implement the String-based
> > name-related methods they expose.
> >
> > Lastly I wanted to discuss the details of the logical names.  For tables,
> > we currently qualify the table name with the catalog/schema info.  There
> is
> > a mismatch in this regard when it comes to remaining a pure JPA
> > implementation.  Consider @Column( ..., table="some_table").  Ultimately
> we
> > need to be able to qualify that with catalog/schema in order to be able
> to
> > construct a matching logical name (to be able to pair that with the
> > referenced org.hibernate.mapping.Table later).  This is trivial when
> table
> > names are unique across all the catalogs/schemas (when there is only one
> > "some_table" in all the mapped catalogs/schemas).  But is poses a problem
> > when the same table name is used from different schemas (e.g., when
> > "some_table" is mapped from both "schema1" and "schema2").  So we have a
> > choice.  Since JPA does not say what is legal/illegal for the
> @Column.table
> > attribute, it is feasible for us to allow @Column.table to contain the
> > catalog/schema information in these cases as a selector.  The only other
> > option I can see is to define a limitation that says that a table name
> must
> > be unique for a given entity across all catalogs/schemas.  I don't think
> > that is generally a restrictive limitation.  What are y'alls thoughts?
> > Perhaps this is one argument for allowing pluggable
> LogicalNamingStrategy?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Wed Jan 14 12:05:06 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 14 Jan 2015 18:05:06 +0100
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9tpWbck722J9YNT65TY1MB4Z0LKMb86LScMJizK+x5uww@mail.gmail.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
	<CADGJaX81Am5+oRcxU6EJEUFZsRcGFzv0tZA_B7XDbk_PweujWQ@mail.gmail.com>
	<CAFdSV9tpWbck722J9YNT65TY1MB4Z0LKMb86LScMJizK+x5uww@mail.gmail.com>
Message-ID: <CADGJaX9p9Kv2yvLi7hhRmCD8MjWVsWuLPu+jDOXkxe+s28uDCg@mail.gmail.com>

2015-01-14 16:06 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> > So I also propose to shift this to use that Identifier class
>>
>> I like that idea.
>>
>> Is it correct to say it represents a logical name basically? If so, how
>> about naming it "LogicalName"? "Identifier" seems too generic to me (e.g.
>> easily to be mixed up with entity identifiers). Would that class/interface
>> define a method String getPhysicalName()? That should nicely encapsulate
>> the quote handling.
>>
>
> Well that depends on how we interpret "logical name".  Take a table named
> "my_table" in the "my_schema" schema as part of the "my_catalog" catalog.
> Now, each of those individual "names" would be an
> * tableName = new Identifier( "my_table", false );
> * schemaName = new Identifier( "my_schema", false );
> * catalogName = new Identifier( "my_catalog", false );
>
> So Identifier really just represents the parts of a "object name" (in SQL
> terms).
>
> Now historically, the logical name of a table is represented by this
> qualified form.  Remember though that "historically" points specifically to
> growing from hbm.xml  mapping where this is not really an issue.
>
> As an aside, in that metamodel branch there is also an aggregated form to
> represent the qualified table name by composing all 3 components together,
> as well as physically grouping them into Schema objects.  But there is no
> natural corollary to these concepts in org.hibernate.mapping, and so I will
> not pull them over.  Although... I will say that it might be better to use
> that typed form (QualifiedTableName class aggregating the 3 compoment
> names) as the "cross reference key".
>

Yes, such an aggregated form indeed is how I had done it on first thought.
But then I don't really know the code which would be using it, so I cannot
comment on whether that'd be feasible or doable at this point of time.

From emmanuel at hibernate.org  Wed Jan 14 12:12:55 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 14 Jan 2015 18:12:55 +0100
Subject: [hibernate-dev] Fwd: Hibernate ORM modules published as major.minor
	and an alias for main
References: <54B699C3.7030109@redhat.com>
Message-ID: <9510D99E-78C6-4523-9292-40578000DCB9@hibernate.org>

FYI

> Begin forwarded message:
> 
> Date: 14 Jan 2015 17:30:59 CET
> From: Scott Marlow <smarlow at redhat.com>
> To: Emmanuel Bernard <emmanuel at hibernate.org>
> Subject: Re: Hibernate ORM modules published as major.minor and an alias for main
> 
> Hi Emmanuel,
> 
> On 01/14/2015 11:06 AM, Emmanuel Bernard wrote:
>> Hi Scott,
>> 
>> In the f2f we discussed the idea of having ORM being published as major.minor and have an alias form main to the default WildFly targeted version.
>> Is that in and for which WildFly version?
> 
> I created https://issues.jboss.org/browse/WFLY-4021 and https://github.com/wildfly/wildfly/pull/6883 which got merged into WildFly 9.0.
> 
> The change is that modules/system/layers/base/org/hibernate/4.3/module.xml was added and contains:
> "
> <module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate.main" slot="4.3" target-name="org.hibernate"/>
> "
> 
> I think this is wrong though, as it should be:
> 
> "
> <module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate" slot="4.3" target-name="org.hibernate"/>
> "
> 
> I'll reopen and push a new pull request.
> 
> 
>> 
>> I am just trying the catch up.
>> 


From gunnar at hibernate.org  Wed Jan 14 12:14:06 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 14 Jan 2015 18:14:06 +0100
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9sfaYn9sXUhEHHWg7oMUDLXk9cb38257xq51dYdwZ==cw@mail.gmail.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
	<20150114103848.GB75173@Sarmakand-4.local>
	<CAFdSV9sfaYn9sXUhEHHWg7oMUDLXk9cb38257xq51dYdwZ==cw@mail.gmail.com>
Message-ID: <CADGJaX8VU1Tt-U9T4zmK815meVQoh2hpUsqGXp-g06kPAACKfw@mail.gmail.com>

2015-01-14 16:19 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> Something like:
>
>
> public interface ImplicitNamingStrategy {
>   public Identifier determinePrimaryTableName(ImplicitEntityNameSource
> source);
>
>   public Identifier determineJoinTableName(ImplicitJoinTableNameSource
> source);
>
>   public Identifier
> determineCollectionTableName(ImplicitCollectionTableNameSource
> source);
>
>   public Identifier
> determineDiscriminatorColumnName(ImplicitDiscriminatorColumnNameSource
> source);
>
>     public Identifier
> determineTenantIdColumnName(ImplicitTenantIdColumnNameSource
> source);
>
>   public Identifier
> determineAttributeColumnName(ImplicitAttributeColumnNameSource
> source);
>
>   public Identifier
> determineCollectionJoinColumnName(ImplicitCollectionJoinColumnNameSource
> source);
>
>     ...
> }
>
>
> The sources are simply parameter objects providing access to information
> needed to determine the implicit name.  For example:
>
> /**
>  * Defines the source for entity naming.  Between legacy Hibernate
> requirements and
>  * JPA requirements this is, unfortunately, multi-sourced.  This contract
> allows
>  * access to all source values.
>  *
>  * @author Steve Ebersole
>  */
> public interface ImplicitEntityNamingSource {
>     /**
>      * The FQN of the entity class.  Note, this may be {@code null} in the
> case
>      * of (non-JPA-compliant) dynamic entities).
>   *
>      * @return The entity class FQN, or {@code null} if a dynamic entity.
>   */
>   public String getEntityClassName();
>
>   /**
>      * Get the explicitly specified Hibernate entity name.  The Hibernate
> name is
>   * very much different from the JPA concept of entity name.
>   *
>   * @return The explicitly specified entity name
>   */
>   public String getExplicitEntityName();
>
>   /**
>   * The Hibernate entity name.  This might be either:<ul>
>   *     <li>The explicitly specified entity name, if one</li>
>   *     <li>The unqualified entity class name if no entity name was
> explicitly specified</li>
>   * </ul>
>   *
>    * @return The Hibernate entity name
>   */
>   public String getEntityName();
>
>   /**
>  * The JPA-specific entity name.  See {@link
> javax.persistence.Entity#name()} for details.
>      *
>   * @return The JPA entity name, if one was specified.  May return {@code
> null} if one
>   * was not explicitly specified.
>   */
>   public String getJpaEntityName();
> }
>
> etc...
>
> And then:
>
> public interface PhysicalNamingStrategy {
>     public Identifier toPhysicalCatalogName(Identifier name);
>
>     public Identifier toPhysicalSchemaName(Identifier name);
>
>     public Identifier toPhysicalTableName(Identifier name);
>
>     public Identifier toPhysicalColumnName(Identifier name);
> }
>
>
So why is PhysicalNamingStrategy returning Identifiers and not Strings? I
think I find the double usage of Identifier for logical names (or
"components" thereof) and physical names somewhat irritating. As the
physical name I'd have expected just the "rendered" String as to be passed
to the driver.

I think ultimately it makes sense to pass some additional information
> into PhysicalNamingStrategy to give access to Dialect, etc.
>

Interesting; As we had already discussed recently, that raises the question
of how to evolve the interface in a compatible way.

Java 8's default methods of course help, but until we can rely on that, I
find using abstract classes rather than interfaces attractive for such
contracts. With these, a method such as void
initialize(SomeInitializationContext) can be easily added, and
implementations can override it in a future version if they wish. Or you
foresee some sort of context parameter on the actual methods of the
contract.


>
> On Wed, Jan 14, 2015 at 4:38 AM, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
>
> > Hi,
> >
> > +1 for ImplicitNamingStrategy and PhysicalNamingStrategy
> > What would be the contract of these strategies?
> >
> > I don't think LogicalNamingStrategy is necessary. I think this might
> > just get too complicated for a user. Also, iiuc the logical name is for
> > internal lookups.
> >
> > +1 for actual identifier classes. I think the code would become easier to
> > understand
> > and hopefully safer with these typed classes. I liked this approach when
> > working
> > on the metamodel branch. I would, however, not make it an interface. I
> > also see
> > this as a pre-mature optimisation
> >
> > > Since JPA does not say what is legal/illegal for the @Column.table
> > > attribute, it is feasible for us to allow @Column.table to contain the
> > > catalog/schema information in these cases as a selector..
> >
> > What exactly do you mean with 'selector'?
> >
> > --Hardy
> >
> >
> >
> > On Tue, Jan 13, 2015 at 12:43:37PM -0600, Steve Ebersole wrote:
> > > As I am working on 5.0, one of the things I am trying to accomplish is
> to
> > > make the handling of table/column names more consistent and better
> > > defined.  The first step in that is to properly define the terms used
> > often
> > > throughout the codebase.
> > >
> > > The first level of naming is the "given" name of a table/column.  The
> > given
> > > name might be:
> > > * explicit - explicitly specified by the user, as in @Table(
> > > name="explicit_name" )
> > > * implicit - not explicitly specified by the user and thus implicitly
> > > determined (by JPA rules, "naming strategy", etc).
> > >
> > > Next, we have a logical name which is a normalized form of the "given"
> > > name.  This is the form used to reference tables/columns internally.
> > E.g.,
> > > its how we resolve @Column(..., table="xyz").  More on this form later.
> > >
> > > Finally we have the physical name of the thing, which is the actual
> name
> > of
> > > the table/column in the database.  Again, this is generally a
> > normalization
> > > of the given name based on Dialect, "naming strategy", etc.
> > >
> > > Today, we have a very messy concept called a NamingStrategy.  I say it
> is
> > > messy because it tries to combine unrelated concerns.  So I still plan
> to
> > > split this as I have outlined elsewhere into:
> > > 1) ImplicitNamingStrategy
> > > 2) PhysicalNamingStrategy
> > >
> > > Which brings up my first question to y'all.  Do we need a contract for
> > > LogicalNamingStrategy?  As I have said, the logical names are the
> things
> > > used to resolve references.  Allowing people to plug in custom
> strategies
> > > for how that normalization works could be very dangerous.  But even
> more
> > > than that, is it really interesting to be able to hook into that
> process?
> > >
> > > Historically, these names are all represented by String.  So I also
> > propose
> > > to shift this to use that Identifier class we developed for the
> metamodel
> > > redesign.  For those that may be unfamiliar, it essentially combines
> the
> > > String name with a "quoted" boolean:
> > >
> > > public class Identifier {
> > >   private final String text;
> > >   private final boolean isQuoted;
> > >     ...
> > > }
> > >
> > > Table names, then, are an aggregation of 3 Identifiers: one for
> catalog,
> > > one for schema, one for table name.  Same for named constraints
> > > (ultimately, which is part of a improvement for 6.0 to allow indexes,
> > > constraints, etc to be created in a separate schema from tables).
> > >
> > > Since a major goal for 5.0 is to continue to use the
> > org.hibernate.mapping
> > > package as the representation of the mapping information, we obviously
> > want
> > > to minimize changes there to only what is completely essential.  To
> that
> > > end, if we are going to use Identifier over String stuff in the
> > > org.hibernate.mapping package will need to deal with both; internally
> > they
> > > will hold the Identifier and use that to implement the String-based
> > > name-related methods they expose.
> > >
> > > Lastly I wanted to discuss the details of the logical names.  For
> tables,
> > > we currently qualify the table name with the catalog/schema info.
> There
> > is
> > > a mismatch in this regard when it comes to remaining a pure JPA
> > > implementation.  Consider @Column( ..., table="some_table").
> Ultimately
> > we
> > > need to be able to qualify that with catalog/schema in order to be able
> > to
> > > construct a matching logical name (to be able to pair that with the
> > > referenced org.hibernate.mapping.Table later).  This is trivial when
> > table
> > > names are unique across all the catalogs/schemas (when there is only
> one
> > > "some_table" in all the mapped catalogs/schemas).  But is poses a
> problem
> > > when the same table name is used from different schemas (e.g., when
> > > "some_table" is mapped from both "schema1" and "schema2").  So we have
> a
> > > choice.  Since JPA does not say what is legal/illegal for the
> > @Column.table
> > > attribute, it is feasible for us to allow @Column.table to contain the
> > > catalog/schema information in these cases as a selector.  The only
> other
> > > option I can see is to define a limitation that says that a table name
> > must
> > > be unique for a given entity across all catalogs/schemas.  I don't
> think
> > > that is generally a restrictive limitation.  What are y'alls thoughts?
> > > Perhaps this is one argument for allowing pluggable
> > LogicalNamingStrategy?
> > > _______________________________________________
> > > 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 Jan 14 16:20:04 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 14 Jan 2015 15:20:04 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CADGJaX8VU1Tt-U9T4zmK815meVQoh2hpUsqGXp-g06kPAACKfw@mail.gmail.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
	<20150114103848.GB75173@Sarmakand-4.local>
	<CAFdSV9sfaYn9sXUhEHHWg7oMUDLXk9cb38257xq51dYdwZ==cw@mail.gmail.com>
	<CADGJaX8VU1Tt-U9T4zmK815meVQoh2hpUsqGXp-g06kPAACKfw@mail.gmail.com>
Message-ID: <CAFdSV9tL4qw5j4rpE0DvTopQ4+kHzdS=r2oVgz6jfxBh0o4+GQ@mail.gmail.com>

On Wed, Jan 14, 2015 at 11:14 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> 2015-01-14 16:19 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>
>> Something like:
>>
>>
>> public interface ImplicitNamingStrategy {
>>   public Identifier determinePrimaryTableName(ImplicitEntityNameSource
>> source);
>>
>>   public Identifier determineJoinTableName(ImplicitJoinTableNameSource
>> source);
>>
>>   public Identifier
>> determineCollectionTableName(ImplicitCollectionTableNameSource
>> source);
>>
>>   public Identifier
>> determineDiscriminatorColumnName(ImplicitDiscriminatorColumnNameSource
>> source);
>>
>>     public Identifier
>> determineTenantIdColumnName(ImplicitTenantIdColumnNameSource
>> source);
>>
>>   public Identifier
>> determineAttributeColumnName(ImplicitAttributeColumnNameSource
>> source);
>>
>>   public Identifier
>> determineCollectionJoinColumnName(ImplicitCollectionJoinColumnNameSource
>> source);
>>
>>     ...
>> }
>>
>>
>> The sources are simply parameter objects providing access to information
>> needed to determine the implicit name.  For example:
>>
>> /**
>>  * Defines the source for entity naming.  Between legacy Hibernate
>> requirements and
>>  * JPA requirements this is, unfortunately, multi-sourced.  This contract
>> allows
>>  * access to all source values.
>>  *
>>  * @author Steve Ebersole
>>  */
>> public interface ImplicitEntityNamingSource {
>>     /**
>>      * The FQN of the entity class.  Note, this may be {@code null} in the
>> case
>>      * of (non-JPA-compliant) dynamic entities).
>>   *
>>      * @return The entity class FQN, or {@code null} if a dynamic entity.
>>   */
>>   public String getEntityClassName();
>>
>>   /**
>>      * Get the explicitly specified Hibernate entity name.  The Hibernate
>> name is
>>   * very much different from the JPA concept of entity name.
>>   *
>>   * @return The explicitly specified entity name
>>   */
>>   public String getExplicitEntityName();
>>
>>   /**
>>   * The Hibernate entity name.  This might be either:<ul>
>>   *     <li>The explicitly specified entity name, if one</li>
>>   *     <li>The unqualified entity class name if no entity name was
>> explicitly specified</li>
>>   * </ul>
>>   *
>>    * @return The Hibernate entity name
>>   */
>>   public String getEntityName();
>>
>>   /**
>>  * The JPA-specific entity name.  See {@link
>> javax.persistence.Entity#name()} for details.
>>      *
>>   * @return The JPA entity name, if one was specified.  May return {@code
>> null} if one
>>   * was not explicitly specified.
>>   */
>>   public String getJpaEntityName();
>> }
>>
>> etc...
>>
>> And then:
>>
>> public interface PhysicalNamingStrategy {
>>     public Identifier toPhysicalCatalogName(Identifier name);
>>
>>     public Identifier toPhysicalSchemaName(Identifier name);
>>
>>     public Identifier toPhysicalTableName(Identifier name);
>>
>>     public Identifier toPhysicalColumnName(Identifier name);
>> }
>>
>>
> So why is PhysicalNamingStrategy returning Identifiers and not Strings? I
> think I find the double usage of Identifier for logical names (or
> "components" thereof) and physical names somewhat irritating. As the
> physical name I'd have expected just the "rendered" String as to be passed
> to the driver.
>

First, technically, the "physical" name (the one we send to the database)
needs to be qualified.  So if this is really resolving to that level, we'd
actually need to have:

public interface PhysicalNamingStrategy {
    public Identifier toPhysicalTableName(Identifier catalog, Identifier
schema, Identifier table);

    public Identifier toPhysicalColumnName(Identifier name);
}

So you think the naming strategy that is supplied by the user should be the
thing that interprets Dialect-specific quoting, Dialect-specific
qualifying, etc?  For example, consider:

Identifier catalogName = new Identifier( "some_catalog", true );
Identifier schemaName = new Identifier( "some_schema", true );
Identifier tableName = new Identifier( "some_table", true );
String physicalName =
physicalNamingStrategy.toPhysicalTableName(catalogName, schemaName,
tableName );

Do you really think it is best design to have PhysicalNamingStrategy (quite
often a user-supplied impl) have to deal with Dialect differences in
qualifying names and quoting names?  Aka, is it really the best design to
have users have to understand to return:
1) "some_schema"."some_table"@"some_catalog" - for Oracle
2) [some_catalog].[some_schema].[some_table] - for SQLServer
3) etc...

IMO it is better to simply have PhysicalNamingStrategy deal with each
component, and then the Hibernate code that calls PhysicalNamingStrategy be
the one that renders them to a properly qualified String:

Identifier catalogName = new Identifier( "some_catalog", true );
Identifier schemaName = new Identifier( "some_schema", true );
Identifier tableName = new Identifier( "some_table", true );

Identifier physicalCatalogName =
physicalNamingStrategy.toPhysicalCatalogName(catalogName);
Identifier physicalSchemaName =
physicalNamingStrategy.toPhysicalSchemaName(schemaName);
Identifier physicalTableName = physicalNaming
Strategy.toPhysicalTableName(tableName);

String qualifiedName = renderQualifiedTableName(physicalCatalogName,
physicalSchemaName, physicalTableName);

This fits a lot better too with the code as I'd eventually like to see it
(as it exists on metamodel branch) where the catalog/schema combo is used
as a hierarchical container for tables, etc.  There we would ask the
PhysicalNamingStrategy to handle each catalog/schema once.




>
> I think ultimately it makes sense to pass some additional information
>> into PhysicalNamingStrategy to give access to Dialect, etc.
>>
>
> Interesting; As we had already discussed recently, that raises the
> question of how to evolve the interface in a compatible way.
>
> Java 8's default methods of course help, but until we can rely on that, I
> find using abstract classes rather than interfaces attractive for such
> contracts. With these, a method such as void
> initialize(SomeInitializationContext) can be easily added, and
> implementations can override it in a future version if they wish. Or you
> foresee some sort of context parameter on the actual methods of the
> contract.
>

I am not following here.  Maybe you are thinking I meant that the
"additional information" would be passed to the PhysicalNamingStrategy
instance directly (injected as it were).  I just meant expanding the
parameters.  Naively:


public interface PhysicalNamingStrategy {
  public Identifier toPhysicalCatalogName(Identifier name, Dialect dialect);
  public Identifier toPhysicalSchemaName(Identifier name, Dialect dialect);
    ...
}

Although, you know how I generally prefer "parameter objects".


>
>
>>
>> On Wed, Jan 14, 2015 at 4:38 AM, Hardy Ferentschik <hardy at hibernate.org>
>> wrote:
>>
>> > Hi,
>> >
>> > +1 for ImplicitNamingStrategy and PhysicalNamingStrategy
>> > What would be the contract of these strategies?
>> >
>> > I don't think LogicalNamingStrategy is necessary. I think this might
>> > just get too complicated for a user. Also, iiuc the logical name is for
>> > internal lookups.
>> >
>> > +1 for actual identifier classes. I think the code would become easier
>> to
>> > understand
>> > and hopefully safer with these typed classes. I liked this approach when
>> > working
>> > on the metamodel branch. I would, however, not make it an interface. I
>> > also see
>> > this as a pre-mature optimisation
>> >
>> > > Since JPA does not say what is legal/illegal for the @Column.table
>> > > attribute, it is feasible for us to allow @Column.table to contain the
>> > > catalog/schema information in these cases as a selector..
>> >
>> > What exactly do you mean with 'selector'?
>> >
>> > --Hardy
>> >
>> >
>> >
>> > On Tue, Jan 13, 2015 at 12:43:37PM -0600, Steve Ebersole wrote:
>> > > As I am working on 5.0, one of the things I am trying to accomplish
>> is to
>> > > make the handling of table/column names more consistent and better
>> > > defined.  The first step in that is to properly define the terms used
>> > often
>> > > throughout the codebase.
>> > >
>> > > The first level of naming is the "given" name of a table/column.  The
>> > given
>> > > name might be:
>> > > * explicit - explicitly specified by the user, as in @Table(
>> > > name="explicit_name" )
>> > > * implicit - not explicitly specified by the user and thus implicitly
>> > > determined (by JPA rules, "naming strategy", etc).
>> > >
>> > > Next, we have a logical name which is a normalized form of the "given"
>> > > name.  This is the form used to reference tables/columns internally.
>> > E.g.,
>> > > its how we resolve @Column(..., table="xyz").  More on this form
>> later.
>> > >
>> > > Finally we have the physical name of the thing, which is the actual
>> name
>> > of
>> > > the table/column in the database.  Again, this is generally a
>> > normalization
>> > > of the given name based on Dialect, "naming strategy", etc.
>> > >
>> > > Today, we have a very messy concept called a NamingStrategy.  I say
>> it is
>> > > messy because it tries to combine unrelated concerns.  So I still
>> plan to
>> > > split this as I have outlined elsewhere into:
>> > > 1) ImplicitNamingStrategy
>> > > 2) PhysicalNamingStrategy
>> > >
>> > > Which brings up my first question to y'all.  Do we need a contract for
>> > > LogicalNamingStrategy?  As I have said, the logical names are the
>> things
>> > > used to resolve references.  Allowing people to plug in custom
>> strategies
>> > > for how that normalization works could be very dangerous.  But even
>> more
>> > > than that, is it really interesting to be able to hook into that
>> process?
>> > >
>> > > Historically, these names are all represented by String.  So I also
>> > propose
>> > > to shift this to use that Identifier class we developed for the
>> metamodel
>> > > redesign.  For those that may be unfamiliar, it essentially combines
>> the
>> > > String name with a "quoted" boolean:
>> > >
>> > > public class Identifier {
>> > >   private final String text;
>> > >   private final boolean isQuoted;
>> > >     ...
>> > > }
>> > >
>> > > Table names, then, are an aggregation of 3 Identifiers: one for
>> catalog,
>> > > one for schema, one for table name.  Same for named constraints
>> > > (ultimately, which is part of a improvement for 6.0 to allow indexes,
>> > > constraints, etc to be created in a separate schema from tables).
>> > >
>> > > Since a major goal for 5.0 is to continue to use the
>> > org.hibernate.mapping
>> > > package as the representation of the mapping information, we obviously
>> > want
>> > > to minimize changes there to only what is completely essential.  To
>> that
>> > > end, if we are going to use Identifier over String stuff in the
>> > > org.hibernate.mapping package will need to deal with both; internally
>> > they
>> > > will hold the Identifier and use that to implement the String-based
>> > > name-related methods they expose.
>> > >
>> > > Lastly I wanted to discuss the details of the logical names.  For
>> tables,
>> > > we currently qualify the table name with the catalog/schema info.
>> There
>> > is
>> > > a mismatch in this regard when it comes to remaining a pure JPA
>> > > implementation.  Consider @Column( ..., table="some_table").
>> Ultimately
>> > we
>> > > need to be able to qualify that with catalog/schema in order to be
>> able
>> > to
>> > > construct a matching logical name (to be able to pair that with the
>> > > referenced org.hibernate.mapping.Table later).  This is trivial when
>> > table
>> > > names are unique across all the catalogs/schemas (when there is only
>> one
>> > > "some_table" in all the mapped catalogs/schemas).  But is poses a
>> problem
>> > > when the same table name is used from different schemas (e.g., when
>> > > "some_table" is mapped from both "schema1" and "schema2").  So we
>> have a
>> > > choice.  Since JPA does not say what is legal/illegal for the
>> > @Column.table
>> > > attribute, it is feasible for us to allow @Column.table to contain the
>> > > catalog/schema information in these cases as a selector.  The only
>> other
>> > > option I can see is to define a limitation that says that a table name
>> > must
>> > > be unique for a given entity across all catalogs/schemas.  I don't
>> think
>> > > that is generally a restrictive limitation.  What are y'alls thoughts?
>> > > Perhaps this is one argument for allowing pluggable
>> > LogicalNamingStrategy?
>> > > _______________________________________________
>> > > 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  Thu Jan 15 07:42:14 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 15 Jan 2015 12:42:14 +0000
Subject: [hibernate-dev] Fwd: Hibernate ORM modules published as
 major.minor and an alias for main
In-Reply-To: <9510D99E-78C6-4523-9292-40578000DCB9@hibernate.org>
References: <54B699C3.7030109@redhat.com>
	<9510D99E-78C6-4523-9292-40578000DCB9@hibernate.org>
Message-ID: <CAFm4XO3TOaVG2qvz5A9LYzVo19RZcDbE9MXfo659KBYaWAZ7WQ@mail.gmail.com>

Hi Scott,
I'm not sure I completely understood your email, but from the example
it looks like you're having the alias relation in the opposite
direction.

We would need to have the actual jars into a module which has the
precise identifier, to match exactly the jars it contains.
Then we'd add an alias to specify that the "main" slot is the specific version.

For example:

## Actual Module
<module xmlns="urn:jboss:module:1.3" name="org.hibernate" slot="4.3.8.Final">
    <resources>
        <resource-root path="xyz-4.3.8.Final" />
        <....
    </resources>
   ...
</module>

## The alias
<module-alias xmlns="urn:jboss:module:1.3"
    name="org.hibernate" slot="main"
    target-name="org.hibernate" target-slot="4.3.8.Final" />

By using this structure you can allow most applications to simply
depend on "org.hibernate" at slot "main". This is useful for the
majority of users, who know they want to depend on Hibernate and are
not too fuzzy about the version they use, or simply want the
"recommended" version, which is essentially what you decide is by
pulling upgrades into WildFly.

But some of our frameworks who might need to depend on a specific
version of ORM would have the option to explicitly depend on
"org.hibernate" slot "4.3.8.Final", which is what we occasionally
need.
Also this would make it possible for the ORM project to release
"update packs", say a version 4.3.9.Final is released soon: users
would be able to drop this into their application server using slot
"4.3.9.Final" without risking to break other applications.

We could also be a bit more fine-grained: are you still keeping
Hibernate 3 around in WildFly 9?
If yes, you might want to have a structure like this one:

## Actual Module
<module xmlns="urn:jboss:module:1.3" name="org.hibernate" slot="4.3.8.Final">
    <resources>
        <resource-root path="xyz-4.3.8.Final" />
    </resources>
   ...
</module>

## The 4.x alias
<module-alias xmlns="urn:jboss:module:1.3"
    name="org.hibernate" slot="4.x"
    target-name="org.hibernate" target-slot="4.3.8.Final" />

## The main alias
<module-alias xmlns="urn:jboss:module:1.3"
    name="org.hibernate" slot="main"
    target-name="org.hibernate" target-slot="4.x" />

One could also think of introducing a 4.3.x level.. possibilities are
endless but the priority for us would be to be able to call out a
specific version.

Thanks,
Sanne



On 14 January 2015 at 17:12, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> FYI
>
>> Begin forwarded message:
>>
>> Date: 14 Jan 2015 17:30:59 CET
>> From: Scott Marlow <smarlow at redhat.com>
>> To: Emmanuel Bernard <emmanuel at hibernate.org>
>> Subject: Re: Hibernate ORM modules published as major.minor and an alias for main
>>
>> Hi Emmanuel,
>>
>> On 01/14/2015 11:06 AM, Emmanuel Bernard wrote:
>>> Hi Scott,
>>>
>>> In the f2f we discussed the idea of having ORM being published as major.minor and have an alias form main to the default WildFly targeted version.
>>> Is that in and for which WildFly version?
>>
>> I created https://issues.jboss.org/browse/WFLY-4021 and https://github.com/wildfly/wildfly/pull/6883 which got merged into WildFly 9.0.
>>
>> The change is that modules/system/layers/base/org/hibernate/4.3/module.xml was added and contains:
>> "
>> <module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate.main" slot="4.3" target-name="org.hibernate"/>
>> "
>>
>> I think this is wrong though, as it should be:
>>
>> "
>> <module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate" slot="4.3" target-name="org.hibernate"/>
>> "
>>
>> I'll reopen and push a new pull request.
>>
>>
>>>
>>> I am just trying the catch up.
>>>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From smarlow at redhat.com  Thu Jan 15 08:56:03 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 15 Jan 2015 08:56:03 -0500
Subject: [hibernate-dev] Fwd: Hibernate ORM modules published as
 major.minor and an alias for main
In-Reply-To: <CAFm4XO3TOaVG2qvz5A9LYzVo19RZcDbE9MXfo659KBYaWAZ7WQ@mail.gmail.com>
References: <54B699C3.7030109@redhat.com>
	<9510D99E-78C6-4523-9292-40578000DCB9@hibernate.org>
	<CAFm4XO3TOaVG2qvz5A9LYzVo19RZcDbE9MXfo659KBYaWAZ7WQ@mail.gmail.com>
Message-ID: <54B7C6F3.1060404@redhat.com>

The change I mentioned for WFLY-4021, is merged in for WildFly 9.0.

On 01/15/2015 07:42 AM, Sanne Grinovero wrote:
> Hi Scott,
> I'm not sure I completely understood your email, but from the example
> it looks like you're having the alias relation in the opposite
> direction.

The WFLY-4021 change allows an application to depend on a specific 
major.minor version of Hibernate ORM:

<property name="jboss.as.jpa.providerModule" value="org.hibernate:4.3" />

>
> We would need to have the actual jars into a module which has the
> precise identifier, to match exactly the jars it contains.
> Then we'd add an alias to specify that the "main" slot is the specific version.

When we talked at the f2f, I said that we would do major.minor, I think 
that is the summary notes from the discussion.

If we were to reverse the definitions, so that org.hibernate:main is an 
alias for a specific version of ORM (whether its using major.minor or 
major.minor.micro, it makes no difference to me) and that offers the 
advantages that your thinking of.

Something to keep in mind, in this multiple ORM version world, is that 
the static javax.persistence api is not aware of modules currently.  By 
the fact that WildFly always loads org.hibernate:main first, 
org.hibernate:main is always first in the list returned by 
PersistenceProviderResolver.getPersistenceProviders().  In the module 
aware (container) deployment code in WildFly, we do check if the 
persistence unit specifies a jboss.as.jpa.providerModule property and 
use that to load the persistence provider from the specified module.


>
> For example:
>
> ## Actual Module
> <module xmlns="urn:jboss:module:1.3" name="org.hibernate" slot="4.3.8.Final">
>      <resources>
>          <resource-root path="xyz-4.3.8.Final" />
>          <....
>      </resources>
>     ...
> </module>
>
> ## The alias
> <module-alias xmlns="urn:jboss:module:1.3"
>      name="org.hibernate" slot="main"
>      target-name="org.hibernate" target-slot="4.3.8.Final" />
>
> By using this structure you can allow most applications to simply
> depend on "org.hibernate" at slot "main". This is useful for the
> majority of users, who know they want to depend on Hibernate and are
> not too fuzzy about the version they use, or simply want the
> "recommended" version, which is essentially what you decide is by
> pulling upgrades into WildFly.
>
> But some of our frameworks who might need to depend on a specific
> version of ORM would have the option to explicitly depend on
> "org.hibernate" slot "4.3.8.Final", which is what we occasionally
> need.
> Also this would make it possible for the ORM project to release
> "update packs", say a version 4.3.9.Final is released soon: users
> would be able to drop this into their application server using slot
> "4.3.9.Final" without risking to break other applications.
>
> We could also be a bit more fine-grained: are you still keeping
> Hibernate 3 around in WildFly 9?

My plan was to remove the Hibernate 3 integration code.  I started doing 
that about a year ago or so, on a WildFly branch that (almost) works 
against Hibernate master from back then.  That branch is very dusty now.

Is there going to be a stable ORM 5.0 branch soon?  At some point, we 
can resume integrating Jipijapa with ORM 5.0 and integrating that with 
WildFly (not sure if that will be WildFly 9 or 10).


> If yes, you might want to have a structure like this one:
>
> ## Actual Module
> <module xmlns="urn:jboss:module:1.3" name="org.hibernate" slot="4.3.8.Final">
>      <resources>
>          <resource-root path="xyz-4.3.8.Final" />
>      </resources>
>     ...
> </module>
>
> ## The 4.x alias
> <module-alias xmlns="urn:jboss:module:1.3"
>      name="org.hibernate" slot="4.x"
>      target-name="org.hibernate" target-slot="4.3.8.Final" />
>
> ## The main alias
> <module-alias xmlns="urn:jboss:module:1.3"
>      name="org.hibernate" slot="main"
>      target-name="org.hibernate" target-slot="4.x" />
>
> One could also think of introducing a 4.3.x level.. possibilities are
> endless but the priority for us would be to be able to call out a
> specific version.
>
> Thanks,
> Sanne
>
>
>
> On 14 January 2015 at 17:12, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> FYI
>>
>>> Begin forwarded message:
>>>
>>> Date: 14 Jan 2015 17:30:59 CET
>>> From: Scott Marlow <smarlow at redhat.com>
>>> To: Emmanuel Bernard <emmanuel at hibernate.org>
>>> Subject: Re: Hibernate ORM modules published as major.minor and an alias for main
>>>
>>> Hi Emmanuel,
>>>
>>> On 01/14/2015 11:06 AM, Emmanuel Bernard wrote:
>>>> Hi Scott,
>>>>
>>>> In the f2f we discussed the idea of having ORM being published as major.minor and have an alias form main to the default WildFly targeted version.
>>>> Is that in and for which WildFly version?
>>>
>>> I created https://issues.jboss.org/browse/WFLY-4021 and https://github.com/wildfly/wildfly/pull/6883 which got merged into WildFly 9.0.
>>>
>>> The change is that modules/system/layers/base/org/hibernate/4.3/module.xml was added and contains:
>>> "
>>> <module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate.main" slot="4.3" target-name="org.hibernate"/>
>>> "
>>>
>>> I think this is wrong though, as it should be:
>>>
>>> "
>>> <module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate" slot="4.3" target-name="org.hibernate"/>
>>> "
>>>
>>> I'll reopen and push a new pull request.
>>>
>>>
>>>>
>>>> I am just trying the catch up.
>>>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Jan 15 09:12:01 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 15 Jan 2015 08:12:01 -0600
Subject: [hibernate-dev] Fwd: Hibernate ORM modules published as
 major.minor and an alias for main
In-Reply-To: <54B7C6F3.1060404@redhat.com>
References: <54B699C3.7030109@redhat.com>
	<9510D99E-78C6-4523-9292-40578000DCB9@hibernate.org>
	<CAFm4XO3TOaVG2qvz5A9LYzVo19RZcDbE9MXfo659KBYaWAZ7WQ@mail.gmail.com>
	<54B7C6F3.1060404@redhat.com>
Message-ID: <CAFdSV9uw1nFZsQ=J2n7ZKh4G4j+4kPHLadgXdz1JDUq8SaNs3g@mail.gmail.com>

master is that branch.  But remember that we pulled back the scope for 5.0.


On Thu, Jan 15, 2015 at 7:56 AM, Scott Marlow <smarlow at redhat.com> wrote:

> The change I mentioned for WFLY-4021, is merged in for WildFly 9.0.
>
> On 01/15/2015 07:42 AM, Sanne Grinovero wrote:
> > Hi Scott,
> > I'm not sure I completely understood your email, but from the example
> > it looks like you're having the alias relation in the opposite
> > direction.
>
> The WFLY-4021 change allows an application to depend on a specific
> major.minor version of Hibernate ORM:
>
> <property name="jboss.as.jpa.providerModule" value="org.hibernate:4.3" />
>
> >
> > We would need to have the actual jars into a module which has the
> > precise identifier, to match exactly the jars it contains.
> > Then we'd add an alias to specify that the "main" slot is the specific
> version.
>
> When we talked at the f2f, I said that we would do major.minor, I think
> that is the summary notes from the discussion.
>
> If we were to reverse the definitions, so that org.hibernate:main is an
> alias for a specific version of ORM (whether its using major.minor or
> major.minor.micro, it makes no difference to me) and that offers the
> advantages that your thinking of.
>
> Something to keep in mind, in this multiple ORM version world, is that
> the static javax.persistence api is not aware of modules currently.  By
> the fact that WildFly always loads org.hibernate:main first,
> org.hibernate:main is always first in the list returned by
> PersistenceProviderResolver.getPersistenceProviders().  In the module
> aware (container) deployment code in WildFly, we do check if the
> persistence unit specifies a jboss.as.jpa.providerModule property and
> use that to load the persistence provider from the specified module.
>
>
> >
> > For example:
> >
> > ## Actual Module
> > <module xmlns="urn:jboss:module:1.3" name="org.hibernate"
> slot="4.3.8.Final">
> >      <resources>
> >          <resource-root path="xyz-4.3.8.Final" />
> >          <....
> >      </resources>
> >     ...
> > </module>
> >
> > ## The alias
> > <module-alias xmlns="urn:jboss:module:1.3"
> >      name="org.hibernate" slot="main"
> >      target-name="org.hibernate" target-slot="4.3.8.Final" />
> >
> > By using this structure you can allow most applications to simply
> > depend on "org.hibernate" at slot "main". This is useful for the
> > majority of users, who know they want to depend on Hibernate and are
> > not too fuzzy about the version they use, or simply want the
> > "recommended" version, which is essentially what you decide is by
> > pulling upgrades into WildFly.
> >
> > But some of our frameworks who might need to depend on a specific
> > version of ORM would have the option to explicitly depend on
> > "org.hibernate" slot "4.3.8.Final", which is what we occasionally
> > need.
> > Also this would make it possible for the ORM project to release
> > "update packs", say a version 4.3.9.Final is released soon: users
> > would be able to drop this into their application server using slot
> > "4.3.9.Final" without risking to break other applications.
> >
> > We could also be a bit more fine-grained: are you still keeping
> > Hibernate 3 around in WildFly 9?
>
> My plan was to remove the Hibernate 3 integration code.  I started doing
> that about a year ago or so, on a WildFly branch that (almost) works
> against Hibernate master from back then.  That branch is very dusty now.
>
> Is there going to be a stable ORM 5.0 branch soon?  At some point, we
> can resume integrating Jipijapa with ORM 5.0 and integrating that with
> WildFly (not sure if that will be WildFly 9 or 10).
>
>
> > If yes, you might want to have a structure like this one:
> >
> > ## Actual Module
> > <module xmlns="urn:jboss:module:1.3" name="org.hibernate"
> slot="4.3.8.Final">
> >      <resources>
> >          <resource-root path="xyz-4.3.8.Final" />
> >      </resources>
> >     ...
> > </module>
> >
> > ## The 4.x alias
> > <module-alias xmlns="urn:jboss:module:1.3"
> >      name="org.hibernate" slot="4.x"
> >      target-name="org.hibernate" target-slot="4.3.8.Final" />
> >
> > ## The main alias
> > <module-alias xmlns="urn:jboss:module:1.3"
> >      name="org.hibernate" slot="main"
> >      target-name="org.hibernate" target-slot="4.x" />
> >
> > One could also think of introducing a 4.3.x level.. possibilities are
> > endless but the priority for us would be to be able to call out a
> > specific version.
> >
> > Thanks,
> > Sanne
> >
> >
> >
> > On 14 January 2015 at 17:12, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >> FYI
> >>
> >>> Begin forwarded message:
> >>>
> >>> Date: 14 Jan 2015 17:30:59 CET
> >>> From: Scott Marlow <smarlow at redhat.com>
> >>> To: Emmanuel Bernard <emmanuel at hibernate.org>
> >>> Subject: Re: Hibernate ORM modules published as major.minor and an
> alias for main
> >>>
> >>> Hi Emmanuel,
> >>>
> >>> On 01/14/2015 11:06 AM, Emmanuel Bernard wrote:
> >>>> Hi Scott,
> >>>>
> >>>> In the f2f we discussed the idea of having ORM being published as
> major.minor and have an alias form main to the default WildFly targeted
> version.
> >>>> Is that in and for which WildFly version?
> >>>
> >>> I created https://issues.jboss.org/browse/WFLY-4021 and
> https://github.com/wildfly/wildfly/pull/6883 which got merged into
> WildFly 9.0.
> >>>
> >>> The change is that
> modules/system/layers/base/org/hibernate/4.3/module.xml was added and
> contains:
> >>> "
> >>> <module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate.main"
> slot="4.3" target-name="org.hibernate"/>
> >>> "
> >>>
> >>> I think this is wrong though, as it should be:
> >>>
> >>> "
> >>> <module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate"
> slot="4.3" target-name="org.hibernate"/>
> >>> "
> >>>
> >>> I'll reopen and push a new pull request.
> >>>
> >>>
> >>>>
> >>>> I am just trying the catch up.
> >>>>
> >>
> >> _______________________________________________
> >> 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  Thu Jan 15 09:38:12 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 15 Jan 2015 08:38:12 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9tL4qw5j4rpE0DvTopQ4+kHzdS=r2oVgz6jfxBh0o4+GQ@mail.gmail.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
	<20150114103848.GB75173@Sarmakand-4.local>
	<CAFdSV9sfaYn9sXUhEHHWg7oMUDLXk9cb38257xq51dYdwZ==cw@mail.gmail.com>
	<CADGJaX8VU1Tt-U9T4zmK815meVQoh2hpUsqGXp-g06kPAACKfw@mail.gmail.com>
	<CAFdSV9tL4qw5j4rpE0DvTopQ4+kHzdS=r2oVgz6jfxBh0o4+GQ@mail.gmail.com>
Message-ID: <CAFdSV9ubSubUyQD5CMFEaSE3jWF3dqrVH52PgEY8P_LmzKhTVA@mail.gmail.com>

So here ( I think) is a better way to categorize these terms/concepts:

   1. logical name - the "raw" name for a table or column (or schema or
   catalog).  Think along of the lines of the concept of a *logical* domain
   model in terms of a parallel.
   1. explicit logical name - the logical name is explicitly specified in
      the mapping
      2. implicit logical name - the logical name is determined via
      ImplicitNamingStrategy
   2. physical name - The name for a table or column (or schema or catalog)
   as it appears in the database.  This is the logical name with rules applied
   for quoting, identifier length restrictions, etc as controlled by the
   PhysicalNamingStrategy

The above relates specifically to unqualified forms, aka Identifiers. A
qualified name, then, is an aggregation of identifiers such as:

class QualifiedSchemaName {
    Identifier catalogName;
    Identifier schemaName;
}

class QualifiedTableName {
    QualifiedSchemaName schemaName;
    Identifier tableName;
}

class QualifiedConstraintName {
    QualifiedSchemaName schemaName;
    Identifier constraintName;
}

class QualifiedColumnName {
    QualifiedTableName tableName;
    Identifier columnName;
}

There is nothing intrinsically logical or physical about the Identifier or
Qualified* classes.  They can represent both.

Hopefully this helps clarify


On Wed, Jan 14, 2015 at 3:20 PM, Steve Ebersole <steve at hibernate.org> wrote:

> On Wed, Jan 14, 2015 at 11:14 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> 2015-01-14 16:19 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> Something like:
>>>
>>>
>>> public interface ImplicitNamingStrategy {
>>>   public Identifier determinePrimaryTableName(ImplicitEntityNameSource
>>> source);
>>>
>>>   public Identifier determineJoinTableName(ImplicitJoinTableNameSource
>>> source);
>>>
>>>   public Identifier
>>> determineCollectionTableName(ImplicitCollectionTableNameSource
>>> source);
>>>
>>>   public Identifier
>>> determineDiscriminatorColumnName(ImplicitDiscriminatorColumnNameSource
>>> source);
>>>
>>>     public Identifier
>>> determineTenantIdColumnName(ImplicitTenantIdColumnNameSource
>>> source);
>>>
>>>   public Identifier
>>> determineAttributeColumnName(ImplicitAttributeColumnNameSource
>>> source);
>>>
>>>   public Identifier
>>> determineCollectionJoinColumnName(ImplicitCollectionJoinColumnNameSource
>>> source);
>>>
>>>     ...
>>> }
>>>
>>>
>>> The sources are simply parameter objects providing access to information
>>> needed to determine the implicit name.  For example:
>>>
>>> /**
>>>  * Defines the source for entity naming.  Between legacy Hibernate
>>> requirements and
>>>  * JPA requirements this is, unfortunately, multi-sourced.  This contract
>>> allows
>>>  * access to all source values.
>>>  *
>>>  * @author Steve Ebersole
>>>  */
>>> public interface ImplicitEntityNamingSource {
>>>     /**
>>>      * The FQN of the entity class.  Note, this may be {@code null} in
>>> the
>>> case
>>>      * of (non-JPA-compliant) dynamic entities).
>>>   *
>>>      * @return The entity class FQN, or {@code null} if a dynamic entity.
>>>   */
>>>   public String getEntityClassName();
>>>
>>>   /**
>>>      * Get the explicitly specified Hibernate entity name.  The Hibernate
>>> name is
>>>   * very much different from the JPA concept of entity name.
>>>   *
>>>   * @return The explicitly specified entity name
>>>   */
>>>   public String getExplicitEntityName();
>>>
>>>   /**
>>>   * The Hibernate entity name.  This might be either:<ul>
>>>   *     <li>The explicitly specified entity name, if one</li>
>>>   *     <li>The unqualified entity class name if no entity name was
>>> explicitly specified</li>
>>>   * </ul>
>>>   *
>>>    * @return The Hibernate entity name
>>>   */
>>>   public String getEntityName();
>>>
>>>   /**
>>>  * The JPA-specific entity name.  See {@link
>>> javax.persistence.Entity#name()} for details.
>>>      *
>>>   * @return The JPA entity name, if one was specified.  May return {@code
>>> null} if one
>>>   * was not explicitly specified.
>>>   */
>>>   public String getJpaEntityName();
>>> }
>>>
>>> etc...
>>>
>>> And then:
>>>
>>> public interface PhysicalNamingStrategy {
>>>     public Identifier toPhysicalCatalogName(Identifier name);
>>>
>>>     public Identifier toPhysicalSchemaName(Identifier name);
>>>
>>>     public Identifier toPhysicalTableName(Identifier name);
>>>
>>>     public Identifier toPhysicalColumnName(Identifier name);
>>> }
>>>
>>>
>> So why is PhysicalNamingStrategy returning Identifiers and not Strings? I
>> think I find the double usage of Identifier for logical names (or
>> "components" thereof) and physical names somewhat irritating. As the
>> physical name I'd have expected just the "rendered" String as to be passed
>> to the driver.
>>
>
> First, technically, the "physical" name (the one we send to the database)
> needs to be qualified.  So if this is really resolving to that level, we'd
> actually need to have:
>
> public interface PhysicalNamingStrategy {
>     public Identifier toPhysicalTableName(Identifier catalog, Identifier
> schema, Identifier table);
>
>     public Identifier toPhysicalColumnName(Identifier name);
> }
>
> So you think the naming strategy that is supplied by the user should be
> the thing that interprets Dialect-specific quoting, Dialect-specific
> qualifying, etc?  For example, consider:
>
> Identifier catalogName = new Identifier( "some_catalog", true );
> Identifier schemaName = new Identifier( "some_schema", true );
> Identifier tableName = new Identifier( "some_table", true );
> String physicalName =
> physicalNamingStrategy.toPhysicalTableName(catalogName, schemaName,
> tableName );
>
> Do you really think it is best design to have PhysicalNamingStrategy
> (quite often a user-supplied impl) have to deal with Dialect differences in
> qualifying names and quoting names?  Aka, is it really the best design to
> have users have to understand to return:
> 1) "some_schema"."some_table"@"some_catalog" - for Oracle
> 2) [some_catalog].[some_schema].[some_table] - for SQLServer
> 3) etc...
>
> IMO it is better to simply have PhysicalNamingStrategy deal with each
> component, and then the Hibernate code that calls PhysicalNamingStrategy be
> the one that renders them to a properly qualified String:
>
> Identifier catalogName = new Identifier( "some_catalog", true );
> Identifier schemaName = new Identifier( "some_schema", true );
> Identifier tableName = new Identifier( "some_table", true );
>
> Identifier physicalCatalogName =
> physicalNamingStrategy.toPhysicalCatalogName(catalogName);
> Identifier physicalSchemaName =
> physicalNamingStrategy.toPhysicalSchemaName(schemaName);
> Identifier physicalTableName = physicalNaming
> Strategy.toPhysicalTableName(tableName);
>
> String qualifiedName = renderQualifiedTableName(physicalCatalogName,
> physicalSchemaName, physicalTableName);
>
> This fits a lot better too with the code as I'd eventually like to see it
> (as it exists on metamodel branch) where the catalog/schema combo is used
> as a hierarchical container for tables, etc.  There we would ask the
> PhysicalNamingStrategy to handle each catalog/schema once.
>
>
>
>
>>
>> I think ultimately it makes sense to pass some additional information
>>> into PhysicalNamingStrategy to give access to Dialect, etc.
>>>
>>
>> Interesting; As we had already discussed recently, that raises the
>> question of how to evolve the interface in a compatible way.
>>
>> Java 8's default methods of course help, but until we can rely on that, I
>> find using abstract classes rather than interfaces attractive for such
>> contracts. With these, a method such as void
>> initialize(SomeInitializationContext) can be easily added, and
>> implementations can override it in a future version if they wish. Or you
>> foresee some sort of context parameter on the actual methods of the
>> contract.
>>
>
> I am not following here.  Maybe you are thinking I meant that the
> "additional information" would be passed to the PhysicalNamingStrategy
> instance directly (injected as it were).  I just meant expanding the
> parameters.  Naively:
>
>
> public interface PhysicalNamingStrategy {
>   public Identifier toPhysicalCatalogName(Identifier name, Dialect
> dialect);
>   public Identifier toPhysicalSchemaName(Identifier name, Dialect
> dialect);
>     ...
> }
>
> Although, you know how I generally prefer "parameter objects".
>
>
>>
>>
>>>
>>> On Wed, Jan 14, 2015 at 4:38 AM, Hardy Ferentschik <hardy at hibernate.org>
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > +1 for ImplicitNamingStrategy and PhysicalNamingStrategy
>>> > What would be the contract of these strategies?
>>> >
>>> > I don't think LogicalNamingStrategy is necessary. I think this might
>>> > just get too complicated for a user. Also, iiuc the logical name is for
>>> > internal lookups.
>>> >
>>> > +1 for actual identifier classes. I think the code would become easier
>>> to
>>> > understand
>>> > and hopefully safer with these typed classes. I liked this approach
>>> when
>>> > working
>>> > on the metamodel branch. I would, however, not make it an interface. I
>>> > also see
>>> > this as a pre-mature optimisation
>>> >
>>> > > Since JPA does not say what is legal/illegal for the @Column.table
>>> > > attribute, it is feasible for us to allow @Column.table to contain
>>> the
>>> > > catalog/schema information in these cases as a selector..
>>> >
>>> > What exactly do you mean with 'selector'?
>>> >
>>> > --Hardy
>>> >
>>> >
>>> >
>>> > On Tue, Jan 13, 2015 at 12:43:37PM -0600, Steve Ebersole wrote:
>>> > > As I am working on 5.0, one of the things I am trying to accomplish
>>> is to
>>> > > make the handling of table/column names more consistent and better
>>> > > defined.  The first step in that is to properly define the terms used
>>> > often
>>> > > throughout the codebase.
>>> > >
>>> > > The first level of naming is the "given" name of a table/column.  The
>>> > given
>>> > > name might be:
>>> > > * explicit - explicitly specified by the user, as in @Table(
>>> > > name="explicit_name" )
>>> > > * implicit - not explicitly specified by the user and thus implicitly
>>> > > determined (by JPA rules, "naming strategy", etc).
>>> > >
>>> > > Next, we have a logical name which is a normalized form of the
>>> "given"
>>> > > name.  This is the form used to reference tables/columns internally.
>>> > E.g.,
>>> > > its how we resolve @Column(..., table="xyz").  More on this form
>>> later.
>>> > >
>>> > > Finally we have the physical name of the thing, which is the actual
>>> name
>>> > of
>>> > > the table/column in the database.  Again, this is generally a
>>> > normalization
>>> > > of the given name based on Dialect, "naming strategy", etc.
>>> > >
>>> > > Today, we have a very messy concept called a NamingStrategy.  I say
>>> it is
>>> > > messy because it tries to combine unrelated concerns.  So I still
>>> plan to
>>> > > split this as I have outlined elsewhere into:
>>> > > 1) ImplicitNamingStrategy
>>> > > 2) PhysicalNamingStrategy
>>> > >
>>> > > Which brings up my first question to y'all.  Do we need a contract
>>> for
>>> > > LogicalNamingStrategy?  As I have said, the logical names are the
>>> things
>>> > > used to resolve references.  Allowing people to plug in custom
>>> strategies
>>> > > for how that normalization works could be very dangerous.  But even
>>> more
>>> > > than that, is it really interesting to be able to hook into that
>>> process?
>>> > >
>>> > > Historically, these names are all represented by String.  So I also
>>> > propose
>>> > > to shift this to use that Identifier class we developed for the
>>> metamodel
>>> > > redesign.  For those that may be unfamiliar, it essentially combines
>>> the
>>> > > String name with a "quoted" boolean:
>>> > >
>>> > > public class Identifier {
>>> > >   private final String text;
>>> > >   private final boolean isQuoted;
>>> > >     ...
>>> > > }
>>> > >
>>> > > Table names, then, are an aggregation of 3 Identifiers: one for
>>> catalog,
>>> > > one for schema, one for table name.  Same for named constraints
>>> > > (ultimately, which is part of a improvement for 6.0 to allow indexes,
>>> > > constraints, etc to be created in a separate schema from tables).
>>> > >
>>> > > Since a major goal for 5.0 is to continue to use the
>>> > org.hibernate.mapping
>>> > > package as the representation of the mapping information, we
>>> obviously
>>> > want
>>> > > to minimize changes there to only what is completely essential.  To
>>> that
>>> > > end, if we are going to use Identifier over String stuff in the
>>> > > org.hibernate.mapping package will need to deal with both; internally
>>> > they
>>> > > will hold the Identifier and use that to implement the String-based
>>> > > name-related methods they expose.
>>> > >
>>> > > Lastly I wanted to discuss the details of the logical names.  For
>>> tables,
>>> > > we currently qualify the table name with the catalog/schema info.
>>> There
>>> > is
>>> > > a mismatch in this regard when it comes to remaining a pure JPA
>>> > > implementation.  Consider @Column( ..., table="some_table").
>>> Ultimately
>>> > we
>>> > > need to be able to qualify that with catalog/schema in order to be
>>> able
>>> > to
>>> > > construct a matching logical name (to be able to pair that with the
>>> > > referenced org.hibernate.mapping.Table later).  This is trivial when
>>> > table
>>> > > names are unique across all the catalogs/schemas (when there is only
>>> one
>>> > > "some_table" in all the mapped catalogs/schemas).  But is poses a
>>> problem
>>> > > when the same table name is used from different schemas (e.g., when
>>> > > "some_table" is mapped from both "schema1" and "schema2").  So we
>>> have a
>>> > > choice.  Since JPA does not say what is legal/illegal for the
>>> > @Column.table
>>> > > attribute, it is feasible for us to allow @Column.table to contain
>>> the
>>> > > catalog/schema information in these cases as a selector.  The only
>>> other
>>> > > option I can see is to define a limitation that says that a table
>>> name
>>> > must
>>> > > be unique for a given entity across all catalogs/schemas.  I don't
>>> think
>>> > > that is generally a restrictive limitation.  What are y'alls
>>> thoughts?
>>> > > Perhaps this is one argument for allowing pluggable
>>> > LogicalNamingStrategy?
>>> > > _______________________________________________
>>> > > 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  Thu Jan 15 09:49:13 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 15 Jan 2015 15:49:13 +0100
Subject: [hibernate-dev] Hibernate ORM modules published as major.minor
	and an alias for main
In-Reply-To: <54B7C6F3.1060404@redhat.com>
References: <54B699C3.7030109@redhat.com>
	<9510D99E-78C6-4523-9292-40578000DCB9@hibernate.org>
	<CAFm4XO3TOaVG2qvz5A9LYzVo19RZcDbE9MXfo659KBYaWAZ7WQ@mail.gmail.com>
	<54B7C6F3.1060404@redhat.com>
Message-ID: <70ED6DF3-2719-4AE0-A83F-DECADAB79FB9@hibernate.org>


> On 15 Jan 2015, at 14:56, Scott Marlow <smarlow at redhat.com> wrote:
> 
> When we talked at the f2f, I said that we would do major.minor, I think 
> that is the summary notes from the discussion.
> 
> If we were to reverse the definitions, so that org.hibernate:main is an 
> alias for a specific version of ORM (whether its using major.minor or 
> major.minor.micro, it makes no difference to me) and that offers the 
> advantages that your thinking of.

I think what Sanne propose is what he and I had in mind when we discussed at the f2f. I think it makes a bit more sense.

From smarlow at redhat.com  Thu Jan 15 10:54:24 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 15 Jan 2015 10:54:24 -0500
Subject: [hibernate-dev] Hibernate ORM modules published as major.minor
 and an alias for main
In-Reply-To: <70ED6DF3-2719-4AE0-A83F-DECADAB79FB9@hibernate.org>
References: <54B699C3.7030109@redhat.com>
	<9510D99E-78C6-4523-9292-40578000DCB9@hibernate.org>
	<CAFm4XO3TOaVG2qvz5A9LYzVo19RZcDbE9MXfo659KBYaWAZ7WQ@mail.gmail.com>
	<54B7C6F3.1060404@redhat.com>
	<70ED6DF3-2719-4AE0-A83F-DECADAB79FB9@hibernate.org>
Message-ID: <54B7E2B0.10702@redhat.com>

On 01/15/2015 09:49 AM, Emmanuel Bernard wrote:
>
>> On 15 Jan 2015, at 14:56, Scott Marlow <smarlow at redhat.com
>> <mailto:smarlow at redhat.com>> wrote:
>>
>> When we talked at the f2f, I said that we would do major.minor, I think
>> that is the summary notes from the discussion.
>>
>> If we were to reverse the definitions, so that org.hibernate:main is an
>> alias for a specific version of ORM (whether its using major.minor or
>> major.minor.micro, it makes no difference to me) and that offers the
>> advantages that your thinking of.
>
> I think what Sanne propose is what he and I had in mind when we
> discussed at the f2f. I think it makes a bit more sense.

I think that this is some sort of minimal/maximal regular expressing 
matching thing.

When we discussed this at the f2f meeting, I was thinking of the minimal 
way to do what you wanted and thought we were in sync.  Now, I 
understand the additional part of what you wanted (more of a maximal 
match).   :)

I think the simple change, is to invert the modules, like suggested. 
Such that org.hibernate:main is an alias that points to a real module.

The part that I am unsure about is including the micro version in the 
module path, which means that every release of WildFly that includes an 
upgraded Hibernate, will likely have the jars in a different path (could 
be a pain for any configuration settings that point to the Hibernate jars).

The actual module path would also move around a lot in git, which is 
annoying but I have no real complaints about that.

One question is how will the different actual "4.3.micro" modules be 
created?  Would external tools automate that or the user manually create 
them (copy all of the Hibernate jars in, setup a module.xml and 
reference needed dependencies)?

Scott

From emmanuel at hibernate.org  Thu Jan 15 11:01:31 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 15 Jan 2015 17:01:31 +0100
Subject: [hibernate-dev] Hibernate ORM modules published as major.minor
	and an alias for main
In-Reply-To: <54B7E2B0.10702@redhat.com>
References: <54B699C3.7030109@redhat.com>
	<9510D99E-78C6-4523-9292-40578000DCB9@hibernate.org>
	<CAFm4XO3TOaVG2qvz5A9LYzVo19RZcDbE9MXfo659KBYaWAZ7WQ@mail.gmail.com>
	<54B7C6F3.1060404@redhat.com>
	<70ED6DF3-2719-4AE0-A83F-DECADAB79FB9@hibernate.org>
	<54B7E2B0.10702@redhat.com>
Message-ID: <A7EC18DB-D393-4CC1-A6CC-0D3018FB8722@hibernate.org>


> On 15 Jan 2015, at 16:54, Scott Marlow <smarlow at redhat.com> wrote:
> 
> 
> The part that I am unsure about is including the micro version in the module path, which means that every release of WildFly that includes an upgraded Hibernate, will likely have the jars in a different path (could be a pain for any configuration settings that point to the Hibernate jars).
> 
> The actual module path would also move around a lot in git, which is annoying but I have no real complaints about that.

On that I am neutral. I remember Sanne advocated this but I forgot the rational nor if I was convinced ;)

From sanne at hibernate.org  Fri Jan 16 07:58:24 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 16 Jan 2015 12:58:24 +0000
Subject: [hibernate-dev] Hibernate ORM modules published as major.minor
 and an alias for main
In-Reply-To: <A7EC18DB-D393-4CC1-A6CC-0D3018FB8722@hibernate.org>
References: <54B699C3.7030109@redhat.com>
	<9510D99E-78C6-4523-9292-40578000DCB9@hibernate.org>
	<CAFm4XO3TOaVG2qvz5A9LYzVo19RZcDbE9MXfo659KBYaWAZ7WQ@mail.gmail.com>
	<54B7C6F3.1060404@redhat.com>
	<70ED6DF3-2719-4AE0-A83F-DECADAB79FB9@hibernate.org>
	<54B7E2B0.10702@redhat.com>
	<A7EC18DB-D393-4CC1-A6CC-0D3018FB8722@hibernate.org>
Message-ID: <CAFm4XO1Ghwd4tHHj5R6F5DNyQVBgrDfS9sabq_SZ1piNepxaGA@mail.gmail.com>

On 15 January 2015 at 16:01, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
> On 15 Jan 2015, at 16:54, Scott Marlow <smarlow at redhat.com> wrote:
>
>
> The part that I am unsure about is including the micro version in the module
> path, which means that every release of WildFly that includes an upgraded
> Hibernate, will likely have the jars in a different path (could be a pain
> for any configuration settings that point to the Hibernate jars).
>
> The actual module path would also move around a lot in git, which is
> annoying but I have no real complaints about that.
>
>
> On that I am neutral. I remember Sanne advocated this but I forgot the
> rational nor if I was convinced ;)

Uhm it's annoying that the file would move in git indeed. But is that
a requirement of the modules system or is that a convention which we
could challenge/refine?

For technical reasons it's obviously better to be able to pick a
specific version than not being able to; for example OGM requires a
specific version of ORM, and "4.3" is not good enough to make sure
we're using the right one. The current solution is working because
we're building against a specific Wildfly / EAP version and build the
modules taking advantage of our knowledge of the specific versions
we'll encounter in there, but it's getting more complex quickly.

I understand that some people will be happy enough to state they
depend on "ORM 4.3" rather than "ORM 4.2" and having you drop-in micro
updates as convenient. In *theory* we promise full drop-in backwards
compatibility on the micro version so we should be able to expect a
user to just need to specify the major.minor, but there's the
possibility of unintentionally breaking this promise (a bug) or - as
historical facts - either OGM or Search needing a specific version.

Sometimes it's just more practical for us to break our "internal
contracts" even in a micro release, to move on timely; in this case we
require a specific micro of ORM even though the exposed contract to
end users and other integrators is still backwards compatible.

So I think it would be better to have both module representations
(major.minor and major.minor.micro): we'd consider the .micro
variation as something people shouldn't use unless they have a
specific need.. but it's good to be able to use it when such a
specific need arises.
Still if that's too inconvenient, just having the major.minor would be
an improvement on current state :)

No other project raised such needs on the WildFly mailing list?
(except Infinispan, which is in our same needs)

Sanne

From emmanuel at hibernate.org  Fri Jan 16 08:26:42 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 16 Jan 2015 14:26:42 +0100
Subject: [hibernate-dev] Hibernate ORM modules published as major.minor
	and an alias for main
In-Reply-To: <CAFm4XO1Ghwd4tHHj5R6F5DNyQVBgrDfS9sabq_SZ1piNepxaGA@mail.gmail.com>
References: <54B699C3.7030109@redhat.com>
	<9510D99E-78C6-4523-9292-40578000DCB9@hibernate.org>
	<CAFm4XO3TOaVG2qvz5A9LYzVo19RZcDbE9MXfo659KBYaWAZ7WQ@mail.gmail.com>
	<54B7C6F3.1060404@redhat.com>
	<70ED6DF3-2719-4AE0-A83F-DECADAB79FB9@hibernate.org>
	<54B7E2B0.10702@redhat.com>
	<A7EC18DB-D393-4CC1-A6CC-0D3018FB8722@hibernate.org>
	<CAFm4XO1Ghwd4tHHj5R6F5DNyQVBgrDfS9sabq_SZ1piNepxaGA@mail.gmail.com>
Message-ID: <CF4DE8E7-3E08-4787-8D0B-9709C6A93A2D@hibernate.org>


> On 16 Jan 2015, at 13:58, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> On 15 January 2015 at 16:01, Emmanuel Bernard <emmanuel at hibernate.org <mailto:emmanuel at hibernate.org>> wrote:
>> 
>> On 15 Jan 2015, at 16:54, Scott Marlow <smarlow at redhat.com> wrote:
>> 
>> 
>> The part that I am unsure about is including the micro version in the module
>> path, which means that every release of WildFly that includes an upgraded
>> Hibernate, will likely have the jars in a different path (could be a pain
>> for any configuration settings that point to the Hibernate jars).
>> 
>> The actual module path would also move around a lot in git, which is
>> annoying but I have no real complaints about that.
>> 
>> 
>> On that I am neutral. I remember Sanne advocated this but I forgot the
>> rational nor if I was convinced ;)
> 
> Uhm it's annoying that the file would move in git indeed. But is that
> a requirement of the modules system or is that a convention which we
> could challenge/refine?
> 
> For technical reasons it's obviously better to be able to pick a
> specific version than not being able to; for example OGM requires a
> specific version of ORM, and "4.3" is not good enough to make sure
> we're using the right one. The current solution is working because
> we're building against a specific Wildfly / EAP version and build the
> modules taking advantage of our knowledge of the specific versions
> we'll encounter in there, but it's getting more complex quickly.
> 
> I understand that some people will be happy enough to state they
> depend on "ORM 4.3" rather than "ORM 4.2" and having you drop-in micro
> updates as convenient. In *theory* we promise full drop-in backwards
> compatibility on the micro version so we should be able to expect a
> user to just need to specify the major.minor, but there's the
> possibility of unintentionally breaking this promise (a bug) or - as
> historical facts - either OGM or Search needing a specific version.
> 
> Sometimes it's just more practical for us to break our "internal
> contracts" even in a micro release, to move on timely; in this case we
> require a specific micro of ORM even though the exposed contract to
> end users and other integrators is still backwards compatible.
> 
> So I think it would be better to have both module representations
> (major.minor and major.minor.micro): we'd consider the .micro
> variation as something people shouldn't use unless they have a
> specific need.. but it's good to be able to use it when such a
> specific need arises.
> Still if that's too inconvenient, just having the major.minor would be
> an improvement on current state :)
> 
> No other project raised such needs on the WildFly mailing list?
> (except Infinispan, which is in our same needs)

So let?s assume that WF 8.1.0 pushes ORM 4.3.4 and WF 8.1.1 pushes ORM 4.3.6.
And let?s assume that OGM 4.1.0 uses ORM 4.3.4 and OGM 4.1.1 uses ORM 4.3.6 (due to the issues you describe above).

If you put the major.minor.micro in WF with aliases for major.minor and main, does that really help OGM?
1. if WF 8.1.1 does not keep ORM 4.3.4 around, then I would say no. As OGM module provider, you still need to know that a given WF version has the right version or not.
2. if WF 8.1.1 does keep the old ORM versions around (i.e. ship 4.3.4 and 4.3.6), then still OGM does not know if the exact version of ORM is included.

The only solution I can think of is for OGM to also bundle the minimal ORM major.minor.micro it needs and have a way to ask the module system to use the most recent between that one and the WF one. I don?t think the module system offers than and I think they are against version range for a lot of reasons.

So turning the table, how does your solution solve or improve the problem Sanne?

From emmanuel at hibernate.org  Fri Jan 16 08:32:10 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 16 Jan 2015 14:32:10 +0100
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
Message-ID: <468EF275-F10B-4BB1-AAD2-70D67AEFC0C7@hibernate.org>

Hey,

First off thanks for working on this. This is quite a tedious topic and it?s easy to make a mess out of it. Been there, done that ;P

The real test is to make sure we can implement:

- the existing default strategy
- the existing JPA strategy
- the various NamingStrategy implementations we have in the code base

If the split you are mentioning (Physical / Implicit) can be done while still implementing the ones above, then big +1 from me. I like the idea of separating these two concepts. It could become extremely handy for OGM if we decide that the implicit values needs to be improved.
One thing that is itching me today is that OGM applies tiny tweaks to the implicit mapping. If a user wants to change the physical part, he needs to basiclaly copy or extend our strategy. This split would eliminate that problem.

I have one question, regarding logical name. The name that a given user needs to use inside say @Column( ?, table=?SomeEntity1?) is the name that comes out of the implicit naming contract (assuming the original table was implicit). Is that correct?

Note to all, when you change the implicit naming strategy, (or the logical naming strategy), then you *do* have an impact on the user mapping for artifact references. Say my implicit naming strategy defines the table name as the entity name in reverse, the user needs to use @Column(?, table=?1ytitnEemoS?). I don?t think I ever found a good solution for that. The only solution I can think of is to have an default implicit naming strategy for the mapping that is unrelated to the actual implicit naming strategy used to generate the physical artifact names. And that gets very confusing.

Also, I?ve been toying with the idea of naming strategy AOP:
- ability to lowercase all columns
- ability to replace . with _
- ability to replace $ with something else
- etc

but I don?t see a good way to do this that would remain properly understandable by everyone (incl. the same person 3 months later).

+1 to enforce that a table name must be unique for a given entity across all catalogs/schemas.

Emmanuel

> On 13 Jan 2015, at 19:43, Steve Ebersole <steve at hibernate.org> wrote:
> 
> As I am working on 5.0, one of the things I am trying to accomplish is to
> make the handling of table/column names more consistent and better
> defined.  The first step in that is to properly define the terms used often
> throughout the codebase.
> 
> The first level of naming is the "given" name of a table/column.  The given
> name might be:
> * explicit - explicitly specified by the user, as in @Table(
> name="explicit_name" )
> * implicit - not explicitly specified by the user and thus implicitly
> determined (by JPA rules, "naming strategy", etc).
> 
> Next, we have a logical name which is a normalized form of the "given"
> name.  This is the form used to reference tables/columns internally.  E.g.,
> its how we resolve @Column(..., table="xyz").  More on this form later.
> 
> Finally we have the physical name of the thing, which is the actual name of
> the table/column in the database.  Again, this is generally a normalization
> of the given name based on Dialect, "naming strategy", etc.
> 
> Today, we have a very messy concept called a NamingStrategy.  I say it is
> messy because it tries to combine unrelated concerns.  So I still plan to
> split this as I have outlined elsewhere into:
> 1) ImplicitNamingStrategy
> 2) PhysicalNamingStrategy
> 
> Which brings up my first question to y'all.  Do we need a contract for
> LogicalNamingStrategy?  As I have said, the logical names are the things
> used to resolve references.  Allowing people to plug in custom strategies
> for how that normalization works could be very dangerous.  But even more
> than that, is it really interesting to be able to hook into that process?
> 
> Historically, these names are all represented by String.  So I also propose
> to shift this to use that Identifier class we developed for the metamodel
> redesign.  For those that may be unfamiliar, it essentially combines the
> String name with a "quoted" boolean:
> 
> public class Identifier {
>  private final String text;
>  private final boolean isQuoted;
>    ...
> }
> 
> Table names, then, are an aggregation of 3 Identifiers: one for catalog,
> one for schema, one for table name.  Same for named constraints
> (ultimately, which is part of a improvement for 6.0 to allow indexes,
> constraints, etc to be created in a separate schema from tables).
> 
> Since a major goal for 5.0 is to continue to use the org.hibernate.mapping
> package as the representation of the mapping information, we obviously want
> to minimize changes there to only what is completely essential.  To that
> end, if we are going to use Identifier over String stuff in the
> org.hibernate.mapping package will need to deal with both; internally they
> will hold the Identifier and use that to implement the String-based
> name-related methods they expose.
> 
> Lastly I wanted to discuss the details of the logical names.  For tables,
> we currently qualify the table name with the catalog/schema info.  There is
> a mismatch in this regard when it comes to remaining a pure JPA
> implementation.  Consider @Column( ..., table="some_table").  Ultimately we
> need to be able to qualify that with catalog/schema in order to be able to
> construct a matching logical name (to be able to pair that with the
> referenced org.hibernate.mapping.Table later).  This is trivial when table
> names are unique across all the catalogs/schemas (when there is only one
> "some_table" in all the mapped catalogs/schemas).  But is poses a problem
> when the same table name is used from different schemas (e.g., when
> "some_table" is mapped from both "schema1" and "schema2").  So we have a
> choice.  Since JPA does not say what is legal/illegal for the @Column.table
> attribute, it is feasible for us to allow @Column.table to contain the
> catalog/schema information in these cases as a selector.  The only other
> option I can see is to define a limitation that says that a table name must
> be unique for a given entity across all catalogs/schemas.  I don't think
> that is generally a restrictive limitation.  What are y'alls thoughts?
> Perhaps this is one argument for allowing pluggable LogicalNamingStrategy?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From steve at hibernate.org  Fri Jan 16 09:10:41 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 16 Jan 2015 08:10:41 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <468EF275-F10B-4BB1-AAD2-70D67AEFC0C7@hibernate.org>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
	<468EF275-F10B-4BB1-AAD2-70D67AEFC0C7@hibernate.org>
Message-ID: <CAFdSV9u5YXMeDNdrLD++A-i8sY270BVxwiE4FJdm5pULHdOWyQ@mail.gmail.com>

On Fri, Jan 16, 2015 at 7:32 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> Hey,
>
> First off thanks for working on this. This is quite a tedious topic and
> it?s easy to make a mess out of it. Been there, done that ;P
>
> The real test is to make sure we can implement:
>
> - the existing default strategy
> - the existing JPA strategy
> - the various NamingStrategy implementations we have in the code base
>
> If the split you are mentioning (Physical / Implicit) can be done while
> still implementing the ones above, then big +1 from me. I like the idea of
> separating these two concepts. It could become extremely handy for OGM if
> we decide that the implicit values needs to be improved.
> One thing that is itching me today is that OGM applies tiny tweaks to the
> implicit mapping. If a user wants to change the physical part, he needs to
> basiclaly copy or extend our strategy. This split would eliminate that
> problem.
>

The new contracts are very specific.  So I do not think this is a problem.
However, I would not necessarily agree with needing to cover *all* of "the
various NamingStrategy implementations we have in the code base".


> I have one question, regarding logical name. The name that a given user
> needs to use inside say @Column( ?, table=?SomeEntity1?) is the name that
> comes out of the implicit naming contract (assuming the original table was
> implicit). Is that correct?
>

This is true.  But remember that this is mainly intended to signify a
secondary table, whose name cannot be implicit.  Also, I think that mixing
implicit naming and explicit naming and expecting that to work is not
necessarily a valid expectation.


>
> Note to all, when you change the implicit naming strategy, (or the logical
> naming strategy), then you *do* have an impact on the user mapping for
> artifact references. Say my implicit naming strategy defines the table name
> as the entity name in reverse, the user needs to use @Column(?,
> table=?1ytitnEemoS?). I don?t think I ever found a good solution for that.
> The only solution I can think of is to have an default implicit naming
> strategy for the mapping that is unrelated to the actual implicit naming
> strategy used to generate the physical artifact names. And that gets very
> confusing.
>
> Also, I?ve been toying with the idea of naming strategy AOP:
> - ability to lowercase all columns
> - ability to replace . with _
> - ability to replace $ with something else
> - etc
>
> but I don?t see a good way to do this that would remain properly
> understandable by everyone (incl. the same person 3 months later).
>

I can see this working by allowing naming strategy to accept "rules"
(insert better name here) that define componentized aspects of the naming
rule.  For example, consider:

new AggregatedNamingStrategy(
    AllLowerNamingRule.INSTANCE,
    DotToUnderscoreRule.INSTANCE,
    DollarSignToUnderscoreRule.INSTANCE
);

Though, I think some of these fit better in implicit naming and others in
physical naming.


> +1 to enforce that a table name must be unique for a given entity across
> all catalogs/schemas.
>
> Emmanuel
>
>

From steve at hibernate.org  Fri Jan 16 09:15:13 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 16 Jan 2015 08:15:13 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9u5YXMeDNdrLD++A-i8sY270BVxwiE4FJdm5pULHdOWyQ@mail.gmail.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
	<468EF275-F10B-4BB1-AAD2-70D67AEFC0C7@hibernate.org>
	<CAFdSV9u5YXMeDNdrLD++A-i8sY270BVxwiE4FJdm5pULHdOWyQ@mail.gmail.com>
Message-ID: <CAFdSV9t3KHZEQu8+RhgRGHOar=1Of0Q7WJ030ACXd1ZnO_F93A@mail.gmail.com>

On Fri, Jan 16, 2015 at 8:10 AM, Steve Ebersole <steve at hibernate.org> wrote:
>
> Also, I?ve been toying with the idea of naming strategy AOP:
>> - ability to lowercase all columns
>> - ability to replace . with _
>> - ability to replace $ with something else
>> - etc
>>
>> but I don?t see a good way to do this that would remain properly
>> understandable by everyone (incl. the same person 3 months later).
>>
>
> I can see this working by allowing naming strategy to accept "rules"
> (insert better name here) that define componentized aspects of the naming
> rule.  For example, consider:
>
> new AggregatedNamingStrategy(
>     AllLowerNamingRule.INSTANCE,
>     DotToUnderscoreRule.INSTANCE,
>     DollarSignToUnderscoreRule.INSTANCE
> );
>
> Though, I think some of these fit better in implicit naming and others in
> physical naming.
>

Also, we want to be very careful with stuff like "all lower naming rule".
For example, think of JPA's "quote all identifiers" setting.  In fact, to
circle back to a question Gunnar asked, this is one of the reasons I want
to have PhysicalNamingStrategy accept Identifier (with quoted/unquoted
flag) and return Identifier.

From steve at hibernate.org  Fri Jan 16 12:37:10 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 16 Jan 2015 11:37:10 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9u5YXMeDNdrLD++A-i8sY270BVxwiE4FJdm5pULHdOWyQ@mail.gmail.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
	<468EF275-F10B-4BB1-AAD2-70D67AEFC0C7@hibernate.org>
	<CAFdSV9u5YXMeDNdrLD++A-i8sY270BVxwiE4FJdm5pULHdOWyQ@mail.gmail.com>
Message-ID: <CAFdSV9ttiEsjXsDA3X1a0re2Y_GejsKxTdQ+C=ZEQOzaGxd=iw@mail.gmail.com>

On Fri, Jan 16, 2015 at 8:10 AM, Steve Ebersole <steve at hibernate.org> wrote:
>
>
>> I have one question, regarding logical name. The name that a given user
>> needs to use inside say @Column( ?, table=?SomeEntity1?) is the name that
>> comes out of the implicit naming contract (assuming the original table was
>> implicit). Is that correct?
>>
>
> This is true.  But remember that this is mainly intended to signify a
> secondary table, whose name cannot be implicit.  Also, I think that mixing
> implicit naming and explicit naming and expecting that to work is not
> necessarily a valid expectation.
>

I just wanted to clarify here a bit.  As far as I know, the only time that
this could be a problem is when we need @Column to refer to the primary
table and the name of the primary table is implicit.  But JPA designs for
that by saying that @Column is expected to refer to the primary table when
@Column#table is null or not specified.  What I was saying above was this,
imo, it is not a reasonable for this to work:

@Entity
public Customer {
    @Column( ..., table="Customer" )
    ...
}

I just think that makes no sense.

Am I missing any potential uses where @Column#table would refer to
something that might reasonably be implicit?

From emmanuel at hibernate.org  Fri Jan 16 13:09:34 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 16 Jan 2015 19:09:34 +0100
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9ttiEsjXsDA3X1a0re2Y_GejsKxTdQ+C=ZEQOzaGxd=iw@mail.gmail.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
	<468EF275-F10B-4BB1-AAD2-70D67AEFC0C7@hibernate.org>
	<CAFdSV9u5YXMeDNdrLD++A-i8sY270BVxwiE4FJdm5pULHdOWyQ@mail.gmail.com>
	<CAFdSV9ttiEsjXsDA3X1a0re2Y_GejsKxTdQ+C=ZEQOzaGxd=iw@mail.gmail.com>
Message-ID: <E1095FA3-D982-4AF4-AF49-3D713D9513B6@hibernate.org>


> On 16 Jan 2015, at 18:37, Steve Ebersole <steve at hibernate.org> wrote:
> 
> On Fri, Jan 16, 2015 at 8:10 AM, Steve Ebersole <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
> 
> I have one question, regarding logical name. The name that a given user needs to use inside say @Column( ?, table=?SomeEntity1?) is the name that comes out of the implicit naming contract (assuming the original table was implicit). Is that correct?
> 
> This is true.  But remember that this is mainly intended to signify a secondary table, whose name cannot be implicit.  Also, I think that mixing implicit naming and explicit naming and expecting that to work is not necessarily a valid expectation.
> 
> I just wanted to clarify here a bit.  As far as I know, the only time that this could be a problem is when we need @Column to refer to the primary table and the name of the primary table is implicit.  But JPA designs for that by saying that @Column is expected to refer to the primary table when @Column#table is null or not specified.  What I was saying above was this, imo, it is not a reasonable for this to work:
> 
> @Entity
> public Customer {
>     @Column( ..., table="Customer" )
>     ...
> }
> 
> I just think that makes no sense.
> 
> Am I missing any potential uses where @Column#table would refer to something that might reasonably be implicit?
> 

No but it might be more problematic for `@JoinColumn(name=?customer_fk, referencedColumnName=?id?)` where the referenced entity has `@Id String id`. That family of references might be more common than secondary tables.

From steve at hibernate.org  Fri Jan 16 17:27:38 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 16 Jan 2015 16:27:38 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <E1095FA3-D982-4AF4-AF49-3D713D9513B6@hibernate.org>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
	<468EF275-F10B-4BB1-AAD2-70D67AEFC0C7@hibernate.org>
	<CAFdSV9u5YXMeDNdrLD++A-i8sY270BVxwiE4FJdm5pULHdOWyQ@mail.gmail.com>
	<CAFdSV9ttiEsjXsDA3X1a0re2Y_GejsKxTdQ+C=ZEQOzaGxd=iw@mail.gmail.com>
	<E1095FA3-D982-4AF4-AF49-3D713D9513B6@hibernate.org>
Message-ID: <CAFdSV9vAptaR6VySYNA0y5uzsTMiZMgvJaE7FRp6YZdeNk5J1g@mail.gmail.com>

In my opinion, this blend of implicit naming and explicit naming is just
asking for problems.  But to answer your specific question, yes.. altering
the naming stratagies used could conceivably mess up cross referencing in
cases like this.
On Jan 16, 2015 12:09 PM, "Emmanuel Bernard" <emmanuel at hibernate.org> wrote:

>
> On 16 Jan 2015, at 18:37, Steve Ebersole <steve at hibernate.org> wrote:
>
> On Fri, Jan 16, 2015 at 8:10 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>>
>>
>>> I have one question, regarding logical name. The name that a given user
>>> needs to use inside say @Column( ?, table=?SomeEntity1?) is the name that
>>> comes out of the implicit naming contract (assuming the original table was
>>> implicit). Is that correct?
>>>
>>
>> This is true.  But remember that this is mainly intended to signify a
>> secondary table, whose name cannot be implicit.  Also, I think that mixing
>> implicit naming and explicit naming and expecting that to work is not
>> necessarily a valid expectation.
>>
>
> I just wanted to clarify here a bit.  As far as I know, the only time that
> this could be a problem is when we need @Column to refer to the primary
> table and the name of the primary table is implicit.  But JPA designs for
> that by saying that @Column is expected to refer to the primary table when
> @Column#table is null or not specified.  What I was saying above was this,
> imo, it is not a reasonable for this to work:
>
> @Entity
> public Customer {
>     @Column( ..., table="Customer" )
>     ...
> }
>
> I just think that makes no sense.
>
> Am I missing any potential uses where @Column#table would refer to
> something that might reasonably be implicit?
>
>
> No but it might be more problematic for `@JoinColumn(name=?customer_fk,
> referencedColumnName=?id?)` where the referenced entity has `@Id String
> id`. That family of references might be more common than secondary tables.
>

From emmanuel at hibernate.org  Mon Jan 19 08:33:48 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 19 Jan 2015 14:33:48 +0100
Subject: [hibernate-dev] Could UUID be one of the default strategy when AUTO
	is requested
Message-ID: <959B2730-93B3-4603-86FC-7ED6604782C4@hibernate.org>

Hey,

I am throwing an idea, let me know what you think.
If the return type of the id property of an entity is either String or UUID, could we automatically consider one fo the uuid strategy as the one matching AUTO?

It would be useful for Hibernate OGM but I am also thinking that it makes equal sense to Hibernate ORM users.

Thoughts? I?m sure there are incompatibilities I have not think of.

Emmanuel

From sanne at hibernate.org  Mon Jan 19 09:58:40 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 19 Jan 2015 14:58:40 +0000
Subject: [hibernate-dev] Could UUID be one of the default strategy when
 AUTO is requested
In-Reply-To: <959B2730-93B3-4603-86FC-7ED6604782C4@hibernate.org>
References: <959B2730-93B3-4603-86FC-7ED6604782C4@hibernate.org>
Message-ID: <CAFm4XO3CH-Rykubf2taw+snW9byXX4=PonGpEs0_A5rkLCgOOw@mail.gmail.com>

On 19 January 2015 at 13:33, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> Hey,
>
> I am throwing an idea, let me know what you think.
> If the return type of the id property of an entity is either String or UUID, could we automatically consider one fo the uuid strategy as the one matching AUTO?

+1
That seems spot-on for the UUID type.
For String, I wonder if someone would argue that it should actually
map to a string-encoded output of a sequence.. "1", "2" ...
I'd personally agree that this is horrible and it should default to
UUID, just wondering.

Would this violate any spec?

>
> It would be useful for Hibernate OGM but I am also thinking that it makes equal sense to Hibernate ORM users.
>
> Thoughts? I?m sure there are incompatibilities I have not think of.
>
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From gunnar at hibernate.org  Mon Jan 19 11:15:42 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 19 Jan 2015 17:15:42 +0100
Subject: [hibernate-dev] Could UUID be one of the default strategy when
 AUTO is requested
In-Reply-To: <CAFm4XO3CH-Rykubf2taw+snW9byXX4=PonGpEs0_A5rkLCgOOw@mail.gmail.com>
References: <959B2730-93B3-4603-86FC-7ED6604782C4@hibernate.org>
	<CAFm4XO3CH-Rykubf2taw+snW9byXX4=PonGpEs0_A5rkLCgOOw@mail.gmail.com>
Message-ID: <CADGJaX835ex73xLvOvjxhXRtEaj+uEkkxNK=x5-uyscprn01Xw@mail.gmail.com>

We discussed a while ago whether it should be pluggable how AUTO is
resolved:
https://lists.jboss.org/pipermail/hibernate-dev/2014-November/011948.html

I still think that's a good idea.

In the case of OGM, it may even be a bit more complex. For example with
MongoDB the following should result in IDENTITY being used (which is mapped
to store-assigned object ids) rather than UUID:

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Type(type = "objectid")
    String id;

So the @Type would have to be taken into account as well for mapping AUTO.

> For String, I wonder if someone would argue that it should actually map
to a string-encoded output of a sequence.. "1", "2" ...

I don't think you can use sequences with String (only numeric values), so
anyone having this expectation would also be unhappy as of today.

--Gunnar


2015-01-19 15:58 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> On 19 January 2015 at 13:33, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> > Hey,
> >
> > I am throwing an idea, let me know what you think.
> > If the return type of the id property of an entity is either String or
> UUID, could we automatically consider one fo the uuid strategy as the one
> matching AUTO?
>
> +1
> That seems spot-on for the UUID type.
> For String, I wonder if someone would argue that it should actually
> map to a string-encoded output of a sequence.. "1", "2" ...
> I'd personally agree that this is horrible and it should default to
> UUID, just wondering.
>
> Would this violate any spec?
>
> >
> > It would be useful for Hibernate OGM but I am also thinking that it
> makes equal sense to Hibernate ORM users.
> >
> > Thoughts? I?m sure there are incompatibilities I have not think of.
> >
> > Emmanuel
> > _______________________________________________
> > 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  Mon Jan 19 16:44:51 2015
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 19 Jan 2015 16:44:51 -0500 (EST)
Subject: [hibernate-dev] Could UUID be one of the default strategy when
 AUTO is requested
In-Reply-To: <CADGJaX835ex73xLvOvjxhXRtEaj+uEkkxNK=x5-uyscprn01Xw@mail.gmail.com>
References: <959B2730-93B3-4603-86FC-7ED6604782C4@hibernate.org>
	<CAFm4XO3CH-Rykubf2taw+snW9byXX4=PonGpEs0_A5rkLCgOOw@mail.gmail.com>
	<CADGJaX835ex73xLvOvjxhXRtEaj+uEkkxNK=x5-uyscprn01Xw@mail.gmail.com>
Message-ID: <348606175.12532473.1421703891386.JavaMail.zimbra@redhat.com>

There are some jiras for using UUIDs (in general, not specifically for IDs) for using a single mapping that would work for different dialects:
- https://hibernate.atlassian.net/browse/HHH-9562
- https://hibernate.atlassian.net/browse/HHH-9574 

It seems that these are related...

----- Original Message -----
> From: "Gunnar Morling" <gunnar at hibernate.org>
> To: "Sanne Grinovero" <sanne at hibernate.org>
> Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Monday, January 19, 2015 8:15:42 AM
> Subject: Re: [hibernate-dev] Could UUID be one of the default strategy when AUTO is requested
> 
> We discussed a while ago whether it should be pluggable how AUTO is
> resolved:
> https://lists.jboss.org/pipermail/hibernate-dev/2014-November/011948.html
> 
> I still think that's a good idea.
> 
> In the case of OGM, it may even be a bit more complex. For example with
> MongoDB the following should result in IDENTITY being used (which is mapped
> to store-assigned object ids) rather than UUID:
> 
>     @Id
>     @GeneratedValue(strategy = GenerationType.AUTO)
>     @Type(type = "objectid")
>     String id;
> 
> So the @Type would have to be taken into account as well for mapping AUTO.
> 
> > For String, I wonder if someone would argue that it should actually map
> to a string-encoded output of a sequence.. "1", "2" ...
> 
> I don't think you can use sequences with String (only numeric values), so
> anyone having this expectation would also be unhappy as of today.
> 
> --Gunnar
> 
> 
> 2015-01-19 15:58 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> 
> > On 19 January 2015 at 13:33, Emmanuel Bernard <emmanuel at hibernate.org>
> > wrote:
> > > Hey,
> > >
> > > I am throwing an idea, let me know what you think.
> > > If the return type of the id property of an entity is either String or
> > UUID, could we automatically consider one fo the uuid strategy as the one
> > matching AUTO?
> >
> > +1
> > That seems spot-on for the UUID type.
> > For String, I wonder if someone would argue that it should actually
> > map to a string-encoded output of a sequence.. "1", "2" ...
> > I'd personally agree that this is horrible and it should default to
> > UUID, just wondering.
> >
> > Would this violate any spec?
> >
> > >
> > > It would be useful for Hibernate OGM but I am also thinking that it
> > makes equal sense to Hibernate ORM users.
> > >
> > > Thoughts? I?m sure there are incompatibilities I have not think of.
> > >
> > > Emmanuel
> > > _______________________________________________
> > > 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 Jan 20 09:27:36 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 20 Jan 2015 08:27:36 -0600
Subject: [hibernate-dev] Could UUID be one of the default strategy when
 AUTO is requested
In-Reply-To: <348606175.12532473.1421703891386.JavaMail.zimbra@redhat.com>
References: <959B2730-93B3-4603-86FC-7ED6604782C4@hibernate.org>
	<CAFm4XO3CH-Rykubf2taw+snW9byXX4=PonGpEs0_A5rkLCgOOw@mail.gmail.com>
	<CADGJaX835ex73xLvOvjxhXRtEaj+uEkkxNK=x5-uyscprn01Xw@mail.gmail.com>
	<348606175.12532473.1421703891386.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9uSaVnJPSh2Lfi58HEH22ZfthsHVEZAHbYSB1RcLhs9WQ@mail.gmail.com>

I really like that thought for UUID return.  Not so convinced for String
return.

On Mon, Jan 19, 2015 at 3:44 PM, Gail Badner <gbadner at redhat.com> wrote:

> There are some jiras for using UUIDs (in general, not specifically for
> IDs) for using a single mapping that would work for different dialects:
> - https://hibernate.atlassian.net/browse/HHH-9562
> - https://hibernate.atlassian.net/browse/HHH-9574
>
> It seems that these are related...
>
> ----- Original Message -----
> > From: "Gunnar Morling" <gunnar at hibernate.org>
> > To: "Sanne Grinovero" <sanne at hibernate.org>
> > Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> > Sent: Monday, January 19, 2015 8:15:42 AM
> > Subject: Re: [hibernate-dev] Could UUID be one of the default strategy
> when AUTO is requested
> >
> > We discussed a while ago whether it should be pluggable how AUTO is
> > resolved:
> >
> https://lists.jboss.org/pipermail/hibernate-dev/2014-November/011948.html
> >
> > I still think that's a good idea.
> >
> > In the case of OGM, it may even be a bit more complex. For example with
> > MongoDB the following should result in IDENTITY being used (which is
> mapped
> > to store-assigned object ids) rather than UUID:
> >
> >     @Id
> >     @GeneratedValue(strategy = GenerationType.AUTO)
> >     @Type(type = "objectid")
> >     String id;
> >
> > So the @Type would have to be taken into account as well for mapping
> AUTO.
> >
> > > For String, I wonder if someone would argue that it should actually map
> > to a string-encoded output of a sequence.. "1", "2" ...
> >
> > I don't think you can use sequences with String (only numeric values), so
> > anyone having this expectation would also be unhappy as of today.
> >
> > --Gunnar
> >
> >
> > 2015-01-19 15:58 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >
> > > On 19 January 2015 at 13:33, Emmanuel Bernard <emmanuel at hibernate.org>
> > > wrote:
> > > > Hey,
> > > >
> > > > I am throwing an idea, let me know what you think.
> > > > If the return type of the id property of an entity is either String
> or
> > > UUID, could we automatically consider one fo the uuid strategy as the
> one
> > > matching AUTO?
> > >
> > > +1
> > > That seems spot-on for the UUID type.
> > > For String, I wonder if someone would argue that it should actually
> > > map to a string-encoded output of a sequence.. "1", "2" ...
> > > I'd personally agree that this is horrible and it should default to
> > > UUID, just wondering.
> > >
> > > Would this violate any spec?
> > >
> > > >
> > > > It would be useful for Hibernate OGM but I am also thinking that it
> > > makes equal sense to Hibernate ORM users.
> > > >
> > > > Thoughts? I?m sure there are incompatibilities I have not think of.
> > > >
> > > > Emmanuel
> > > > _______________________________________________
> > > > 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 emmanuel at hibernate.org  Tue Jan 20 10:33:14 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 20 Jan 2015 16:33:14 +0100
Subject: [hibernate-dev] Could UUID be one of the default strategy when
	AUTO is requested
In-Reply-To: <CAFdSV9uSaVnJPSh2Lfi58HEH22ZfthsHVEZAHbYSB1RcLhs9WQ@mail.gmail.com>
References: <959B2730-93B3-4603-86FC-7ED6604782C4@hibernate.org>
	<CAFm4XO3CH-Rykubf2taw+snW9byXX4=PonGpEs0_A5rkLCgOOw@mail.gmail.com>
	<CADGJaX835ex73xLvOvjxhXRtEaj+uEkkxNK=x5-uyscprn01Xw@mail.gmail.com>
	<348606175.12532473.1421703891386.JavaMail.zimbra@redhat.com>
	<CAFdSV9uSaVnJPSh2Lfi58HEH22ZfthsHVEZAHbYSB1RcLhs9WQ@mail.gmail.com>
Message-ID: <23FC3E42-C72C-4F3E-B79E-B07E52695C2F@hibernate.org>

I?ve captured some of it
https://hibernate.atlassian.net/browse/HHH-9577 <https://hibernate.atlassian.net/browse/HHH-9577>

It is probably worth doing two or three issues. Not sure.

> On 20 Jan 2015, at 15:27, Steve Ebersole <steve at hibernate.org> wrote:
> 
> I really like that thought for UUID return.  Not so convinced for String
> return.
> 
> On Mon, Jan 19, 2015 at 3:44 PM, Gail Badner <gbadner at redhat.com> wrote:
> 
>> There are some jiras for using UUIDs (in general, not specifically for
>> IDs) for using a single mapping that would work for different dialects:
>> - https://hibernate.atlassian.net/browse/HHH-9562
>> - https://hibernate.atlassian.net/browse/HHH-9574
>> 
>> It seems that these are related...
>> 
>> ----- Original Message -----
>>> From: "Gunnar Morling" <gunnar at hibernate.org>
>>> To: "Sanne Grinovero" <sanne at hibernate.org>
>>> Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
>>> Sent: Monday, January 19, 2015 8:15:42 AM
>>> Subject: Re: [hibernate-dev] Could UUID be one of the default strategy
>> when AUTO is requested
>>> 
>>> We discussed a while ago whether it should be pluggable how AUTO is
>>> resolved:
>>> 
>> https://lists.jboss.org/pipermail/hibernate-dev/2014-November/011948.html
>>> 
>>> I still think that's a good idea.
>>> 
>>> In the case of OGM, it may even be a bit more complex. For example with
>>> MongoDB the following should result in IDENTITY being used (which is
>> mapped
>>> to store-assigned object ids) rather than UUID:
>>> 
>>>    @Id
>>>    @GeneratedValue(strategy = GenerationType.AUTO)
>>>    @Type(type = "objectid")
>>>    String id;
>>> 
>>> So the @Type would have to be taken into account as well for mapping
>> AUTO.
>>> 
>>>> For String, I wonder if someone would argue that it should actually map
>>> to a string-encoded output of a sequence.. "1", "2" ...
>>> 
>>> I don't think you can use sequences with String (only numeric values), so
>>> anyone having this expectation would also be unhappy as of today.
>>> 
>>> --Gunnar
>>> 
>>> 
>>> 2015-01-19 15:58 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>> 
>>>> On 19 January 2015 at 13:33, Emmanuel Bernard <emmanuel at hibernate.org>
>>>> wrote:
>>>>> Hey,
>>>>> 
>>>>> I am throwing an idea, let me know what you think.
>>>>> If the return type of the id property of an entity is either String
>> or
>>>> UUID, could we automatically consider one fo the uuid strategy as the
>> one
>>>> matching AUTO?
>>>> 
>>>> +1
>>>> That seems spot-on for the UUID type.
>>>> For String, I wonder if someone would argue that it should actually
>>>> map to a string-encoded output of a sequence.. "1", "2" ...
>>>> I'd personally agree that this is horrible and it should default to
>>>> UUID, just wondering.
>>>> 
>>>> Would this violate any spec?
>>>> 
>>>>> 
>>>>> It would be useful for Hibernate OGM but I am also thinking that it
>>>> makes equal sense to Hibernate ORM users.
>>>>> 
>>>>> Thoughts? I?m sure there are incompatibilities I have not think of.
>>>>> 
>>>>> Emmanuel
>>>>> _______________________________________________
>>>>> 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 steve at hibernate.org  Tue Jan 20 10:36:45 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 20 Jan 2015 09:36:45 -0600
Subject: [hibernate-dev] Could UUID be one of the default strategy when
 AUTO is requested
In-Reply-To: <CAFm4XO3CH-Rykubf2taw+snW9byXX4=PonGpEs0_A5rkLCgOOw@mail.gmail.com>
References: <959B2730-93B3-4603-86FC-7ED6604782C4@hibernate.org>
	<CAFm4XO3CH-Rykubf2taw+snW9byXX4=PonGpEs0_A5rkLCgOOw@mail.gmail.com>
Message-ID: <CAFdSV9vvztLkis6cvubL2=Ln6_aWCeY5+xE+_siAfzqBh0aU_Q@mail.gmail.com>

On Mon, Jan 19, 2015 at 8:58 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 19 January 2015 at 13:33, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> > Hey,
> >
> > I am throwing an idea, let me know what you think.
> > If the return type of the id property of an entity is either String or
> UUID, could we automatically consider one fo the uuid strategy as the one
> matching AUTO?
>
> +1
> That seems spot-on for the UUID type.
> For String, I wonder if someone would argue that it should actually
> map to a string-encoded output of a sequence.. "1", "2" ...
> I'd personally agree that this is horrible and it should default to
> UUID, just wondering.
>
> Would this violate any spec?
>

The javadoc for GenerationType.AUTO does specifically say that "provider
should pick an appropriate strategy for the particular database".  Note the
*for the particular database* portion.  But it does not specifically
disallow UUID-based generation.  So I do not think we violate the spirit of
the spec if we were to do this.

From steve at hibernate.org  Tue Jan 20 10:41:58 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 20 Jan 2015 09:41:58 -0600
Subject: [hibernate-dev] Could UUID be one of the default strategy when
 AUTO is requested
In-Reply-To: <348606175.12532473.1421703891386.JavaMail.zimbra@redhat.com>
References: <959B2730-93B3-4603-86FC-7ED6604782C4@hibernate.org>
	<CAFm4XO3CH-Rykubf2taw+snW9byXX4=PonGpEs0_A5rkLCgOOw@mail.gmail.com>
	<CADGJaX835ex73xLvOvjxhXRtEaj+uEkkxNK=x5-uyscprn01Xw@mail.gmail.com>
	<348606175.12532473.1421703891386.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9uw=Eth4D6vCyDr+c9j9=Vg+34iPRLGC-B90+1Se40ObQ@mail.gmail.com>

The problem with both of these is the lack of knowing Dialect when building
the mapping model.  5.0 is a first step toward fixing that.  6.0
(metamodel) is the complete step.

In general there are a lot of things we can do knowing the Dialect while
building the mapping model, things we cannot do now.

On Mon, Jan 19, 2015 at 3:44 PM, Gail Badner <gbadner at redhat.com> wrote:

> There are some jiras for using UUIDs (in general, not specifically for
> IDs) for using a single mapping that would work for different dialects:
> - https://hibernate.atlassian.net/browse/HHH-9562
> - https://hibernate.atlassian.net/browse/HHH-9574
>
> It seems that these are related...
>
> ----- Original Message -----
> > From: "Gunnar Morling" <gunnar at hibernate.org>
> > To: "Sanne Grinovero" <sanne at hibernate.org>
> > Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> > Sent: Monday, January 19, 2015 8:15:42 AM
> > Subject: Re: [hibernate-dev] Could UUID be one of the default strategy
> when AUTO is requested
> >
> > We discussed a while ago whether it should be pluggable how AUTO is
> > resolved:
> >
> https://lists.jboss.org/pipermail/hibernate-dev/2014-November/011948.html
> >
> > I still think that's a good idea.
> >
> > In the case of OGM, it may even be a bit more complex. For example with
> > MongoDB the following should result in IDENTITY being used (which is
> mapped
> > to store-assigned object ids) rather than UUID:
> >
> >     @Id
> >     @GeneratedValue(strategy = GenerationType.AUTO)
> >     @Type(type = "objectid")
> >     String id;
> >
> > So the @Type would have to be taken into account as well for mapping
> AUTO.
> >
> > > For String, I wonder if someone would argue that it should actually map
> > to a string-encoded output of a sequence.. "1", "2" ...
> >
> > I don't think you can use sequences with String (only numeric values), so
> > anyone having this expectation would also be unhappy as of today.
> >
> > --Gunnar
> >
> >
> > 2015-01-19 15:58 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >
> > > On 19 January 2015 at 13:33, Emmanuel Bernard <emmanuel at hibernate.org>
> > > wrote:
> > > > Hey,
> > > >
> > > > I am throwing an idea, let me know what you think.
> > > > If the return type of the id property of an entity is either String
> or
> > > UUID, could we automatically consider one fo the uuid strategy as the
> one
> > > matching AUTO?
> > >
> > > +1
> > > That seems spot-on for the UUID type.
> > > For String, I wonder if someone would argue that it should actually
> > > map to a string-encoded output of a sequence.. "1", "2" ...
> > > I'd personally agree that this is horrible and it should default to
> > > UUID, just wondering.
> > >
> > > Would this violate any spec?
> > >
> > > >
> > > > It would be useful for Hibernate OGM but I am also thinking that it
> > > makes equal sense to Hibernate ORM users.
> > > >
> > > > Thoughts? I?m sure there are incompatibilities I have not think of.
> > > >
> > > > Emmanuel
> > > > _______________________________________________
> > > > 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  Tue Jan 20 16:41:28 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 20 Jan 2015 15:41:28 -0600
Subject: [hibernate-dev] index-many-to-any
Message-ID: <CAFdSV9uQ3vPMr7hKA-9o6ooODR6ydHJvU5c7BWdWObOYh16NHw@mail.gmail.com>

Anyone used this mapping construct before?  As far as I can tell, it is
incompletely defined.  Unless I am missing something, it misses allowing to
map discriminator values to classes (meta-value).

What is more concerning that that is simultaneously allows re-defining the
discriminator type (meta-type).

Is this intentional for some reason?

From emmanuel at hibernate.org  Thu Jan 22 10:48:09 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 22 Jan 2015 16:48:09 +0100
Subject: [hibernate-dev] index-many-to-any
In-Reply-To: <CAFdSV9uQ3vPMr7hKA-9o6ooODR6ydHJvU5c7BWdWObOYh16NHw@mail.gmail.com>
References: <CAFdSV9uQ3vPMr7hKA-9o6ooODR6ydHJvU5c7BWdWObOYh16NHw@mail.gmail.com>
Message-ID: <4031BD34-BD58-4DF3-BE1A-362D2A56D423@hibernate.org>

I did not. I guess a regular index or basic key with an any _value_ is much more common.

> On 20 Jan 2015, at 22:41, Steve Ebersole <steve at hibernate.org> wrote:
> 
> Anyone used this mapping construct before?  As far as I can tell, it is
> incompletely defined.  Unless I am missing something, it misses allowing to
> map discriminator values to classes (meta-value).
> 
> What is more concerning that that is simultaneously allows re-defining the
> discriminator type (meta-type).
> 
> Is this intentional for some reason?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From steve at hibernate.org  Thu Jan 22 14:21:04 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 22 Jan 2015 13:21:04 -0600
Subject: [hibernate-dev] index-many-to-any
In-Reply-To: <4031BD34-BD58-4DF3-BE1A-362D2A56D423@hibernate.org>
References: <CAFdSV9uQ3vPMr7hKA-9o6ooODR6ydHJvU5c7BWdWObOYh16NHw@mail.gmail.com>
	<4031BD34-BD58-4DF3-BE1A-362D2A56D423@hibernate.org>
Message-ID: <CAFdSV9t=4v4Uh3fqyCGasx0pfXdby969ThyCXtWeeqncSAegyQ@mail.gmail.com>

I won't at all disagree about the commonality.  But regardless, it's
defined to be allowed as the key.  My concern is that it is done in an
incomplete and inconsistent way.

I think we should either remove this feature or complete it.

On Thu, Jan 22, 2015 at 9:48 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> I did not. I guess a regular index or basic key with an any _value_ is
> much more common.
>
> > On 20 Jan 2015, at 22:41, Steve Ebersole <steve at hibernate.org> wrote:
> >
> > Anyone used this mapping construct before?  As far as I can tell, it is
> > incompletely defined.  Unless I am missing something, it misses allowing
> to
> > map discriminator values to classes (meta-value).
> >
> > What is more concerning that that is simultaneously allows re-defining
> the
> > discriminator type (meta-type).
> >
> > Is this intentional for some reason?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Fri Jan 23 08:18:56 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 23 Jan 2015 07:18:56 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9vAptaR6VySYNA0y5uzsTMiZMgvJaE7FRp6YZdeNk5J1g@mail.gmail.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
	<468EF275-F10B-4BB1-AAD2-70D67AEFC0C7@hibernate.org>
	<CAFdSV9u5YXMeDNdrLD++A-i8sY270BVxwiE4FJdm5pULHdOWyQ@mail.gmail.com>
	<CAFdSV9ttiEsjXsDA3X1a0re2Y_GejsKxTdQ+C=ZEQOzaGxd=iw@mail.gmail.com>
	<E1095FA3-D982-4AF4-AF49-3D713D9513B6@hibernate.org>
	<CAFdSV9vAptaR6VySYNA0y5uzsTMiZMgvJaE7FRp6YZdeNk5J1g@mail.gmail.com>
Message-ID: <CAFdSV9sRVd2sJU2rRt0UEWUfPnQEMdiYxjhrANniRpEF-jfDQg@mail.gmail.com>

Another thing to consider here...  In regards to physical naming, one of
the aspects we need to consider is to possibly shorten names based on the
maximum identifier length per Dialect[1].  PhysicalNamingStrategy is the
most natural place to put this.  However, that means when a user supplies
a PhysicalNamingStrategy the onus is on their impl to make sure this length
constraint is accomplished.

What do y'all think of that?

I don't think it is necessarily a deal-breaker.  Worst case, it would be
super easy for them to simply delegate to some standard (dumb) length
handling.  Or they could implement smarter (contextual) shortening (NUMBER
becomes NM or NO rather than NUM, e.g)


[1] - I vaguely recall seeing that certain databases allow different length
constraints for different types of identifiers (table name, versus column
name, versus constrain name, ...).  Can anyone confirm that?

On Fri, Jan 16, 2015 at 4:27 PM, Steve Ebersole <steve at hibernate.org> wrote:

> In my opinion, this blend of implicit naming and explicit naming is just
> asking for problems.  But to answer your specific question, yes.. altering
> the naming stratagies used could conceivably mess up cross referencing in
> cases like this.
> On Jan 16, 2015 12:09 PM, "Emmanuel Bernard" <emmanuel at hibernate.org>
> wrote:
>
>>
>> On 16 Jan 2015, at 18:37, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> On Fri, Jan 16, 2015 at 8:10 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>>
>>>
>>>> I have one question, regarding logical name. The name that a given user
>>>> needs to use inside say @Column( ?, table=?SomeEntity1?) is the name that
>>>> comes out of the implicit naming contract (assuming the original table was
>>>> implicit). Is that correct?
>>>>
>>>
>>> This is true.  But remember that this is mainly intended to signify a
>>> secondary table, whose name cannot be implicit.  Also, I think that mixing
>>> implicit naming and explicit naming and expecting that to work is not
>>> necessarily a valid expectation.
>>>
>>
>> I just wanted to clarify here a bit.  As far as I know, the only time
>> that this could be a problem is when we need @Column to refer to the
>> primary table and the name of the primary table is implicit.  But JPA
>> designs for that by saying that @Column is expected to refer to the primary
>> table when @Column#table is null or not specified.  What I was saying above
>> was this, imo, it is not a reasonable for this to work:
>>
>> @Entity
>> public Customer {
>>     @Column( ..., table="Customer" )
>>     ...
>> }
>>
>> I just think that makes no sense.
>>
>> Am I missing any potential uses where @Column#table would refer to
>> something that might reasonably be implicit?
>>
>>
>> No but it might be more problematic for `@JoinColumn(name=?customer_fk,
>> referencedColumnName=?id?)` where the referenced entity has `@Id String
>> id`. That family of references might be more common than secondary tables.
>>
>

From steve at hibernate.org  Fri Jan 23 08:36:57 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 23 Jan 2015 07:36:57 -0600
Subject: [hibernate-dev] Could UUID be one of the default strategy when
 AUTO is requested
In-Reply-To: <CAFdSV9uw=Eth4D6vCyDr+c9j9=Vg+34iPRLGC-B90+1Se40ObQ@mail.gmail.com>
References: <959B2730-93B3-4603-86FC-7ED6604782C4@hibernate.org>
	<CAFm4XO3CH-Rykubf2taw+snW9byXX4=PonGpEs0_A5rkLCgOOw@mail.gmail.com>
	<CADGJaX835ex73xLvOvjxhXRtEaj+uEkkxNK=x5-uyscprn01Xw@mail.gmail.com>
	<348606175.12532473.1421703891386.JavaMail.zimbra@redhat.com>
	<CAFdSV9uw=Eth4D6vCyDr+c9j9=Vg+34iPRLGC-B90+1Se40ObQ@mail.gmail.com>
Message-ID: <CAFdSV9srsb2G7qao-Q4UQDT3hpZxVAV_7=FHgyTUHGTNixj0wA@mail.gmail.com>

Just to clarify, there are 2 things here.  Gail the 2 issues you mention
are only tangentially related.

What Emmanuel is asking about it the determination of the id gen strategy
to use when we see AUTO.  The real difficulty there is that the code, as it
was originally written, is hard to isolate.  It does quite a few things and
iirc it does them in different places.

Part of what AUTO interpretation does is to set the Type name.  If we start
supporting UUID with AUTO (and again I vote we should), then that is where
these other issues come up.  I left a pretty detailed comment on HHH-9574


On Tue, Jan 20, 2015 at 9:41 AM, Steve Ebersole <steve at hibernate.org> wrote:

> The problem with both of these is the lack of knowing Dialect when
> building the mapping model.  5.0 is a first step toward fixing that.  6.0
> (metamodel) is the complete step.
>
> In general there are a lot of things we can do knowing the Dialect while
> building the mapping model, things we cannot do now.
>
> On Mon, Jan 19, 2015 at 3:44 PM, Gail Badner <gbadner at redhat.com> wrote:
>
>> There are some jiras for using UUIDs (in general, not specifically for
>> IDs) for using a single mapping that would work for different dialects:
>> - https://hibernate.atlassian.net/browse/HHH-9562
>> - https://hibernate.atlassian.net/browse/HHH-9574
>>
>> It seems that these are related...
>>
>> ----- Original Message -----
>> > From: "Gunnar Morling" <gunnar at hibernate.org>
>> > To: "Sanne Grinovero" <sanne at hibernate.org>
>> > Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
>> > Sent: Monday, January 19, 2015 8:15:42 AM
>> > Subject: Re: [hibernate-dev] Could UUID be one of the default strategy
>> when AUTO is requested
>> >
>> > We discussed a while ago whether it should be pluggable how AUTO is
>> > resolved:
>> >
>> https://lists.jboss.org/pipermail/hibernate-dev/2014-November/011948.html
>> >
>> > I still think that's a good idea.
>> >
>> > In the case of OGM, it may even be a bit more complex. For example with
>> > MongoDB the following should result in IDENTITY being used (which is
>> mapped
>> > to store-assigned object ids) rather than UUID:
>> >
>> >     @Id
>> >     @GeneratedValue(strategy = GenerationType.AUTO)
>> >     @Type(type = "objectid")
>> >     String id;
>> >
>> > So the @Type would have to be taken into account as well for mapping
>> AUTO.
>> >
>> > > For String, I wonder if someone would argue that it should actually
>> map
>> > to a string-encoded output of a sequence.. "1", "2" ...
>> >
>> > I don't think you can use sequences with String (only numeric values),
>> so
>> > anyone having this expectation would also be unhappy as of today.
>> >
>> > --Gunnar
>> >
>> >
>> > 2015-01-19 15:58 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >
>> > > On 19 January 2015 at 13:33, Emmanuel Bernard <emmanuel at hibernate.org
>> >
>> > > wrote:
>> > > > Hey,
>> > > >
>> > > > I am throwing an idea, let me know what you think.
>> > > > If the return type of the id property of an entity is either String
>> or
>> > > UUID, could we automatically consider one fo the uuid strategy as the
>> one
>> > > matching AUTO?
>> > >
>> > > +1
>> > > That seems spot-on for the UUID type.
>> > > For String, I wonder if someone would argue that it should actually
>> > > map to a string-encoded output of a sequence.. "1", "2" ...
>> > > I'd personally agree that this is horrible and it should default to
>> > > UUID, just wondering.
>> > >
>> > > Would this violate any spec?
>> > >
>> > > >
>> > > > It would be useful for Hibernate OGM but I am also thinking that it
>> > > makes equal sense to Hibernate ORM users.
>> > > >
>> > > > Thoughts? I?m sure there are incompatibilities I have not think of.
>> > > >
>> > > > Emmanuel
>> > > > _______________________________________________
>> > > > 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 Jan 23 08:40:32 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 23 Jan 2015 07:40:32 -0600
Subject: [hibernate-dev] [OGM] Transaction type "RESOURCE_LOCAL",
 still JTA is required
In-Reply-To: <DE5277D7-C0AF-48A4-B60B-BE43B1FE62FF@hibernate.org>
References: <CADGJaX9WiH0mxHf3uTHED_=3dyoDJKF19-goRs5LfunizwSqsA@mail.gmail.com>
	<CAFdSV9u8nHCYF=FBMu5OFWq36utVepqPPkGfruj+h0HCut843g@mail.gmail.com>
	<CADGJaX8wXPF_6Z+RtV3Ew-crnhKAwtQSX7CE1E-cYBxNtU6GiA@mail.gmail.com>
	<DE5277D7-C0AF-48A4-B60B-BE43B1FE62FF@hibernate.org>
Message-ID: <CAFdSV9vbmoHXS_4UapWXYR7KM2GHC=b+BUPNYCc8Y7ktMzhL4w@mail.gmail.com>

Probably in y'alls initiator you will need to make a specific
interpretation of your various settings to determine whether to initiate
the JTA-specific service.  I think that as long as you don't trigger
initialization of the Class, the JVM will not attempt to link in the JTA
classes.

On Wed, Jan 14, 2015 at 3:39 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

>
> > On 14 Jan 2015, at 10:08, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> > 2015-01-13 19:49 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> >
> >> You'd need to not specify the JtaPlatform service stuff.
> >>
> >
> > Yes, but which org.hibernate.Transaction implementation to use? We'd
> need a
> > "fake" implementation which triggers the grid dialect upon
> flush()/commit()
> > invocations.
>
> I think I originally replaced it so that it worked for Infinispan. Which
> mandates a JTA TM all the time (for transactions).
> Looks like it was still working for the other datastores and no one
> bothered to improve a working bit until you discovered the extra dependency
> issue.

From manderse at redhat.com  Fri Jan 23 11:19:49 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 23 Jan 2015 17:19:49 +0100
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9sRVd2sJU2rRt0UEWUfPnQEMdiYxjhrANniRpEF-jfDQg@mail.gmail.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
	<468EF275-F10B-4BB1-AAD2-70D67AEFC0C7@hibernate.org>
	<CAFdSV9u5YXMeDNdrLD++A-i8sY270BVxwiE4FJdm5pULHdOWyQ@mail.gmail.com>
	<CAFdSV9ttiEsjXsDA3X1a0re2Y_GejsKxTdQ+C=ZEQOzaGxd=iw@mail.gmail.com>
	<E1095FA3-D982-4AF4-AF49-3D713D9513B6@hibernate.org>
	<CAFdSV9vAptaR6VySYNA0y5uzsTMiZMgvJaE7FRp6YZdeNk5J1g@mail.gmail.com>
	<CAFdSV9sRVd2sJU2rRt0UEWUfPnQEMdiYxjhrANniRpEF-jfDQg@mail.gmail.com>
Message-ID: <E3BFFD6B-1BEE-45A7-9263-E76ED261A899@redhat.com>

On 23 Jan 2015, at 14:18, Steve Ebersole wrote:

> [1] - I vaguely recall seeing that certain databases allow different 
> length
> constraints for different types of identifiers (table name, versus 
> column
> name, versus constrain name, ...).  Can anyone confirm that?

I remember db2 have this fun.

http://bytes.com/topic/db2/answers/183320-maximum-length-table-names-colums-etc

I believe Oracle has too but couldn't find evidence for it.

/max
http://about.me/maxandersen

From steve at hibernate.org  Fri Jan 23 11:43:10 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 23 Jan 2015 10:43:10 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <E3BFFD6B-1BEE-45A7-9263-E76ED261A899@redhat.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
	<468EF275-F10B-4BB1-AAD2-70D67AEFC0C7@hibernate.org>
	<CAFdSV9u5YXMeDNdrLD++A-i8sY270BVxwiE4FJdm5pULHdOWyQ@mail.gmail.com>
	<CAFdSV9ttiEsjXsDA3X1a0re2Y_GejsKxTdQ+C=ZEQOzaGxd=iw@mail.gmail.com>
	<E1095FA3-D982-4AF4-AF49-3D713D9513B6@hibernate.org>
	<CAFdSV9vAptaR6VySYNA0y5uzsTMiZMgvJaE7FRp6YZdeNk5J1g@mail.gmail.com>
	<CAFdSV9sRVd2sJU2rRt0UEWUfPnQEMdiYxjhrANniRpEF-jfDQg@mail.gmail.com>
	<E3BFFD6B-1BEE-45A7-9263-E76ED261A899@redhat.com>
Message-ID: <CAFdSV9sADREy6ohG9av04CVQsK0SrskmAUq_i0gHUPCOBRu5yA@mail.gmail.com>

Thanks Max for validating I am not going insane... at least in regards to
this :)

On Fri, Jan 23, 2015 at 10:19 AM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

> On 23 Jan 2015, at 14:18, Steve Ebersole wrote:
>
>  [1] - I vaguely recall seeing that certain databases allow different
>> length
>> constraints for different types of identifiers (table name, versus column
>> name, versus constrain name, ...).  Can anyone confirm that?
>>
>
> I remember db2 have this fun.
>
> http://bytes.com/topic/db2/answers/183320-maximum-length-
> table-names-colums-etc
>
> I believe Oracle has too but couldn't find evidence for it.
>
> /max
> http://about.me/maxandersen
>

From sanne at hibernate.org  Sun Jan 25 16:19:22 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 25 Jan 2015 21:19:22 +0000
Subject: [hibernate-dev] [Hibernate Search] Donating some of our source code
	to Infinispan
Message-ID: <CAFm4XO2H5h6bccne=cPzg5U9od3pj7LXV49p-un8oaQ1NCd9Vg@mail.gmail.com>

All,
we've discussed several times the issues we have because of the
circular dependency between Hibernate Search and Infinispan.
Normally the pain point we aim to address with such discussions is the
need to carefully coordinate between releases [of Search and
Infinispan] in our quest for a final stable release, and brings some
release pressure.

More recently it has also become a compatibility problem, as the two
projects target different platforms/environments, and have different
life-cycle expectations - creating more maintenance work such as lots
of back-porting of patches.. distracting from our goals.

We already discussed some solutions, but none too convincing. I have a
new fresh proposal which I feel is more interesting:

# New plan

1) the module "/infinispan" from the Hibernate Search source tree is
moved to the Infinispan project into some "hibernate-search-directory"
Maven module.

2) Hibernate Search drops any dependency to Infinispan

Reminder: this "/infinispan" module we have contains just a couple of
classes, and represents the "DirectoryProvider" implementation which
integrates with the Hibernate Search autodiscovery and creates a
Directory instance (whose implementation always lived in Infinispan).
Most of the code is about applying configuration properties,
integration tests.

It's a very simple plan, but has some valuable consequences:
 - Search can move on without ever needing to wait for Infinispan -
and vice versa.
 - There is no longer a circular dependency
 - Search would be in control of its Lucene dependency, and can
upgrade as needed. We could experiment with different Lucene versions
without necessarily wait for Infinispan to solve compatiblity issues
first - and often more complex as that means then for Infinispan to be
able to guarantee a compatibility with a *range* of Lucene versions,
to include both the target Lucene and the version currently consumed
via Infinispan Query / Hibernate Search Engine.
 - Infinispan can *opt* to stick with an older version of Search - or
update - provided it can satisfy both a) integration with possible
changes to the Search SPI b) an update for possible new requirements
of the new Lucene version (the Lucene Directory might need
compatibility fixes)
 - The dependency structure would better match the one as provided by
our Enterprise Products. For example, it's the JDG distribution - not
Hibernate Search - to provide these integration bits, so it makes more
sense to build the Directory against the specific version of
Infinispan than against the specific version of Search.
 - It will be easier to have new Infinispan code take advantage of
features exposed on the Infinispan Lucene Directory - if all changed
parts are in the same [Infinispan] repository. This is actually being
a problem right now, as it's holding back a POC meant to deliver great
improvements with the Directory implementation.

And not least we'll have faster builds ;-)

# Drawbacks

First one is we'll probably have our users need to change some details
of how they build.
Infinispan might need to fix some SPI related code before being able
to upgrade, but historically our SPI has been extremely stable.
The real problem is that when such a thing happens, after we've
released a version of Search there might be some time before a
compatible version of Infinispan is made available as well.

In practice this means the gap of time in which we have to catch up on
API changes is "exposed" to end users wanting to use our latest and
possibly blocked - but while they would then see the tip of the
iceberg of our integration, I believe it would still take the same
amount of waiting time in terms of calendar dates in which the working
duo is available to them - as with the current model in such a
situation we need to wait for the same Infinispan release to happen
before we can release ours.
So: same time, but we'd have a leaner process, and possibly quicker
releases for all users not interested in that - or just benefits in
all those scenarios in which we don't break APIs which is very common.
I've not identified other problems, so my opinion is that these are
well worth the benefits.

# Consequences for our users

Not much. Even today we expect our users to depend on several jar
files provided by the Infinispan team; this would be just one more.
Opens some questions though:

 A) Should the Maven group id be changed? I'd expect it to be
transferred to "org.infinispan" group at least, and probably need a
better artifact id too.

 B) License. Our code is LGPL, most of Infinispan is ASL - but not all
of it. So I expect it would be possible to keep the existing license
at least for now, and defer eventual license changes as a separate
step (if people feel need for any change at all).

 C) Documentation. Besides the needed updates in Maven coordinates /
download sources, I don't expect much of a difference: we'd still
explain how to set this integration up.

 D) Distribution. Today we distribute this module, and its
dependencies, in our release bundles. Which implies we distribute a
copy of various Infinispan jars.
I think we should drop these from our distribution - even though it
might seem counter-intuitive:
while it might seem convenient to have these included, the whole point
of the change would be that there would be more flexibility in which
versions of Infinispan would work with Search. And actually the
integration tests and this specific knowledge would be responsibility
of Infinispan.

Am I failing to see a more critical issue?
How would you all feel about our code being transferred to the
different project?

Sanne

From sanne at hibernate.org  Sun Jan 25 19:40:12 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 26 Jan 2015 00:40:12 +0000
Subject: [hibernate-dev] Search: upgrade to Apache Lucene 5
Message-ID: <CAFm4XO32pwfjZtM53Lv+o5QnHoUHhy22h_YzmiE5U2p+Ho72vA@mail.gmail.com>

Apache Lucene 5 is in candidate release now, and might be released
before the end of the month.
I've been testing it this weekend... and it's still Java7 compatible!

Sorry I got confused when I previously mentioned it would require
Java8: they did indeed switch "trunk" branch to require Java8, but
"trunk" is meant to become 6.0, while branch "5.0" was already
branched before that change in requirements.

So we could propose a timely update to Lucene 5 without necessarily
waiting for it to be a good time for Hibernate Search to upgrade to
Java8 / major release.

The initial "damage" is accounted as about 600 compile errors; I could
resolve approx 230 already as they were trivial.
The remaining ones require some more care & investigation, but seems
like we could get it done in 1-2 weeks, if we were to put our focus on
this...  it definitely looks better than the migration 3 -> 4.

Changes would again (obviously) affect users wherever they use
"native" Lucene APIs, but it seems like that this time we could do a
zero-changes in our APIs.. so we could do this in a minor release
without violating our "backwards compatibility policy" but I guess
that's arguable, as while our APIs would be "drop-in" compatible, the
user application wouldn't work with all the changes in Lucene code.
We would need to rewrite areas relating to:
 - Faceting
 - Filters and filter stacking
 - Custom Collectors (i.e. most code of Spatial)
 - FieldCache
 - Some IndexWriter code related to I/O errorhandling locking
 - Analyzer

A more extensive preview of changes is documented here:
http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC1-rev1654615/lucene/changes/Changes.html#v5.0.0.documentation

We might want to start working soon on a new major already?
Whatever we do, we can't allow our users needing to wait as long as we
did for 4, especially since the upgrade is not as nasty.

Sanne

From hardy at hibernate.org  Mon Jan 26 04:45:13 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 26 Jan 2015 10:45:13 +0100
Subject: [hibernate-dev] [Hibernate Search] Donating some of our source
 code to Infinispan
In-Reply-To: <CAFm4XO2H5h6bccne=cPzg5U9od3pj7LXV49p-un8oaQ1NCd9Vg@mail.gmail.com>
References: <CAFm4XO2H5h6bccne=cPzg5U9od3pj7LXV49p-un8oaQ1NCd9Vg@mail.gmail.com>
Message-ID: <20150126094513.GA2532@Sarmakand-4.local>

Hi,

Sounds like a reasonable plan. I am just wondering what happened with the idea
of creating a standalone repository for the Infinispan Lucene Directory
(I guess that implies moving things from Inifinispan and Search into a new repo)?
I think this was our most favoured plan until now. IMO this has even more 
flexibility as the move to Infinispan. 

Also it should be in the interest of Infinispan as well to split things out,
given how many modules they already have. I think smaller independent "projects"
is more favourable than this huge monolithic multi-module setups. It also
comes with additional flexibility when it comes to releasing.

In case we co ahead with moving the code to Infinispan:

>  A) Should the Maven group id be changed? I'd expect it to be
> transferred to "org.infinispan" group at least, and probably need a
> better artifact id too.

+1 At least group id needs top change. 

>  B) License. Our code is LGPL, most of Infinispan is ASL - but not all
> of it. So I expect it would be possible to keep the existing license
> at least for now, and defer eventual license changes as a separate
> step (if people feel need for any change at all).

Would it not be easier to change to ASL?

>  C) Documentation. Besides the needed updates in Maven coordinates /
> download sources, I don't expect much of a difference: we'd still
> explain how to set this integration up.

+1

> I think we should drop these from our distribution 

+1

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150126/1333c39c/attachment.bin 

From gunnar at hibernate.org  Mon Jan 26 05:00:19 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 26 Jan 2015 11:00:19 +0100
Subject: [hibernate-dev] [Hibernate Search] Donating some of our source
 code to Infinispan
In-Reply-To: <CAFm4XO2H5h6bccne=cPzg5U9od3pj7LXV49p-un8oaQ1NCd9Vg@mail.gmail.com>
References: <CAFm4XO2H5h6bccne=cPzg5U9od3pj7LXV49p-un8oaQ1NCd9Vg@mail.gmail.com>
Message-ID: <CADGJaX8JLy8u0UVPJgoyOm-dcUyDS0KJMfMMv9pSEzYv-0GS_Q@mail.gmail.com>

Hi,

+1 for addressing this, the cyclic dependency has been a pain point for a
long time.

Moving the directory provider code out of HS is the right thing to do. But
moving it into ISPN creates the release dependency you describe: After a HS
release there will be a time where people potentially cannot use it with
the ISPN directory provider until there has been a new ISPN release which
adapts to the HS (and, transitively, Lucene) changes. So it kind of ties
the ISPN release cycle to HS, although ISPN itself might be fine using the
previous HSEARCH version for its own querying purposes.

To me the problem appears to be that ISPN a) uses HS (for querying) but b)
also extends it (as index storage) at the same time. For a) ISPN could live
with older HS versions AFAIU, whereas for b) following HS releases closely
is needed in order to keep that integration usable as HS (and Lucene)
advances.

So alternatively the ISPN Lucene directory as well as the HS directory (and
related integration tests) could be moved into a separate repository, with
its own release lifecycle. Then when a new HS release comes out, only that
separate integration project needs to be adapted and released (which of
course could be prepared during Alpha/Beta phases, so it could be released
on the same day as HS), whereas no new version of ISPN itself would be
needed. Also the dependency cycle would be nicely untangled:

* ISPN depends on HS
* "Lucene directory + provider" depends on HS and ISPN
* Users wishing to store their indexes in ISPN would add the "Lucene
directory + provider" dependency

One issue I can see though is that the "Lucene directory + provider"
component could not be easily part of a ISPN/JDG distribution as the
dependency would be the other way around. Not sure whether that's actually
a problem.

> - It will be easier to have new Infinispan code take advantage of
> features exposed on the Infinispan Lucene Directory

This makes me curious; There is ISPN code which directly depends on that
directory implementation? What is this about, I assumed no such dependency
to exist. If so, having the directory and provider in the ISPN repo itself
indeed seems the only way, with the consequence of ISPN having to follow HS
releases in a timely manner.

--Gunnar


2015-01-25 22:19 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> All,
> we've discussed several times the issues we have because of the
> circular dependency between Hibernate Search and Infinispan.
> Normally the pain point we aim to address with such discussions is the
> need to carefully coordinate between releases [of Search and
> Infinispan] in our quest for a final stable release, and brings some
> release pressure.
>
> More recently it has also become a compatibility problem, as the two
> projects target different platforms/environments, and have different
> life-cycle expectations - creating more maintenance work such as lots
> of back-porting of patches.. distracting from our goals.
>
> We already discussed some solutions, but none too convincing. I have a
> new fresh proposal which I feel is more interesting:
>
> # New plan
>
> 1) the module "/infinispan" from the Hibernate Search source tree is
> moved to the Infinispan project into some "hibernate-search-directory"
> Maven module.
>
> 2) Hibernate Search drops any dependency to Infinispan
>
> Reminder: this "/infinispan" module we have contains just a couple of
> classes, and represents the "DirectoryProvider" implementation which
> integrates with the Hibernate Search autodiscovery and creates a
> Directory instance (whose implementation always lived in Infinispan).
> Most of the code is about applying configuration properties,
> integration tests.
>
> It's a very simple plan, but has some valuable consequences:
>  - Search can move on without ever needing to wait for Infinispan -
> and vice versa.
>  - There is no longer a circular dependency
>  - Search would be in control of its Lucene dependency, and can
> upgrade as needed. We could experiment with different Lucene versions
> without necessarily wait for Infinispan to solve compatiblity issues
> first - and often more complex as that means then for Infinispan to be
> able to guarantee a compatibility with a *range* of Lucene versions,
> to include both the target Lucene and the version currently consumed
> via Infinispan Query / Hibernate Search Engine.
>  - Infinispan can *opt* to stick with an older version of Search - or
> update - provided it can satisfy both a) integration with possible
> changes to the Search SPI b) an update for possible new requirements
> of the new Lucene version (the Lucene Directory might need
> compatibility fixes)
>  - The dependency structure would better match the one as provided by
> our Enterprise Products. For example, it's the JDG distribution - not
> Hibernate Search - to provide these integration bits, so it makes more
> sense to build the Directory against the specific version of
> Infinispan than against the specific version of Search.
>  - It will be easier to have new Infinispan code take advantage of
> features exposed on the Infinispan Lucene Directory - if all changed
> parts are in the same [Infinispan] repository. This is actually being
> a problem right now, as it's holding back a POC meant to deliver great
> improvements with the Directory implementation.
>
> And not least we'll have faster builds ;-)
>
> # Drawbacks
>
> First one is we'll probably have our users need to change some details
> of how they build.
> Infinispan might need to fix some SPI related code before being able
> to upgrade, but historically our SPI has been extremely stable.
> The real problem is that when such a thing happens, after we've
> released a version of Search there might be some time before a
> compatible version of Infinispan is made available as well.
>
> In practice this means the gap of time in which we have to catch up on
> API changes is "exposed" to end users wanting to use our latest and
> possibly blocked - but while they would then see the tip of the
> iceberg of our integration, I believe it would still take the same
> amount of waiting time in terms of calendar dates in which the working
> duo is available to them - as with the current model in such a
> situation we need to wait for the same Infinispan release to happen
> before we can release ours.
> So: same time, but we'd have a leaner process, and possibly quicker
> releases for all users not interested in that - or just benefits in
> all those scenarios in which we don't break APIs which is very common.
> I've not identified other problems, so my opinion is that these are
> well worth the benefits.
>
> # Consequences for our users
>
> Not much. Even today we expect our users to depend on several jar
> files provided by the Infinispan team; this would be just one more.
> Opens some questions though:
>
>  A) Should the Maven group id be changed? I'd expect it to be
> transferred to "org.infinispan" group at least, and probably need a
> better artifact id too.
>
>  B) License. Our code is LGPL, most of Infinispan is ASL - but not all
> of it. So I expect it would be possible to keep the existing license
> at least for now, and defer eventual license changes as a separate
> step (if people feel need for any change at all).
>
>  C) Documentation. Besides the needed updates in Maven coordinates /
> download sources, I don't expect much of a difference: we'd still
> explain how to set this integration up.
>
>  D) Distribution. Today we distribute this module, and its
> dependencies, in our release bundles. Which implies we distribute a
> copy of various Infinispan jars.
> I think we should drop these from our distribution - even though it
> might seem counter-intuitive:
> while it might seem convenient to have these included, the whole point
> of the change would be that there would be more flexibility in which
> versions of Infinispan would work with Search. And actually the
> integration tests and this specific knowledge would be responsibility
> of Infinispan.
>
> Am I failing to see a more critical issue?
> How would you all feel about our code being transferred to the
> different project?
>
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Mon Jan 26 05:20:47 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 26 Jan 2015 10:20:47 +0000
Subject: [hibernate-dev] [Hibernate Search] Donating some of our source
 code to Infinispan
In-Reply-To: <20150126094513.GA2532@Sarmakand-4.local>
References: <CAFm4XO2H5h6bccne=cPzg5U9od3pj7LXV49p-un8oaQ1NCd9Vg@mail.gmail.com>
	<20150126094513.GA2532@Sarmakand-4.local>
Message-ID: <CAFm4XO3_0XiujyLp6=dXYmpXdwMQDF4LrtBq5=aRLm+ecXLFRw@mail.gmail.com>

On 26 January 2015 at 09:45, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
> Sounds like a reasonable plan. I am just wondering what happened with the idea
> of creating a standalone repository for the Infinispan Lucene Directory
> (I guess that implies moving things from Inifinispan and Search into a new repo)?
> I think this was our most favoured plan until now. IMO this has even more
> flexibility as the move to Infinispan.

We had identified several issues with that. I don't remember them all,
but was discussed on both mailing lists, some problems as I remember
them include:
 - it doesn't relax coupling but would require a specific version of
Infinispan and a specific of version Search
 - compatibility would break for ANY of: Lucene API change, Search API
change, Infinispan API change
 - you'd need a release of such a module for each combination of
versions as it's likely to break often
 - such a module's versioning scheme would be something like "module
for Search 5 & Infinispan 6 review 0.1" because of the coupling

>
> Also it should be in the interest of Infinispan as well to split things out,
> given how many modules they already have. I think smaller independent "projects"
> is more favourable than this huge monolithic multi-module setups. It also
> comes with additional flexibility when it comes to releasing.

Maybe, I'm sceptical but not ruling that out. What matters for us is
to hook up that module to their release process and versioning scheme
rather than ours; how Infinispan decides to organize their sources is
an evolution they can make on their own if need arises.


> In case we co ahead with moving the code to Infinispan:
>
>>  A) Should the Maven group id be changed? I'd expect it to be
>> transferred to "org.infinispan" group at least, and probably need a
>> better artifact id too.
>
> +1 At least group id needs top change.
>
>>  B) License. Our code is LGPL, most of Infinispan is ASL - but not all
>> of it. So I expect it would be possible to keep the existing license
>> at least for now, and defer eventual license changes as a separate
>> step (if people feel need for any change at all).
>
> Would it not be easier to change to ASL?

"Involve Legal" ~ "easier" ??
Maybe, but I'm suggesting I hope that any such process would be
asynchronous compared to the practicalities for us of moving the code.

>>  C) Documentation. Besides the needed updates in Maven coordinates /
>> download sources, I don't expect much of a difference: we'd still
>> explain how to set this integration up.
>
> +1
>
>> I think we should drop these from our distribution
>
> +1
>
> --Hardy

Thanks!
Sanne

From sanne at hibernate.org  Mon Jan 26 05:26:56 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 26 Jan 2015 10:26:56 +0000
Subject: [hibernate-dev] [Hibernate Search] Donating some of our source
 code to Infinispan
In-Reply-To: <54C60E4C.2020102@infinispan.org>
References: <CAFm4XO2H5h6bccne=cPzg5U9od3pj7LXV49p-un8oaQ1NCd9Vg@mail.gmail.com>
	<20150126094513.GA2532@Sarmakand-4.local>
	<54C60E4C.2020102@infinispan.org>
Message-ID: <CAFm4XO0amoDD-RQMqyR2DPoS8igEtwYQRcU3G7d01HQsHLeN7w@mail.gmail.com>

On 26 January 2015 at 09:52, Tristan Tarrant <tristan at infinispan.org> wrote:
> On 26/01/2015 10:45, Hardy Ferentschik wrote:
>>
>>
>>   A) Should the Maven group id be changed? I'd expect it to be
>> transferred to "org.infinispan" group at least, and probably need a
>> better artifact id too.
>> +1 At least group id needs top change.
>
> Yes.
>>
>>
>>>   B) License. Our code is LGPL, most of Infinispan is ASL - but not all
>>> of it. So I expect it would be possible to keep the existing license
>>> at least for now, and defer eventual license changes as a separate
>>> step (if people feel need for any change at all).
>>
>> Would it not be easier to change to ASL?
>
> All of the embeddable Infinispan code is ASL. The exception is for the
> server itself which is LGPL (being based on WildFly which is LGPL itself).
> So I'd rather not confuse the issues any more.
>
> Tristan

As long as we're clear that wherever you expose/include Search and
parser code it's LGPL ;-)
And JPACacheStore, and ..
So I don't think it's a very simple story to explain to users today,
one more module wouldn't be a significant change, especially since
it's not public API! And remember you're already using the same code
today, with the same strings attached. If any this should make it
easier to change license.

I'm fine to change this to ASL, but I'd prefer we could move forward
with it without needing to involve legal matters as a blocking
process.
As mentioned above, this would make it far easier to develop some
improvements which would highly benefit both projects in the short
time.

Sanne

From sanne at hibernate.org  Mon Jan 26 05:53:53 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 26 Jan 2015 10:53:53 +0000
Subject: [hibernate-dev] [Hibernate Search] Donating some of our source
 code to Infinispan
In-Reply-To: <CADGJaX8JLy8u0UVPJgoyOm-dcUyDS0KJMfMMv9pSEzYv-0GS_Q@mail.gmail.com>
References: <CAFm4XO2H5h6bccne=cPzg5U9od3pj7LXV49p-un8oaQ1NCd9Vg@mail.gmail.com>
	<CADGJaX8JLy8u0UVPJgoyOm-dcUyDS0KJMfMMv9pSEzYv-0GS_Q@mail.gmail.com>
Message-ID: <CAFm4XO3Hu0yY=ZSihaCai5J7nEYv=nxrbGrjtsQj-64d_BnohA@mail.gmail.com>

On 26 January 2015 at 10:00, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> +1 for addressing this, the cyclic dependency has been a pain point for a
> long time.
>
> Moving the directory provider code out of HS is the right thing to do. But
> moving it into ISPN creates the release dependency you describe: After a HS
> release there will be a time where people potentially cannot use it with the
> ISPN directory provider until there has been a new ISPN release which adapts
> to the HS (and, transitively, Lucene) changes. So it kind of ties the ISPN
> release cycle to HS, although ISPN itself might be fine using the previousi
> HSEARCH version for its own querying purposes.

No, it "unties". Currently Infinispan is strictly required to follow
up with a Search upgrade on each minor change, and vice-versa.
Having flexibility such as the option to not upgrade is a huge benefit
we don't have today.
Let's assume for simplicity that, while planning a component upgrade:
 - upgrading the Directory (in Infinispan) takes 5 days of work
 - upgrading the Infinispan Query to latest Search APIs takes 5 days of work
 - upgrading the Search engine to latest Lucene takes 5 days of work
== total is 15 days of work

It does't matter how you shuffle these tasks around, it's still 15
days of work to update all the code. Currently - in a perfect world in
which each project would release exactly whenever I need it (like
never has regressions or trouble releasing), and in which a release
does take ZERO seconds (as you'd need many releases to get there)
performing a release upgrading these would take you 15 days.
So that's 15 days a user would need to wait to get benefit of any new
Lucene feature, or 15 days before he can download our stuff and start
evaluating an upgrade.

In the new model, he has the choice to:
 - download the Search release after 5 days, as he doesn't need/use Infinispan
 - download the same complete integration in 15 days

So: really the user isn't waiting more. Even in the worst case, our
"time to market" would be faster because of the missing intermediate
releases as in reality it doesn't take us zero seconds to publish one.

>
> To me the problem appears to be that ISPN a) uses HS (for querying) but b)
> also extends it (as index storage) at the same time. For a) ISPN could live
> with older HS versions AFAIU, whereas for b) following HS releases closely
> is needed in order to keep that integration usable as HS (and Lucene)
> advances.

Right

> So alternatively the ISPN Lucene directory as well as the HS directory (and
> related integration tests) could be moved into a separate repository, with
> its own release lifecycle. Then when a new HS release comes out, only that
> separate integration project needs to be adapted and released (which of
> course could be prepared during Alpha/Beta phases, so it could be released
> on the same day as HS), whereas no new version of ISPN itself would be
> needed. Also the dependency cycle would be nicely untangled:

We already discussed this. It doesn't work as nicely as the new module
would have strict coupling to 2 different project's versions.

> * ISPN depends on HS
> * "Lucene directory + provider" depends on HS and ISPN
> * Users wishing to store their indexes in ISPN would add the "Lucene
> directory + provider" dependency
>
> One issue I can see though is that the "Lucene directory + provider"
> component could not be easily part of a ISPN/JDG distribution as the
> dependency would be the other way around. Not sure whether that's actually a
> problem.

That's a serious problem, and not open to debate: we need to have
these integrations distributed by the Infinispan download.
Which is why I think it's essential to follow the Infinispan versioning scheme.

>
>> - It will be easier to have new Infinispan code take advantage of
>> features exposed on the Infinispan Lucene Directory
>
> This makes me curious; There is ISPN code which directly depends on that
> directory implementation? What is this about, I assumed no such dependency
> to exist. If so, having the directory and provider in the ISPN repo itself
> indeed seems the only way, with the consequence of ISPN having to follow HS
> releases in a timely manner.

We recently had several improvements applied to the Infinispan
Directory implementation, which then needed a one-liner change in the
Search module to "active" such a feature or pass-on a configuration,
essentially translating from the properties in Search to the DSL of
Infinispan.
Each of these had to be backported, to allow an older version of
Search to be able to be combined with a newer version of Infinispan
without silently deactivating the feature - which is ultimately an
Infinispan feature.
In some cases Gustavo had to resort on reflection to invoke the right
methods, as we're not upgrading Infinispan for branches 4.4 and 4.5 of
Search, so some of these methods which need to be invoked are not
existing, and not testable.

An example of what this is leading to:
https://github.com/hibernate/hibernate-search/blob/4.5/infinispan/src/main/java/org/hibernate/search/infinispan/impl/InfinispanDirectoryProvider.java#L139

It turns out that's not an isolated case, I'm now tinkering with some
more awesome possibilities, but having to adjust that module is making
it more convenient to use my own copy in Infinispan rather than reuse
it. Ultimately this all just doesn't make much sense, ans is resulting
in missing improvements in both projects. For example, what I'm
evolving in Infinispan isn't anymore Search compatible, while I'd wish
both could benefit from it.

-- Sanne

>
> --Gunnar
>
>
> 2015-01-25 22:19 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> All,
>> we've discussed several times the issues we have because of the
>> circular dependency between Hibernate Search and Infinispan.
>> Normally the pain point we aim to address with such discussions is the
>> need to carefully coordinate between releases [of Search and
>> Infinispan] in our quest for a final stable release, and brings some
>> release pressure.
>>
>> More recently it has also become a compatibility problem, as the two
>> projects target different platforms/environments, and have different
>> life-cycle expectations - creating more maintenance work such as lots
>> of back-porting of patches.. distracting from our goals.
>>
>> We already discussed some solutions, but none too convincing. I have a
>> new fresh proposal which I feel is more interesting:
>>
>> # New plan
>>
>> 1) the module "/infinispan" from the Hibernate Search source tree is
>> moved to the Infinispan project into some "hibernate-search-directory"
>> Maven module.
>>
>> 2) Hibernate Search drops any dependency to Infinispan
>>
>> Reminder: this "/infinispan" module we have contains just a couple of
>> classes, and represents the "DirectoryProvider" implementation which
>> integrates with the Hibernate Search autodiscovery and creates a
>> Directory instance (whose implementation always lived in Infinispan).
>> Most of the code is about applying configuration properties,
>> integration tests.
>>
>> It's a very simple plan, but has some valuable consequences:
>>  - Search can move on without ever needing to wait for Infinispan -
>> and vice versa.
>>  - There is no longer a circular dependency
>>  - Search would be in control of its Lucene dependency, and can
>> upgrade as needed. We could experiment with different Lucene versions
>> without necessarily wait for Infinispan to solve compatiblity issues
>> first - and often more complex as that means then for Infinispan to be
>> able to guarantee a compatibility with a *range* of Lucene versions,
>> to include both the target Lucene and the version currently consumed
>> via Infinispan Query / Hibernate Search Engine.
>>  - Infinispan can *opt* to stick with an older version of Search - or
>> update - provided it can satisfy both a) integration with possible
>> changes to the Search SPI b) an update for possible new requirements
>> of the new Lucene version (the Lucene Directory might need
>> compatibility fixes)
>>  - The dependency structure would better match the one as provided by
>> our Enterprise Products. For example, it's the JDG distribution - not
>> Hibernate Search - to provide these integration bits, so it makes more
>> sense to build the Directory against the specific version of
>> Infinispan than against the specific version of Search.
>>  - It will be easier to have new Infinispan code take advantage of
>> features exposed on the Infinispan Lucene Directory - if all changed
>> parts are in the same [Infinispan] repository. This is actually being
>> a problem right now, as it's holding back a POC meant to deliver great
>> improvements with the Directory implementation.
>>
>> And not least we'll have faster builds ;-)
>>
>> # Drawbacks
>>
>> First one is we'll probably have our users need to change some details
>> of how they build.
>> Infinispan might need to fix some SPI related code before being able
>> to upgrade, but historically our SPI has been extremely stable.
>> The real problem is that when such a thing happens, after we've
>> released a version of Search there might be some time before a
>> compatible version of Infinispan is made available as well.
>>
>> In practice this means the gap of time in which we have to catch up on
>> API changes is "exposed" to end users wanting to use our latest and
>> possibly blocked - but while they would then see the tip of the
>> iceberg of our integration, I believe it would still take the same
>> amount of waiting time in terms of calendar dates in which the working
>> duo is available to them - as with the current model in such a
>> situation we need to wait for the same Infinispan release to happen
>> before we can release ours.
>> So: same time, but we'd have a leaner process, and possibly quicker
>> releases for all users not interested in that - or just benefits in
>> all those scenarios in which we don't break APIs which is very common.
>> I've not identified other problems, so my opinion is that these are
>> well worth the benefits.
>>
>> # Consequences for our users
>>
>> Not much. Even today we expect our users to depend on several jar
>> files provided by the Infinispan team; this would be just one more.
>> Opens some questions though:
>>
>>  A) Should the Maven group id be changed? I'd expect it to be
>> transferred to "org.infinispan" group at least, and probably need a
>> better artifact id too.
>>
>>  B) License. Our code is LGPL, most of Infinispan is ASL - but not all
>> of it. So I expect it would be possible to keep the existing license
>> at least for now, and defer eventual license changes as a separate
>> step (if people feel need for any change at all).
>>
>>  C) Documentation. Besides the needed updates in Maven coordinates /
>> download sources, I don't expect much of a difference: we'd still
>> explain how to set this integration up.
>>
>>  D) Distribution. Today we distribute this module, and its
>> dependencies, in our release bundles. Which implies we distribute a
>> copy of various Infinispan jars.
>> I think we should drop these from our distribution - even though it
>> might seem counter-intuitive:
>> while it might seem convenient to have these included, the whole point
>> of the change would be that there would be more flexibility in which
>> versions of Infinispan would work with Search. And actually the
>> integration tests and this specific knowledge would be responsibility
>> of Infinispan.
>>
>> Am I failing to see a more critical issue?
>> How would you all feel about our code being transferred to the
>> different project?
>>
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From gunnar at hibernate.org  Mon Jan 26 06:42:29 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 26 Jan 2015 12:42:29 +0100
Subject: [hibernate-dev] [Hibernate Search] Donating some of our source
 code to Infinispan
In-Reply-To: <CAFm4XO3Hu0yY=ZSihaCai5J7nEYv=nxrbGrjtsQj-64d_BnohA@mail.gmail.com>
References: <CAFm4XO2H5h6bccne=cPzg5U9od3pj7LXV49p-un8oaQ1NCd9Vg@mail.gmail.com>
	<CADGJaX8JLy8u0UVPJgoyOm-dcUyDS0KJMfMMv9pSEzYv-0GS_Q@mail.gmail.com>
	<CAFm4XO3Hu0yY=ZSihaCai5J7nEYv=nxrbGrjtsQj-64d_BnohA@mail.gmail.com>
Message-ID: <CADGJaX-4kCdW0=UOjf8FyBkehFzyqfNe44ctVhCjK3VG1iVAdg@mail.gmail.com>

2015-01-26 11:53 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> On 26 January 2015 at 10:00, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Hi,
> >
> > +1 for addressing this, the cyclic dependency has been a pain point for a
> > long time.
> >
> > Moving the directory provider code out of HS is the right thing to do.
> But
> > moving it into ISPN creates the release dependency you describe: After a
> HS
> > release there will be a time where people potentially cannot use it with
> the
> > ISPN directory provider until there has been a new ISPN release which
> adapts
> > to the HS (and, transitively, Lucene) changes. So it kind of ties the
> ISPN
> > release cycle to HS, although ISPN itself might be fine using the
> previousi
> > HSEARCH version for its own querying purposes.
>
> No, it "unties". Currently Infinispan is strictly required to follow
> up with a Search upgrade on each minor change, and vice-versa.
> Having flexibility such as the option to not upgrade is a huge benefit
> we don't have today.
>

But how realistic is the option not to upgrade?

It means a new HS (which e.g. upgrades Lucene) cannot be used with the ISPN
directory unless there has been a new release of ISPN altogether. So there
seems to be quite a high motivation to do an ISPN release right after HS
has been released. But if that's alright for ISPN, then go for it.

To me it'd appear beneficial though to narrow down the pieces which would
have to be released in such a timely manner to the minimum. A separate
component may easier and quicker be updated and released than the entire
project which e.g. may contain other work in progress which may not be in
releasable state at the point of time where HS is out and just would need a
one-line fix in the directory implementation.


> Let's assume for simplicity that, while planning a component upgrade:
>  - upgrading the Directory (in Infinispan) takes 5 days of work
>  - upgrading the Infinispan Query to latest Search APIs takes 5 days of
> work
>  - upgrading the Search engine to latest Lucene takes 5 days of work
> == total is 15 days of work
>
> It does't matter how you shuffle these tasks around, it's still 15
> days of work to update all the code. Currently - in a perfect world in
> which each project would release exactly whenever I need it (like
> never has regressions or trouble releasing), and in which a release
> does take ZERO seconds (as you'd need many releases to get there)
> performing a release upgrading these would take you 15 days.
> So that's 15 days a user would need to wait to get benefit of any new
> Lucene feature, or 15 days before he can download our stuff and start
> evaluating an upgrade.
>
> In the new model, he has the choice to:
>  - download the Search release after 5 days, as he doesn't need/use
> Infinispan
>  - download the same complete integration in 15 days
>
> So: really the user isn't waiting more. Even in the worst case, our
> "time to market" would be faster because of the missing intermediate
> releases as in reality it doesn't take us zero seconds to publish one.


Sure, I'm not arguing about the requiring working days. Only that it may be
easier to release a separate component after a HS release than the entire
ISPN which may not be in a good position to do the release e.g. to other
ongoing changes.

>
> > To me the problem appears to be that ISPN a) uses HS (for querying) but
> b)
> > also extends it (as index storage) at the same time. For a) ISPN could
> live
> > with older HS versions AFAIU, whereas for b) following HS releases
> closely
> > is needed in order to keep that integration usable as HS (and Lucene)
> > advances.
>
> Right
>
> > So alternatively the ISPN Lucene directory as well as the HS directory
> (and
> > related integration tests) could be moved into a separate repository,
> with
> > its own release lifecycle. Then when a new HS release comes out, only
> that
> > separate integration project needs to be adapted and released (which of
> > course could be prepared during Alpha/Beta phases, so it could be
> released
> > on the same day as HS), whereas no new version of ISPN itself would be
> > needed. Also the dependency cycle would be nicely untangled:
>
> We already discussed this. It doesn't work as nicely as the new module
> would have strict coupling to 2 different project's versions.
>

Yes, that may be a challenge. How big it is depends on the stability of the
used APIs/SPIs. I'd hope the integration could work e.g. compatibly across
the ISPNs of one major release family (say 7.x)?


>
> > * ISPN depends on HS
> > * "Lucene directory + provider" depends on HS and ISPN
> > * Users wishing to store their indexes in ISPN would add the "Lucene
> > directory + provider" dependency
> >
> > One issue I can see though is that the "Lucene directory + provider"
> > component could not be easily part of a ISPN/JDG distribution as the
> > dependency would be the other way around. Not sure whether that's
> actually a
> > problem.
>
> That's a serious problem, and not open to debate: we need to have
> these integrations distributed by the Infinispan download.
>

Out of interest, why is that?

As a HS user working with the ISPN directory, I'd find it appealing if
updating HS would only require me to get an update to such integration
module rather than updating the entire ISPN as well (maybe only the
integration bits within ISPN have actually changed, but I couldn't easily
really know). Less moving pieces.

Btw. a combined download still could assembled btw., admittedly more
difficult though.

Anyways, just my 2ct. Both approaches are better than what we have now.

--Gunnar



> Which is why I think it's essential to follow the Infinispan versioning
> scheme.
>
> >
> >> - It will be easier to have new Infinispan code take advantage of
> >> features exposed on the Infinispan Lucene Directory
> >
> > This makes me curious; There is ISPN code which directly depends on that
> > directory implementation? What is this about, I assumed no such
> dependency
> > to exist. If so, having the directory and provider in the ISPN repo
> itself
> > indeed seems the only way, with the consequence of ISPN having to follow
> HS
> > releases in a timely manner.
>
> We recently had several improvements applied to the Infinispan
> Directory implementation, which then needed a one-liner change in the
> Search module to "active" such a feature or pass-on a configuration,
> essentially translating from the properties in Search to the DSL of
> Infinispan.
> Each of these had to be backported, to allow an older version of
> Search to be able to be combined with a newer version of Infinispan
> without silently deactivating the feature - which is ultimately an
> Infinispan feature.
> In some cases Gustavo had to resort on reflection to invoke the right
> methods, as we're not upgrading Infinispan for branches 4.4 and 4.5 of
> Search, so some of these methods which need to be invoked are not
> existing, and not testable.
>
> An example of what this is leading to:
>
> https://github.com/hibernate/hibernate-search/blob/4.5/infinispan/src/main/java/org/hibernate/search/infinispan/impl/InfinispanDirectoryProvider.java#L139
>
> It turns out that's not an isolated case, I'm now tinkering with some
> more awesome possibilities, but having to adjust that module is making
> it more convenient to use my own copy in Infinispan rather than reuse
> it. Ultimately this all just doesn't make much sense, ans is resulting
> in missing improvements in both projects. For example, what I'm
> evolving in Infinispan isn't anymore Search compatible, while I'd wish
> both could benefit from it.
>
> -- Sanne
>
> >
> > --Gunnar
> >
> >
> > 2015-01-25 22:19 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> All,
> >> we've discussed several times the issues we have because of the
> >> circular dependency between Hibernate Search and Infinispan.
> >> Normally the pain point we aim to address with such discussions is the
> >> need to carefully coordinate between releases [of Search and
> >> Infinispan] in our quest for a final stable release, and brings some
> >> release pressure.
> >>
> >> More recently it has also become a compatibility problem, as the two
> >> projects target different platforms/environments, and have different
> >> life-cycle expectations - creating more maintenance work such as lots
> >> of back-porting of patches.. distracting from our goals.
> >>
> >> We already discussed some solutions, but none too convincing. I have a
> >> new fresh proposal which I feel is more interesting:
> >>
> >> # New plan
> >>
> >> 1) the module "/infinispan" from the Hibernate Search source tree is
> >> moved to the Infinispan project into some "hibernate-search-directory"
> >> Maven module.
> >>
> >> 2) Hibernate Search drops any dependency to Infinispan
> >>
> >> Reminder: this "/infinispan" module we have contains just a couple of
> >> classes, and represents the "DirectoryProvider" implementation which
> >> integrates with the Hibernate Search autodiscovery and creates a
> >> Directory instance (whose implementation always lived in Infinispan).
> >> Most of the code is about applying configuration properties,
> >> integration tests.
> >>
> >> It's a very simple plan, but has some valuable consequences:
> >>  - Search can move on without ever needing to wait for Infinispan -
> >> and vice versa.
> >>  - There is no longer a circular dependency
> >>  - Search would be in control of its Lucene dependency, and can
> >> upgrade as needed. We could experiment with different Lucene versions
> >> without necessarily wait for Infinispan to solve compatiblity issues
> >> first - and often more complex as that means then for Infinispan to be
> >> able to guarantee a compatibility with a *range* of Lucene versions,
> >> to include both the target Lucene and the version currently consumed
> >> via Infinispan Query / Hibernate Search Engine.
> >>  - Infinispan can *opt* to stick with an older version of Search - or
> >> update - provided it can satisfy both a) integration with possible
> >> changes to the Search SPI b) an update for possible new requirements
> >> of the new Lucene version (the Lucene Directory might need
> >> compatibility fixes)
> >>  - The dependency structure would better match the one as provided by
> >> our Enterprise Products. For example, it's the JDG distribution - not
> >> Hibernate Search - to provide these integration bits, so it makes more
> >> sense to build the Directory against the specific version of
> >> Infinispan than against the specific version of Search.
> >>  - It will be easier to have new Infinispan code take advantage of
> >> features exposed on the Infinispan Lucene Directory - if all changed
> >> parts are in the same [Infinispan] repository. This is actually being
> >> a problem right now, as it's holding back a POC meant to deliver great
> >> improvements with the Directory implementation.
> >>
> >> And not least we'll have faster builds ;-)
> >>
> >> # Drawbacks
> >>
> >> First one is we'll probably have our users need to change some details
> >> of how they build.
> >> Infinispan might need to fix some SPI related code before being able
> >> to upgrade, but historically our SPI has been extremely stable.
> >> The real problem is that when such a thing happens, after we've
> >> released a version of Search there might be some time before a
> >> compatible version of Infinispan is made available as well.
> >>
> >> In practice this means the gap of time in which we have to catch up on
> >> API changes is "exposed" to end users wanting to use our latest and
> >> possibly blocked - but while they would then see the tip of the
> >> iceberg of our integration, I believe it would still take the same
> >> amount of waiting time in terms of calendar dates in which the working
> >> duo is available to them - as with the current model in such a
> >> situation we need to wait for the same Infinispan release to happen
> >> before we can release ours.
> >> So: same time, but we'd have a leaner process, and possibly quicker
> >> releases for all users not interested in that - or just benefits in
> >> all those scenarios in which we don't break APIs which is very common.
> >> I've not identified other problems, so my opinion is that these are
> >> well worth the benefits.
> >>
> >> # Consequences for our users
> >>
> >> Not much. Even today we expect our users to depend on several jar
> >> files provided by the Infinispan team; this would be just one more.
> >> Opens some questions though:
> >>
> >>  A) Should the Maven group id be changed? I'd expect it to be
> >> transferred to "org.infinispan" group at least, and probably need a
> >> better artifact id too.
> >>
> >>  B) License. Our code is LGPL, most of Infinispan is ASL - but not all
> >> of it. So I expect it would be possible to keep the existing license
> >> at least for now, and defer eventual license changes as a separate
> >> step (if people feel need for any change at all).
> >>
> >>  C) Documentation. Besides the needed updates in Maven coordinates /
> >> download sources, I don't expect much of a difference: we'd still
> >> explain how to set this integration up.
> >>
> >>  D) Distribution. Today we distribute this module, and its
> >> dependencies, in our release bundles. Which implies we distribute a
> >> copy of various Infinispan jars.
> >> I think we should drop these from our distribution - even though it
> >> might seem counter-intuitive:
> >> while it might seem convenient to have these included, the whole point
> >> of the change would be that there would be more flexibility in which
> >> versions of Infinispan would work with Search. And actually the
> >> integration tests and this specific knowledge would be responsibility
> >> of Infinispan.
> >>
> >> Am I failing to see a more critical issue?
> >> How would you all feel about our code being transferred to the
> >> different project?
> >>
> >> Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>

From sanne at hibernate.org  Mon Jan 26 08:21:20 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 26 Jan 2015 13:21:20 +0000
Subject: [hibernate-dev] Search 5 migration pains: MultiFieldQueryParser and
	Numeric Fields
Message-ID: <CAFm4XO0nPs-MDMvNvBEkiYzOU9mxEQDUw_3AqicfYafXOzNPHA@mail.gmail.com>

As reported on SO [1], it's not a straight forward migration for those
who embraced the convenience of using a MultiFieldQueryParser, or one
of the other Lucene provided parsers.

In the specific example, I think the right answer would be to use the
programmatic API or our DSL.. but let's consider the use case in which
you want to parse user input, from a text input in your application?

Using the parser is quite convenient in such a case, as people can
express boolean operators and field names, while keeping the UI very
simple.

Wouldn't it be nice to have a custom "parser" in our DSL, which
essentially mimicks the functionality of the MultiFieldQueryParser but
takes advantage of our indexing metadata - like we do for the HQL
Parser?

Sanne


1 - http://stackoverflow.com/questions/28138308/hibernate-search-5-0-numeric-lucene-query-hsearch000233-issue

From hardy at hibernate.org  Mon Jan 26 08:39:06 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 26 Jan 2015 14:39:06 +0100
Subject: [hibernate-dev] Search 5 migration pains: MultiFieldQueryParser
 and Numeric Fields
In-Reply-To: <CAFm4XO0nPs-MDMvNvBEkiYzOU9mxEQDUw_3AqicfYafXOzNPHA@mail.gmail.com>
References: <CAFm4XO0nPs-MDMvNvBEkiYzOU9mxEQDUw_3AqicfYafXOzNPHA@mail.gmail.com>
Message-ID: <20150126133906.GA4550@Sarmakand-4.local>

Hi,

On Mon, Jan 26, 2015 at 01:21:20PM +0000, Sanne Grinovero wrote:
> As reported on SO [1], it's not a straight forward migration for those
> who embraced the convenience of using a MultiFieldQueryParser, or one
> of the other Lucene provided parsers.

That is correct, but we knew that right? The docs explain the situation and
we need to make sure that we answer these type of questions.

> In the specific example, I think the right answer would be to use the
> programmatic API or our DSL.. 

It depends. If the user wants to keep the old behaviour and is happy with
it, he can just make sure that the numeric values as indexed as strings.
Personally, I am not going to recommend to switch to the DSL.

> Wouldn't it be nice to have a custom "parser" in our DSL, which
> essentially mimicks the functionality of the MultiFieldQueryParser but
> takes advantage of our indexing metadata - like we do for the HQL
> Parser?

We could in fact do that. I thought there was even an issue for that.
If not I at least wanted to create one ;-) As you are saying, we have the 
required information (whether a field is numeric or not) available. So we could
write a custom QueryParser which takes this into account. We might even not
only use it in the DSL, but also make it available standalone

--Hardy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150126/fbebb30f/attachment.bin 

From emmanuel at hibernate.org  Mon Jan 26 09:01:17 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 26 Jan 2015 15:01:17 +0100
Subject: [hibernate-dev] Search 5 migration pains: MultiFieldQueryParser
	and Numeric Fields
In-Reply-To: <CAFm4XO0nPs-MDMvNvBEkiYzOU9mxEQDUw_3AqicfYafXOzNPHA@mail.gmail.com>
References: <CAFm4XO0nPs-MDMvNvBEkiYzOU9mxEQDUw_3AqicfYafXOzNPHA@mail.gmail.com>
Message-ID: <225F839C-A59A-4D5C-9D09-BE80EF43706A@hibernate.org>

Yes but let?s put it in perspective to all the goals we have :)

> On 26 Jan 2015, at 14:21, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> As reported on SO [1], it's not a straight forward migration for those
> who embraced the convenience of using a MultiFieldQueryParser, or one
> of the other Lucene provided parsers.
> 
> In the specific example, I think the right answer would be to use the
> programmatic API or our DSL.. but let's consider the use case in which
> you want to parse user input, from a text input in your application?
> 
> Using the parser is quite convenient in such a case, as people can
> express boolean operators and field names, while keeping the UI very
> simple.
> 
> Wouldn't it be nice to have a custom "parser" in our DSL, which
> essentially mimicks the functionality of the MultiFieldQueryParser but
> takes advantage of our indexing metadata - like we do for the HQL
> Parser?
> 
> Sanne
> 
> 
> 1 - http://stackoverflow.com/questions/28138308/hibernate-search-5-0-numeric-lucene-query-hsearch000233-issue
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From hardy at hibernate.org  Mon Jan 26 09:13:12 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 26 Jan 2015 15:13:12 +0100
Subject: [hibernate-dev] Search 5 migration pains: MultiFieldQueryParser
 and Numeric Fields
In-Reply-To: <225F839C-A59A-4D5C-9D09-BE80EF43706A@hibernate.org>
References: <CAFm4XO0nPs-MDMvNvBEkiYzOU9mxEQDUw_3AqicfYafXOzNPHA@mail.gmail.com>
	<225F839C-A59A-4D5C-9D09-BE80EF43706A@hibernate.org>
Message-ID: <20150126141312.GB4550@Sarmakand-4.local>

On Mon, Jan 26, 2015 at 03:01:17PM +0100, Emmanuel Bernard wrote:
> Yes but let?s put it in perspective to all the goals we have :)

Right, same with the potential Search 5 upgrade (I also think we should
do it asap). It is all a question of priority and the time we have to work
on this.

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150126/779a18e9/attachment.bin 

From emmanuel at hibernate.org  Mon Jan 26 09:39:14 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 26 Jan 2015 15:39:14 +0100
Subject: [hibernate-dev] Search 5 migration pains: MultiFieldQueryParser
	and Numeric Fields
In-Reply-To: <20150126141312.GB4550@Sarmakand-4.local>
References: <CAFm4XO0nPs-MDMvNvBEkiYzOU9mxEQDUw_3AqicfYafXOzNPHA@mail.gmail.com>
	<225F839C-A59A-4D5C-9D09-BE80EF43706A@hibernate.org>
	<20150126141312.GB4550@Sarmakand-4.local>
Message-ID: <6B1BD7ED-381C-42FB-8948-18F111169BA9@hibernate.org>


> On 26 Jan 2015, at 15:13, Hardy Ferentschik <hardy at hibernate.org> wrote:
> 
> Right, same with the potential Search 5 upgrade (I also think we should
> do it asap).

I am not following you on that? We are at Hibernate Search 5 already.

From emmanuel at hibernate.org  Mon Jan 26 10:05:39 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 26 Jan 2015 16:05:39 +0100
Subject: [hibernate-dev] [Hibernate Search] Donating some of our source
	code to Infinispan
In-Reply-To: <CAFm4XO2H5h6bccne=cPzg5U9od3pj7LXV49p-un8oaQ1NCd9Vg@mail.gmail.com>
References: <CAFm4XO2H5h6bccne=cPzg5U9od3pj7LXV49p-un8oaQ1NCd9Vg@mail.gmail.com>
Message-ID: <7909DCF1-048D-4A2F-8CC8-70616C86C925@hibernate.org>

One angle that is a bit unclear to me is how easy is this consumable and discoverable by our users.

Some in this thread mentioned creating a separate repository. I see this as a massive ease of use problem if the user is exposed to finding the right version of each of these three libs. Likewise for documentation, project identity, etc.

I think the merge of this piece of code into Infinispan does not create too much of a problem in that regard. The main issue is that as an Hibernate Search user, I don?t know which Infinispan to target. And an Infinispan user does not really care for the most part about an explicit HSearch usage outside Infinispan query.

BTW will the documentation on HSearch integration with Infinispan Lucene Directory remain in HSearch?s doc or be copied in Infinispan?s?

Emmanuel

> On 25 Jan 2015, at 22:19, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> All,
> we've discussed several times the issues we have because of the
> circular dependency between Hibernate Search and Infinispan.
> Normally the pain point we aim to address with such discussions is the
> need to carefully coordinate between releases [of Search and
> Infinispan] in our quest for a final stable release, and brings some
> release pressure.
> 
> More recently it has also become a compatibility problem, as the two
> projects target different platforms/environments, and have different
> life-cycle expectations - creating more maintenance work such as lots
> of back-porting of patches.. distracting from our goals.
> 
> We already discussed some solutions, but none too convincing. I have a
> new fresh proposal which I feel is more interesting:
> 
> # New plan
> 
> 1) the module "/infinispan" from the Hibernate Search source tree is
> moved to the Infinispan project into some "hibernate-search-directory"
> Maven module.
> 
> 2) Hibernate Search drops any dependency to Infinispan
> 
> Reminder: this "/infinispan" module we have contains just a couple of
> classes, and represents the "DirectoryProvider" implementation which
> integrates with the Hibernate Search autodiscovery and creates a
> Directory instance (whose implementation always lived in Infinispan).
> Most of the code is about applying configuration properties,
> integration tests.
> 
> It's a very simple plan, but has some valuable consequences:
> - Search can move on without ever needing to wait for Infinispan -
> and vice versa.
> - There is no longer a circular dependency
> - Search would be in control of its Lucene dependency, and can
> upgrade as needed. We could experiment with different Lucene versions
> without necessarily wait for Infinispan to solve compatiblity issues
> first - and often more complex as that means then for Infinispan to be
> able to guarantee a compatibility with a *range* of Lucene versions,
> to include both the target Lucene and the version currently consumed
> via Infinispan Query / Hibernate Search Engine.
> - Infinispan can *opt* to stick with an older version of Search - or
> update - provided it can satisfy both a) integration with possible
> changes to the Search SPI b) an update for possible new requirements
> of the new Lucene version (the Lucene Directory might need
> compatibility fixes)
> - The dependency structure would better match the one as provided by
> our Enterprise Products. For example, it's the JDG distribution - not
> Hibernate Search - to provide these integration bits, so it makes more
> sense to build the Directory against the specific version of
> Infinispan than against the specific version of Search.
> - It will be easier to have new Infinispan code take advantage of
> features exposed on the Infinispan Lucene Directory - if all changed
> parts are in the same [Infinispan] repository. This is actually being
> a problem right now, as it's holding back a POC meant to deliver great
> improvements with the Directory implementation.
> 
> And not least we'll have faster builds ;-)
> 
> # Drawbacks
> 
> First one is we'll probably have our users need to change some details
> of how they build.
> Infinispan might need to fix some SPI related code before being able
> to upgrade, but historically our SPI has been extremely stable.
> The real problem is that when such a thing happens, after we've
> released a version of Search there might be some time before a
> compatible version of Infinispan is made available as well.
> 
> In practice this means the gap of time in which we have to catch up on
> API changes is "exposed" to end users wanting to use our latest and
> possibly blocked - but while they would then see the tip of the
> iceberg of our integration, I believe it would still take the same
> amount of waiting time in terms of calendar dates in which the working
> duo is available to them - as with the current model in such a
> situation we need to wait for the same Infinispan release to happen
> before we can release ours.
> So: same time, but we'd have a leaner process, and possibly quicker
> releases for all users not interested in that - or just benefits in
> all those scenarios in which we don't break APIs which is very common.
> I've not identified other problems, so my opinion is that these are
> well worth the benefits.
> 
> # Consequences for our users
> 
> Not much. Even today we expect our users to depend on several jar
> files provided by the Infinispan team; this would be just one more.
> Opens some questions though:
> 
> A) Should the Maven group id be changed? I'd expect it to be
> transferred to "org.infinispan" group at least, and probably need a
> better artifact id too.
> 
> B) License. Our code is LGPL, most of Infinispan is ASL - but not all
> of it. So I expect it would be possible to keep the existing license
> at least for now, and defer eventual license changes as a separate
> step (if people feel need for any change at all).
> 
> C) Documentation. Besides the needed updates in Maven coordinates /
> download sources, I don't expect much of a difference: we'd still
> explain how to set this integration up.
> 
> D) Distribution. Today we distribute this module, and its
> dependencies, in our release bundles. Which implies we distribute a
> copy of various Infinispan jars.
> I think we should drop these from our distribution - even though it
> might seem counter-intuitive:
> while it might seem convenient to have these included, the whole point
> of the change would be that there would be more flexibility in which
> versions of Infinispan would work with Search. And actually the
> integration tests and this specific knowledge would be responsibility
> of Infinispan.
> 
> Am I failing to see a more critical issue?
> How would you all feel about our code being transferred to the
> different project?
> 
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From hardy at hibernate.org  Mon Jan 26 10:49:43 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 26 Jan 2015 16:49:43 +0100
Subject: [hibernate-dev] Search 5 migration pains: MultiFieldQueryParser
 and Numeric Fields
In-Reply-To: <6B1BD7ED-381C-42FB-8948-18F111169BA9@hibernate.org>
References: <CAFm4XO0nPs-MDMvNvBEkiYzOU9mxEQDUw_3AqicfYafXOzNPHA@mail.gmail.com>
	<225F839C-A59A-4D5C-9D09-BE80EF43706A@hibernate.org>
	<20150126141312.GB4550@Sarmakand-4.local>
	<6B1BD7ED-381C-42FB-8948-18F111169BA9@hibernate.org>
Message-ID: <20150126154943.GA5543@Sarmakand-4.local>

On Mon, Jan 26, 2015 at 03:39:14PM +0100, Emmanuel Bernard wrote:
> > Right, same with the potential Search 5 upgrade (I also think we should
> > do it asap).
> 
> I am not following you on that? We are at Hibernate Search 5 already.

Sorry, meant to write Lucene 5, referring to Sanne's email from earlier.

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150126/6c679f3a/attachment.bin 

From sanne at hibernate.org  Mon Jan 26 11:08:24 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 26 Jan 2015 16:08:24 +0000
Subject: [hibernate-dev] [Hibernate Search] Donating some of our source
 code to Infinispan
In-Reply-To: <7909DCF1-048D-4A2F-8CC8-70616C86C925@hibernate.org>
References: <CAFm4XO2H5h6bccne=cPzg5U9od3pj7LXV49p-un8oaQ1NCd9Vg@mail.gmail.com>
	<7909DCF1-048D-4A2F-8CC8-70616C86C925@hibernate.org>
Message-ID: <CAFm4XO2AMRQgG5V7LjnmCjvFOSOhtBVmfU4PU7_HOi3mM-vJMA@mail.gmail.com>

On 26 January 2015 at 15:05, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> One angle that is a bit unclear to me is how easy is this consumable and discoverable by our users.

Discovery would be the same as today, same configuration property.
We have your "resolution strategy" which translates from short name to
fully qualified name, which is already "pluggable" in the case of the
IndexManager lookup. So we have plenty of options A) look for the new
FQCN B) plug a custom resolver strategy for the DirectoryProvider
names C)use the custom IndexManager: we had already decided at our f2f
meeting that it would be far easier for people to only have to choose
the IndexManager implementation, which would be in charge of setting
up the right backend/directory couples as a "profile".

WildFly users don't even need to know about changes in the module
names / jar names / maven coordinates as the instructions would still
be: download both modules, drop them in your AS -> works.

In short, we can keep user changes to minimal.

> Some in this thread mentioned creating a separate repository. I see this as a massive ease of use problem if the user is exposed to finding the right version of each of these three libs. Likewise for documentation, project identity, etc.

+1 not my preferred choice either. I think we'll stick to my plan, at
least until I'm proven this proposal is utterly broken.

> I think the merge of this piece of code into Infinispan does not create too much of a problem in that regard. The main issue is that as an Hibernate Search user, I don?t know which Infinispan to target. And an Infinispan user does not really care for the most part about an explicit HSearch usage outside Infinispan query.

We'll have to document that. Indeed quite tricky, as there might be
cases in which there is no compatible version of Infinispan whatsoever
(for example each time we migrate to a new Lucene there would be a
gap).. but my hope is that would be some Alpha/Beta, and by the time
of a Final release we'd have a viable suggestion, with more options
while the branch matures in maintenance mode.

> BTW will the documentation on HSearch integration with Infinispan Lucene Directory remain in HSearch?s doc or be copied in Infinispan?s?

I'd prefer to have a single consistent document for our users to read:
we'd have the high level description from the point of view of an
Hibernate user, and exposing to the subset of tuning options which
make sense to him.
Infinispan should have a different copy, especially as it's becoming
clear that tuning and configuration for this specific component is
quite different in the two different use cases. Ultimately both
"engines" should be able to guess and auto-configure several options
which are manual today, and these guessing and custom backends are
different.
The low level details of the Directory tuning should probably live in
Infinispan only, in close coupling to the code changes, to make sure
there is a document set kept in synch with the specific version. From
experience we know the new configuration options needed by Infinispan
are rarely in the "need to know" for Hibernate users.

Sanne

>
> Emmanuel
>
>> On 25 Jan 2015, at 22:19, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> All,
>> we've discussed several times the issues we have because of the
>> circular dependency between Hibernate Search and Infinispan.
>> Normally the pain point we aim to address with such discussions is the
>> need to carefully coordinate between releases [of Search and
>> Infinispan] in our quest for a final stable release, and brings some
>> release pressure.
>>
>> More recently it has also become a compatibility problem, as the two
>> projects target different platforms/environments, and have different
>> life-cycle expectations - creating more maintenance work such as lots
>> of back-porting of patches.. distracting from our goals.
>>
>> We already discussed some solutions, but none too convincing. I have a
>> new fresh proposal which I feel is more interesting:
>>
>> # New plan
>>
>> 1) the module "/infinispan" from the Hibernate Search source tree is
>> moved to the Infinispan project into some "hibernate-search-directory"
>> Maven module.
>>
>> 2) Hibernate Search drops any dependency to Infinispan
>>
>> Reminder: this "/infinispan" module we have contains just a couple of
>> classes, and represents the "DirectoryProvider" implementation which
>> integrates with the Hibernate Search autodiscovery and creates a
>> Directory instance (whose implementation always lived in Infinispan).
>> Most of the code is about applying configuration properties,
>> integration tests.
>>
>> It's a very simple plan, but has some valuable consequences:
>> - Search can move on without ever needing to wait for Infinispan -
>> and vice versa.
>> - There is no longer a circular dependency
>> - Search would be in control of its Lucene dependency, and can
>> upgrade as needed. We could experiment with different Lucene versions
>> without necessarily wait for Infinispan to solve compatiblity issues
>> first - and often more complex as that means then for Infinispan to be
>> able to guarantee a compatibility with a *range* of Lucene versions,
>> to include both the target Lucene and the version currently consumed
>> via Infinispan Query / Hibernate Search Engine.
>> - Infinispan can *opt* to stick with an older version of Search - or
>> update - provided it can satisfy both a) integration with possible
>> changes to the Search SPI b) an update for possible new requirements
>> of the new Lucene version (the Lucene Directory might need
>> compatibility fixes)
>> - The dependency structure would better match the one as provided by
>> our Enterprise Products. For example, it's the JDG distribution - not
>> Hibernate Search - to provide these integration bits, so it makes more
>> sense to build the Directory against the specific version of
>> Infinispan than against the specific version of Search.
>> - It will be easier to have new Infinispan code take advantage of
>> features exposed on the Infinispan Lucene Directory - if all changed
>> parts are in the same [Infinispan] repository. This is actually being
>> a problem right now, as it's holding back a POC meant to deliver great
>> improvements with the Directory implementation.
>>
>> And not least we'll have faster builds ;-)
>>
>> # Drawbacks
>>
>> First one is we'll probably have our users need to change some details
>> of how they build.
>> Infinispan might need to fix some SPI related code before being able
>> to upgrade, but historically our SPI has been extremely stable.
>> The real problem is that when such a thing happens, after we've
>> released a version of Search there might be some time before a
>> compatible version of Infinispan is made available as well.
>>
>> In practice this means the gap of time in which we have to catch up on
>> API changes is "exposed" to end users wanting to use our latest and
>> possibly blocked - but while they would then see the tip of the
>> iceberg of our integration, I believe it would still take the same
>> amount of waiting time in terms of calendar dates in which the working
>> duo is available to them - as with the current model in such a
>> situation we need to wait for the same Infinispan release to happen
>> before we can release ours.
>> So: same time, but we'd have a leaner process, and possibly quicker
>> releases for all users not interested in that - or just benefits in
>> all those scenarios in which we don't break APIs which is very common.
>> I've not identified other problems, so my opinion is that these are
>> well worth the benefits.
>>
>> # Consequences for our users
>>
>> Not much. Even today we expect our users to depend on several jar
>> files provided by the Infinispan team; this would be just one more.
>> Opens some questions though:
>>
>> A) Should the Maven group id be changed? I'd expect it to be
>> transferred to "org.infinispan" group at least, and probably need a
>> better artifact id too.
>>
>> B) License. Our code is LGPL, most of Infinispan is ASL - but not all
>> of it. So I expect it would be possible to keep the existing license
>> at least for now, and defer eventual license changes as a separate
>> step (if people feel need for any change at all).
>>
>> C) Documentation. Besides the needed updates in Maven coordinates /
>> download sources, I don't expect much of a difference: we'd still
>> explain how to set this integration up.
>>
>> D) Distribution. Today we distribute this module, and its
>> dependencies, in our release bundles. Which implies we distribute a
>> copy of various Infinispan jars.
>> I think we should drop these from our distribution - even though it
>> might seem counter-intuitive:
>> while it might seem convenient to have these included, the whole point
>> of the change would be that there would be more flexibility in which
>> versions of Infinispan would work with Search. And actually the
>> integration tests and this specific knowledge would be responsibility
>> of Infinispan.
>>
>> Am I failing to see a more critical issue?
>> How would you all feel about our code being transferred to the
>> different project?
>>
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From emmanuel at hibernate.org  Mon Jan 26 11:20:29 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 26 Jan 2015 17:20:29 +0100
Subject: [hibernate-dev] [Hibernate Search] Donating some of our source
	code to Infinispan
In-Reply-To: <CAFm4XO2AMRQgG5V7LjnmCjvFOSOhtBVmfU4PU7_HOi3mM-vJMA@mail.gmail.com>
References: <CAFm4XO2H5h6bccne=cPzg5U9od3pj7LXV49p-un8oaQ1NCd9Vg@mail.gmail.com>
	<7909DCF1-048D-4A2F-8CC8-70616C86C925@hibernate.org>
	<CAFm4XO2AMRQgG5V7LjnmCjvFOSOhtBVmfU4PU7_HOi3mM-vJMA@mail.gmail.com>
Message-ID: <B4A277D8-44FD-44AD-81BF-D1DE4E4387E6@hibernate.org>

I mean discoverable by humans. i.e. easly seeing that the feature even exists. I could not care less about pluggable lookup strategies ;)

> On 26 Jan 2015, at 17:08, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> On 26 January 2015 at 15:05, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> One angle that is a bit unclear to me is how easy is this consumable and discoverable by our users.
> 
> Discovery would be the same as today, same configuration property.
> We have your "resolution strategy" which translates from short name to
> fully qualified name, which is already "pluggable" in the case of the
> IndexManager lookup. So we have plenty of options A) look for the new
> FQCN B) plug a custom resolver strategy for the DirectoryProvider
> names C)use the custom IndexManager: we had already decided at our f2f
> meeting that it would be far easier for people to only have to choose
> the IndexManager implementation, which would be in charge of setting
> up the right backend/directory couples as a "profile".
> 
> WildFly users don't even need to know about changes in the module
> names / jar names / maven coordinates as the instructions would still
> be: download both modules, drop them in your AS -> works.
> 
> In short, we can keep user changes to minimal.
> 
>> Some in this thread mentioned creating a separate repository. I see this as a massive ease of use problem if the user is exposed to finding the right version of each of these three libs. Likewise for documentation, project identity, etc.
> 
> +1 not my preferred choice either. I think we'll stick to my plan, at
> least until I'm proven this proposal is utterly broken.
> 
>> I think the merge of this piece of code into Infinispan does not create too much of a problem in that regard. The main issue is that as an Hibernate Search user, I don?t know which Infinispan to target. And an Infinispan user does not really care for the most part about an explicit HSearch usage outside Infinispan query.
> 
> We'll have to document that. Indeed quite tricky, as there might be
> cases in which there is no compatible version of Infinispan whatsoever
> (for example each time we migrate to a new Lucene there would be a
> gap).. but my hope is that would be some Alpha/Beta, and by the time
> of a Final release we'd have a viable suggestion, with more options
> while the branch matures in maintenance mode.
> 
>> BTW will the documentation on HSearch integration with Infinispan Lucene Directory remain in HSearch?s doc or be copied in Infinispan?s?
> 
> I'd prefer to have a single consistent document for our users to read:
> we'd have the high level description from the point of view of an
> Hibernate user, and exposing to the subset of tuning options which
> make sense to him.
> Infinispan should have a different copy, especially as it's becoming
> clear that tuning and configuration for this specific component is
> quite different in the two different use cases. Ultimately both
> "engines" should be able to guess and auto-configure several options
> which are manual today, and these guessing and custom backends are
> different.
> The low level details of the Directory tuning should probably live in
> Infinispan only, in close coupling to the code changes, to make sure
> there is a document set kept in synch with the specific version. From
> experience we know the new configuration options needed by Infinispan
> are rarely in the "need to know" for Hibernate users.
> 
> Sanne
> 
>> 
>> Emmanuel
>> 
>>> On 25 Jan 2015, at 22:19, Sanne Grinovero <sanne at hibernate.org> wrote:
>>> 
>>> All,
>>> we've discussed several times the issues we have because of the
>>> circular dependency between Hibernate Search and Infinispan.
>>> Normally the pain point we aim to address with such discussions is the
>>> need to carefully coordinate between releases [of Search and
>>> Infinispan] in our quest for a final stable release, and brings some
>>> release pressure.
>>> 
>>> More recently it has also become a compatibility problem, as the two
>>> projects target different platforms/environments, and have different
>>> life-cycle expectations - creating more maintenance work such as lots
>>> of back-porting of patches.. distracting from our goals.
>>> 
>>> We already discussed some solutions, but none too convincing. I have a
>>> new fresh proposal which I feel is more interesting:
>>> 
>>> # New plan
>>> 
>>> 1) the module "/infinispan" from the Hibernate Search source tree is
>>> moved to the Infinispan project into some "hibernate-search-directory"
>>> Maven module.
>>> 
>>> 2) Hibernate Search drops any dependency to Infinispan
>>> 
>>> Reminder: this "/infinispan" module we have contains just a couple of
>>> classes, and represents the "DirectoryProvider" implementation which
>>> integrates with the Hibernate Search autodiscovery and creates a
>>> Directory instance (whose implementation always lived in Infinispan).
>>> Most of the code is about applying configuration properties,
>>> integration tests.
>>> 
>>> It's a very simple plan, but has some valuable consequences:
>>> - Search can move on without ever needing to wait for Infinispan -
>>> and vice versa.
>>> - There is no longer a circular dependency
>>> - Search would be in control of its Lucene dependency, and can
>>> upgrade as needed. We could experiment with different Lucene versions
>>> without necessarily wait for Infinispan to solve compatiblity issues
>>> first - and often more complex as that means then for Infinispan to be
>>> able to guarantee a compatibility with a *range* of Lucene versions,
>>> to include both the target Lucene and the version currently consumed
>>> via Infinispan Query / Hibernate Search Engine.
>>> - Infinispan can *opt* to stick with an older version of Search - or
>>> update - provided it can satisfy both a) integration with possible
>>> changes to the Search SPI b) an update for possible new requirements
>>> of the new Lucene version (the Lucene Directory might need
>>> compatibility fixes)
>>> - The dependency structure would better match the one as provided by
>>> our Enterprise Products. For example, it's the JDG distribution - not
>>> Hibernate Search - to provide these integration bits, so it makes more
>>> sense to build the Directory against the specific version of
>>> Infinispan than against the specific version of Search.
>>> - It will be easier to have new Infinispan code take advantage of
>>> features exposed on the Infinispan Lucene Directory - if all changed
>>> parts are in the same [Infinispan] repository. This is actually being
>>> a problem right now, as it's holding back a POC meant to deliver great
>>> improvements with the Directory implementation.
>>> 
>>> And not least we'll have faster builds ;-)
>>> 
>>> # Drawbacks
>>> 
>>> First one is we'll probably have our users need to change some details
>>> of how they build.
>>> Infinispan might need to fix some SPI related code before being able
>>> to upgrade, but historically our SPI has been extremely stable.
>>> The real problem is that when such a thing happens, after we've
>>> released a version of Search there might be some time before a
>>> compatible version of Infinispan is made available as well.
>>> 
>>> In practice this means the gap of time in which we have to catch up on
>>> API changes is "exposed" to end users wanting to use our latest and
>>> possibly blocked - but while they would then see the tip of the
>>> iceberg of our integration, I believe it would still take the same
>>> amount of waiting time in terms of calendar dates in which the working
>>> duo is available to them - as with the current model in such a
>>> situation we need to wait for the same Infinispan release to happen
>>> before we can release ours.
>>> So: same time, but we'd have a leaner process, and possibly quicker
>>> releases for all users not interested in that - or just benefits in
>>> all those scenarios in which we don't break APIs which is very common.
>>> I've not identified other problems, so my opinion is that these are
>>> well worth the benefits.
>>> 
>>> # Consequences for our users
>>> 
>>> Not much. Even today we expect our users to depend on several jar
>>> files provided by the Infinispan team; this would be just one more.
>>> Opens some questions though:
>>> 
>>> A) Should the Maven group id be changed? I'd expect it to be
>>> transferred to "org.infinispan" group at least, and probably need a
>>> better artifact id too.
>>> 
>>> B) License. Our code is LGPL, most of Infinispan is ASL - but not all
>>> of it. So I expect it would be possible to keep the existing license
>>> at least for now, and defer eventual license changes as a separate
>>> step (if people feel need for any change at all).
>>> 
>>> C) Documentation. Besides the needed updates in Maven coordinates /
>>> download sources, I don't expect much of a difference: we'd still
>>> explain how to set this integration up.
>>> 
>>> D) Distribution. Today we distribute this module, and its
>>> dependencies, in our release bundles. Which implies we distribute a
>>> copy of various Infinispan jars.
>>> I think we should drop these from our distribution - even though it
>>> might seem counter-intuitive:
>>> while it might seem convenient to have these included, the whole point
>>> of the change would be that there would be more flexibility in which
>>> versions of Infinispan would work with Search. And actually the
>>> integration tests and this specific knowledge would be responsibility
>>> of Infinispan.
>>> 
>>> Am I failing to see a more critical issue?
>>> How would you all feel about our code being transferred to the
>>> different project?
>>> 
>>> Sanne
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 



From sanne at hibernate.org  Mon Jan 26 11:24:58 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 26 Jan 2015 16:24:58 +0000
Subject: [hibernate-dev] [Hibernate Search] Donating some of our source
 code to Infinispan
In-Reply-To: <B4A277D8-44FD-44AD-81BF-D1DE4E4387E6@hibernate.org>
References: <CAFm4XO2H5h6bccne=cPzg5U9od3pj7LXV49p-un8oaQ1NCd9Vg@mail.gmail.com>
	<7909DCF1-048D-4A2F-8CC8-70616C86C925@hibernate.org>
	<CAFm4XO2AMRQgG5V7LjnmCjvFOSOhtBVmfU4PU7_HOi3mM-vJMA@mail.gmail.com>
	<B4A277D8-44FD-44AD-81BF-D1DE4E4387E6@hibernate.org>
Message-ID: <CAFm4XO3H57TaU6_S9Doe6vXWGFwTb3-m=4K4QKsNe6Nn=QSNsA@mail.gmail.com>

On 26 January 2015 at 16:20, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> I mean discoverable by humans. i.e. easly seeing that the feature even exists. I could not care less about pluggable lookup strategies ;)

Ok. Well then I think I covered it too, but to summarize:
 - same configuration property
 - same documentation coverage
 - not included in the distribution

From gunnar at hibernate.org  Tue Jan 27 13:00:15 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 27 Jan 2015 19:00:15 +0100
Subject: [hibernate-dev] [HSEARCH] *.next Jira versions
Message-ID: <CADGJaX8og3CZtU5CYPLkHGcAv6mXAWX3AjBHKNTbkWLBZmSXeA@mail.gmail.com>

Hi,

There are many (new?) versions in Jira such as 3.1.next, 3.2.next etc.

Are those all needed? 5.x makes sense to me, and maybe 4.5.next, but all
the old ones? All these unreleased versions make it a bit unwieldy when
assigning a fix version to an issue.

Thx,

--Gunnar

From hardy at hibernate.org  Tue Jan 27 17:08:48 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 27 Jan 2015 23:08:48 +0100
Subject: [hibernate-dev] [HSEARCH] *.next Jira versions
In-Reply-To: <CADGJaX8og3CZtU5CYPLkHGcAv6mXAWX3AjBHKNTbkWLBZmSXeA@mail.gmail.com>
References: <CADGJaX8og3CZtU5CYPLkHGcAv6mXAWX3AjBHKNTbkWLBZmSXeA@mail.gmail.com>
Message-ID: <20150127220848.GB7137@Sarmakand-4.local>

Hi,

On Tue, Jan 27, 2015 at 07:00:15PM +0100, Gunnar Morling wrote:
> There are many (new?) versions in Jira such as 3.1.next, 3.2.next etc.
> 
> Are those all needed? 5.x makes sense to me, and maybe 4.5.next, but all
> the old ones? All these unreleased versions make it a bit unwieldy when
> assigning a fix version to an issue.

+1 I also find it unwieldy, not only for assigning a fix version, but also when
"browsing" by version when on the project home page. I also find it sub-optimal
that if on the project summary the visible versions are 3.1.next, 3.2.next ... 4.1.next.

This is partly related to the components discussion we had a while back. IMO 
HSEARCH Jira needs a bit of a make-over.

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150127/413533dc/attachment.bin 

From sanne at hibernate.org  Tue Jan 27 17:41:02 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 27 Jan 2015 22:41:02 +0000
Subject: [hibernate-dev] [HSEARCH] *.next Jira versions
In-Reply-To: <20150127220848.GB7137@Sarmakand-4.local>
References: <CADGJaX8og3CZtU5CYPLkHGcAv6mXAWX3AjBHKNTbkWLBZmSXeA@mail.gmail.com>
	<20150127220848.GB7137@Sarmakand-4.local>
Message-ID: <CAFm4XO34o4Pi3tfzMDo28GJRgmNk93Fj9egRSv+H7M3kiT72Og@mail.gmail.com>

Ok, all outdated versions are now either pruned or archived.

I'm still keeping 4.4.next and 4.5.next around for a little longer, as
some final touches are needed before we close these.

What's the suggestion for components?

These I'd want to keep:
 - documentation
 - testing
 - build
I guess these never were much of a source of confusion?

These I don't think are a good fit any more - unless we want a very
precise granularity:
 - optimizer (Any Optimizer is deprecated)
 - directory provider (Except the MasterDP, they are all trivial -
we'd probably focus on the more general IndexManager nowadays)

These I think are quite well defined, but I'm not sure if we're all on
the same page:
 - backend
 - query
 - serialization
 - spatial
 - mapping

The "infinispan" is becoming tricky. It used to be just "those things
in the /infinispan module", but nowadays we have many more
interactions - not least some issues have been tagged with this with
the (wrong IMO) meaning of "needed for Infinispan" as in blocking some
issue in the Infinispan Query project.

But remember that deleting unused components has consequences: affects
a thousand closed issues. I'd rather accept that these will not be
used much anymore.
Adding new components also better be worth it, as you'd have to accept
either of two evils:
 A) you'll need to re-classify all existing issues
 B) you'll have to accept that old issues won't show up classified
nicely, in case you're searching for them or looking at per-component
metrics over time..

Sanne

On 27 January 2015 at 22:08, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
> On Tue, Jan 27, 2015 at 07:00:15PM +0100, Gunnar Morling wrote:
>> There are many (new?) versions in Jira such as 3.1.next, 3.2.next etc.
>>
>> Are those all needed? 5.x makes sense to me, and maybe 4.5.next, but all
>> the old ones? All these unreleased versions make it a bit unwieldy when
>> assigning a fix version to an issue.
>
> +1 I also find it unwieldy, not only for assigning a fix version, but also when
> "browsing" by version when on the project home page. I also find it sub-optimal
> that if on the project summary the visible versions are 3.1.next, 3.2.next ... 4.1.next.
>
> This is partly related to the components discussion we had a while back. IMO
> HSEARCH Jira needs a bit of a make-over.
>
> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed Jan 28 09:59:17 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 28 Jan 2015 15:59:17 +0100
Subject: [hibernate-dev] [HSEARCH] *.next Jira versions
In-Reply-To: <CAFm4XO34o4Pi3tfzMDo28GJRgmNk93Fj9egRSv+H7M3kiT72Og@mail.gmail.com>
References: <CADGJaX8og3CZtU5CYPLkHGcAv6mXAWX3AjBHKNTbkWLBZmSXeA@mail.gmail.com>
	<20150127220848.GB7137@Sarmakand-4.local>
	<CAFm4XO34o4Pi3tfzMDo28GJRgmNk93Fj9egRSv+H7M3kiT72Og@mail.gmail.com>
Message-ID: <CADGJaX_ESkpEx50sFjbcLFTTp2hKha2FD051ZMzuVpuLf28GOA@mail.gmail.com>

2015-01-27 23:41 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> Ok, all outdated versions are now either pruned or archived.
>
> I'm still keeping 4.4.next and 4.5.next around for a little longer, as
> some final touches are needed before we close these.
>

Thanks!

What's the suggestion for components?
>

I don't have any preference.

I wouldn't delete any "old" components. There is a feature request for
making JIRA issues archivable (just as versions), but that's not there yet
and they don't have immediate plans to do so. If the legacy components
really bother you, you might consider to rename them ("xxx_optimizer") so
they only show up at the end in drop-downs.


> These I'd want to keep:
>  - documentation
>  - testing
>  - build
> I guess these never were much of a source of confusion?
>
> These I don't think are a good fit any more - unless we want a very
> precise granularity:
>  - optimizer (Any Optimizer is deprecated)
>  - directory provider (Except the MasterDP, they are all trivial -
> we'd probably focus on the more general IndexManager nowadays)
>
> These I think are quite well defined, but I'm not sure if we're all on
> the same page:
>  - backend
>  - query
>  - serialization
>  - spatial
>  - mapping
>
> The "infinispan" is becoming tricky. It used to be just "those things
> in the /infinispan module", but nowadays we have many more
> interactions - not least some issues have been tagged with this with
> the (wrong IMO) meaning of "needed for Infinispan" as in blocking some
> issue in the Infinispan Query project.
>
> But remember that deleting unused components has consequences: affects
> a thousand closed issues. I'd rather accept that these will not be
> used much anymore.
> Adding new components also better be worth it, as you'd have to accept
> either of two evils:
>  A) you'll need to re-classify all existing issues
>  B) you'll have to accept that old issues won't show up classified
> nicely, in case you're searching for them or looking at per-component
> metrics over time..
>
> Sanne
>
> On 27 January 2015 at 22:08, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
> > Hi,
> >
> > On Tue, Jan 27, 2015 at 07:00:15PM +0100, Gunnar Morling wrote:
> >> There are many (new?) versions in Jira such as 3.1.next, 3.2.next etc.
> >>
> >> Are those all needed? 5.x makes sense to me, and maybe 4.5.next, but all
> >> the old ones? All these unreleased versions make it a bit unwieldy when
> >> assigning a fix version to an issue.
> >
> > +1 I also find it unwieldy, not only for assigning a fix version, but
> also when
> > "browsing" by version when on the project home page. I also find it
> sub-optimal
> > that if on the project summary the visible versions are 3.1.next,
> 3.2.next ... 4.1.next.
> >
> > This is partly related to the components discussion we had a while back.
> IMO
> > HSEARCH Jira needs a bit of a make-over.
> >
> > --Hardy
> >
> > _______________________________________________
> > 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 hardy at hibernate.org  Wed Jan 28 10:57:26 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 28 Jan 2015 16:57:26 +0100
Subject: [hibernate-dev] [HSEARCH] *.next Jira versions
In-Reply-To: <CADGJaX_ESkpEx50sFjbcLFTTp2hKha2FD051ZMzuVpuLf28GOA@mail.gmail.com>
References: <CADGJaX8og3CZtU5CYPLkHGcAv6mXAWX3AjBHKNTbkWLBZmSXeA@mail.gmail.com>
	<20150127220848.GB7137@Sarmakand-4.local>
	<CAFm4XO34o4Pi3tfzMDo28GJRgmNk93Fj9egRSv+H7M3kiT72Og@mail.gmail.com>
	<CADGJaX_ESkpEx50sFjbcLFTTp2hKha2FD051ZMzuVpuLf28GOA@mail.gmail.com>
Message-ID: <20150128155726.GD29864@Sarmakand-4.local>

Hi,

> I wouldn't delete any "old" components. There is a feature request for
> making JIRA issues archivable (just as versions), but that's not there yet
> and they don't have immediate plans to do so. If the legacy components
> really bother you, you might consider to rename them ("xxx_optimizer") so
> they only show up at the end in drop-downs.

What is the problem with the deleting old components. They are jsut categorizations 
of the issues and are not referenced anywhere (eg in the changelog). 
As long as the change logs stay intact I don't see a problem with deleting them
(just the component, not any issues assigned to them).

Prepending 'xxx' is one way of doing it, but I just hate how it looks.

--Hardy 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150128/4dc312e4/attachment.bin 

From hardy at hibernate.org  Wed Jan 28 11:09:39 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 28 Jan 2015 17:09:39 +0100
Subject: [hibernate-dev] [HSEARCH] *.next Jira versions
In-Reply-To: <CAFm4XO34o4Pi3tfzMDo28GJRgmNk93Fj9egRSv+H7M3kiT72Og@mail.gmail.com>
References: <CADGJaX8og3CZtU5CYPLkHGcAv6mXAWX3AjBHKNTbkWLBZmSXeA@mail.gmail.com>
	<20150127220848.GB7137@Sarmakand-4.local>
	<CAFm4XO34o4Pi3tfzMDo28GJRgmNk93Fj9egRSv+H7M3kiT72Og@mail.gmail.com>
Message-ID: <20150128160939.GE29864@Sarmakand-4.local>

Hi,

> What's the suggestion for components?
> 
> These I'd want to keep:
>  - documentation
>  - testing
>  - build
> I guess these never were much of a source of confusion?

Right, +1 for keeping these.
'tests' might belong here as well

> These I don't think are a good fit any more - unless we want a very
> precise granularity:
>  - optimizer (Any Optimizer is deprecated)
>  - directory provider (Except the MasterDP, they are all trivial -
> we'd probably focus on the more general IndexManager nowadays)

I would count analyzer to this list as well 

> These I think are quite well defined, but I'm not sure if we're all on
> the same page:
>  - backend

I am not so sure about this one. What is 'backend' in your opinion. For me it is just 'engine'. Where
is the line to backend?

>  - query

So does this encompass just the actual query writing part (aka DSL) or would you include things like QueryHits, LazyQueryState, etc

>  - serialization

Agreed, that one is obvious

>  - spatial

As above, where do you draw the line?

>  - mapping

This one, I am not sure what it means. Configuration? 

Personally, I'd rather have 'engine' as coarser component which includes things like
mappig, spatial, query. If you like to categorize further you can use tags.

> But remember that deleting unused components has consequences: affects
> a thousand closed issues.

Sure, but there is really no problem with that imo. Changing things like fix
version are a no go, but the component does not really matter.

> I'd rather accept that these will not be used much anymore.

-1 That's really not helping much. Also how do issue reporters know that we decided
not to use them anymore.

>  B) you'll have to accept that old issues won't show up classified
> nicely, in case you're searching for them or looking at per-component
> metrics over time..

Sure. Do you think that all is properly categorized right now? I doubt that.


--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150128/a26f2211/attachment.bin 

From sanne at hibernate.org  Wed Jan 28 12:40:16 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 28 Jan 2015 17:40:16 +0000
Subject: [hibernate-dev] [Search] Deprecating the @Key annotation
Message-ID: <CAFm4XO1w74aCa6UsQuYurF=t64M5J1O5WgHm-BpWGjMB2_dP9g@mail.gmail.com>

Gunnar made a nice patch[1] to simplify usage of parameterized,
cacheable FulltextFilters:
these no longer require the user to create a custom key to identify
the parameterset.

Documentation wise, we're struggling in finding a good explanation on
why someone might want to still use the @Key annotation - besides
backward compatibility.

It would be nice to simply remove the references to @Key in the
documentation, and avoid trying to explain when to choose between the
two alternatives.

This would imply to deprecate the annotation.. any objection?

Sanne

1 - https://github.com/hibernate/hibernate-search/pull/775

From hardy at hibernate.org  Thu Jan 29 03:42:31 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 29 Jan 2015 09:42:31 +0100
Subject: [hibernate-dev] [Search] Deprecating the @Key annotation
In-Reply-To: <CAFm4XO1w74aCa6UsQuYurF=t64M5J1O5WgHm-BpWGjMB2_dP9g@mail.gmail.com>
References: <CAFm4XO1w74aCa6UsQuYurF=t64M5J1O5WgHm-BpWGjMB2_dP9g@mail.gmail.com>
Message-ID: <20150129084231.GA31310@Sarmakand-4.local>

Hi,

> It would be nice to simply remove the references to @Key in the
> documentation, and avoid trying to explain when to choose between the
> two alternatives.
> 
> This would imply to deprecate the annotation.. any objection?

+1 for not mentioning it in the docs. Not sure whether this implies that 
we need to deprecate it as well, but I have no hard feelings if we do.

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150129/d0874da8/attachment-0001.bin 

From gunnar at hibernate.org  Thu Jan 29 03:49:48 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 29 Jan 2015 09:49:48 +0100
Subject: [hibernate-dev] [HSEARCH] Full-text query returning projection of
	one element
Message-ID: <CADGJaX95dtX+2b1VdmzNJo6d_Ow9y8eqZZX7F06GBfWhD-iftQ@mail.gmail.com>

Hi,

When doing a full-text query which projects exactly one column, e.g. like
so:

    List<?> list = fullTextSession.createFullTextQuery( query, MyEntity.
class )
        .setProjection( ProjectionConstants.ID )
        .list();

Then each list element will be a single-column array, containing the
projection result.

I'd rather have expected the list to contain the single column values
directly in this case. That's what HQL projection do and seems implied by
the docs of list().

Is it done differently in HSEARCH on purpose or should it be considered a
bug?

Thx,

--Gunnar

From sanne at hibernate.org  Thu Jan 29 07:31:35 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 29 Jan 2015 12:31:35 +0000
Subject: [hibernate-dev] [HSEARCH] Full-text query returning projection
 of one element
In-Reply-To: <CADGJaX95dtX+2b1VdmzNJo6d_Ow9y8eqZZX7F06GBfWhD-iftQ@mail.gmail.com>
References: <CADGJaX95dtX+2b1VdmzNJo6d_Ow9y8eqZZX7F06GBfWhD-iftQ@mail.gmail.com>
Message-ID: <CAFm4XO2tWwpGBzM7sd-73=S7v_7zbzsm61HO1-WJe1f3gxtX4w@mail.gmail.com>

I hadn't noticed that HQL projections would do that.
It seems useful indeed, but also quite irregular.. I'm not too
convinced, I guess I'd be happier if we could express the difference
on the method signature's return type.

I tend to agree that we should conform to the list() contract, but
this is unlikely to be an welcome change for existing users.
If you all agree it's an improvement, I'd schedule such an issue for 6?

Sanne

On 29 January 2015 at 08:49, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> When doing a full-text query which projects exactly one column, e.g. like
> so:
>
>     List<?> list = fullTextSession.createFullTextQuery( query, MyEntity.
> class )
>         .setProjection( ProjectionConstants.ID )
>         .list();
>
> Then each list element will be a single-column array, containing the
> projection result.
>
> I'd rather have expected the list to contain the single column values
> directly in this case. That's what HQL projection do and seems implied by
> the docs of list().
>
> Is it done differently in HSEARCH on purpose or should it be considered a
> bug?
>
> Thx,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From emmanuel at hibernate.org  Thu Jan 29 09:19:52 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 29 Jan 2015 15:19:52 +0100
Subject: [hibernate-dev] [HSEARCH] Faster way to get a query builder
Message-ID: <F0D5CC4C-3A3F-46C3-B7BE-E58FC3DD3B7D@hibernate.org>

https://gist.github.com/emmanuelbernard/3ca431a8fa58b69cf6c3 <https://gist.github.com/emmanuelbernard/3ca431a8fa58b69cf6c3>

//curent
QueryBuilder b = ftem.getSearchFactory().buildQueryBuilder().forEntity( Hike.class ).get();

//a bit shorter
QueryBuilder b = ftem.buildQueryForEntity( Hike.class ).get();

// shortest but no field overriding
QueryBuilder b = ftem.buildQueryForEntity( Hike.class );

Thoughts?

From gunnar at hibernate.org  Thu Jan 29 09:39:11 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 29 Jan 2015 15:39:11 +0100
Subject: [hibernate-dev] [HSEARCH] Full-text query returning projection
 of one element
In-Reply-To: <CAFm4XO2tWwpGBzM7sd-73=S7v_7zbzsm61HO1-WJe1f3gxtX4w@mail.gmail.com>
References: <CADGJaX95dtX+2b1VdmzNJo6d_Ow9y8eqZZX7F06GBfWhD-iftQ@mail.gmail.com>
	<CAFm4XO2tWwpGBzM7sd-73=S7v_7zbzsm61HO1-WJe1f3gxtX4w@mail.gmail.com>
Message-ID: <CADGJaX89BJiGGr6n9fG9hwjvUYJ8N1KhgLAOpUMfs=KkBff_+A@mail.gmail.com>

2015-01-29 13:31 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> I hadn't noticed that HQL projections would do that.
> It seems useful indeed, but also quite irregular.. I'm not too
> convinced, I guess I'd be happier if we could express the difference
> on the method signature's return type.
>
> I tend to agree that we should conform to the list() contract, but
> this is unlikely to be an welcome change for existing users.
> If you all agree it's an improvement, I'd schedule such an issue for 6?
>

Yes, it may come at the surprise of users relying on the current behavior.
Fixing it in HS 6 seems reasonable to me.

Sanne
>
> On 29 January 2015 at 08:49, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Hi,
> >
> > When doing a full-text query which projects exactly one column, e.g. like
> > so:
> >
> >     List<?> list = fullTextSession.createFullTextQuery( query, MyEntity.
> > class )
> >         .setProjection( ProjectionConstants.ID )
> >         .list();
> >
> > Then each list element will be a single-column array, containing the
> > projection result.
> >
> > I'd rather have expected the list to contain the single column values
> > directly in this case. That's what HQL projection do and seems implied by
> > the docs of list().
> >
> > Is it done differently in HSEARCH on purpose or should it be considered a
> > bug?
> >
> > Thx,
> >
> > --Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Thu Jan 29 09:54:17 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 29 Jan 2015 14:54:17 +0000
Subject: [hibernate-dev] [HSEARCH] Full-text query returning projection
 of one element
In-Reply-To: <CADGJaX89BJiGGr6n9fG9hwjvUYJ8N1KhgLAOpUMfs=KkBff_+A@mail.gmail.com>
References: <CADGJaX95dtX+2b1VdmzNJo6d_Ow9y8eqZZX7F06GBfWhD-iftQ@mail.gmail.com>
	<CAFm4XO2tWwpGBzM7sd-73=S7v_7zbzsm61HO1-WJe1f3gxtX4w@mail.gmail.com>
	<CADGJaX89BJiGGr6n9fG9hwjvUYJ8N1KhgLAOpUMfs=KkBff_+A@mail.gmail.com>
Message-ID: <CAFm4XO326+USUz3M2pTVrCSgB51nHh9o7b1DYx53B4_L_DB_Og@mail.gmail.com>

On 29 January 2015 at 14:39, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2015-01-29 13:31 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> I hadn't noticed that HQL projections would do that.
>> It seems useful indeed, but also quite irregular.. I'm not too
>> convinced, I guess I'd be happier if we could express the difference
>> on the method signature's return type.
>>
>> I tend to agree that we should conform to the list() contract, but
>> this is unlikely to be an welcome change for existing users.
>> If you all agree it's an improvement, I'd schedule such an issue for 6?
>
> Yes, it may come at the surprise of users relying on the current behavior.
> Fixing it in HS 6 seems reasonable to me.

https://hibernate.atlassian.net/browse/HSEARCH-1788

From gunnar at hibernate.org  Thu Jan 29 10:00:00 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 29 Jan 2015 16:00:00 +0100
Subject: [hibernate-dev] [HSEARCH] Faster way to get a query builder
In-Reply-To: <F0D5CC4C-3A3F-46C3-B7BE-E58FC3DD3B7D@hibernate.org>
References: <F0D5CC4C-3A3F-46C3-B7BE-E58FC3DD3B7D@hibernate.org>
Message-ID: <CADGJaX8KnKNbXoY_gVC=-HK15S3zOq-QktYQV6dtKWmc=QWWXQ@mail.gmail.com>

How would the last one be done? You would define overridesForField on
QueryBuilder and prohibit its usage after anything else on the builder has
been invoked?

Or, you could have two different methods:

    QueryBuilder getQueryBuilder(Class<?> entityType);
    QueryBuilderContext buildQueryBuilder(Class<?> entityType);

And then

    QueryBuilder qb = ftem. getQueryBuilder( Hike.class );
    QueryBuilder qb = ftem. buildQueryBuilder( Hike.class
).overridesForField( "organizer", "custom_analzer1" ).get();

Naming-wise, I find buildQueryForEntity() not totally right, as the method
doesn't build a query but a query builder. So I'd name it
getQueryBuilder(). Or getDefaultQueryBuilder() + getQueryBuilder().

--Gunnar






2015-01-29 15:19 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> https://gist.github.com/emmanuelbernard/3ca431a8fa58b69cf6c3 <
> https://gist.github.com/emmanuelbernard/3ca431a8fa58b69cf6c3>
>
> //curent
> QueryBuilder b = ftem.getSearchFactory().buildQueryBuilder().forEntity(
> Hike.class ).get();
>
> //a bit shorter
> QueryBuilder b = ftem.buildQueryForEntity( Hike.class ).get();
>
> // shortest but no field overriding
> QueryBuilder b = ftem.buildQueryForEntity( Hike.class );
>
> Thoughts?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Thu Jan 29 10:03:16 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 29 Jan 2015 15:03:16 +0000
Subject: [hibernate-dev] [HSEARCH] Faster way to get a query builder
In-Reply-To: <F0D5CC4C-3A3F-46C3-B7BE-E58FC3DD3B7D@hibernate.org>
References: <F0D5CC4C-3A3F-46C3-B7BE-E58FC3DD3B7D@hibernate.org>
Message-ID: <CAFm4XO3bqys7c=rgExR_bm6aXJZjr+UkEJo0xhy1seODw9SjcQ@mail.gmail.com>

On 29 January 2015 at 14:19, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> https://gist.github.com/emmanuelbernard/3ca431a8fa58b69cf6c3 <https://gist.github.com/emmanuelbernard/3ca431a8fa58b69cf6c3>
>
> //curent
> QueryBuilder b = ftem.getSearchFactory().buildQueryBuilder().forEntity( Hike.class ).get();
>
> //a bit shorter
> QueryBuilder b = ftem.buildQueryForEntity( Hike.class ).get();
>
> // shortest but no field overriding
> QueryBuilder b = ftem.buildQueryForEntity( Hike.class );

I like this third one the most, but I guess the method name you've
chosen is assuming that people will immediately chain more methods on
it, rather than reusing "b" ?
Just thinking that we generally suggest to reuse a QueryBuilder for
performance reasons. However I'm fine to take my perf-hat on a side
for sake of usability.

If we're into polishing this API, in sake of minimizing the times we
make API changes, I'd love a new proposal would also consider:

- How this would work with nice CDI helpers: inject a strongly typed builder?
- Be able to avoid repeating the target type twice. Now you have to
specify it once to get the right QueryBuilder, but then again you need
to specify the target types when wrapping the Lucene Query into a
FullTextQuery

I suspect this second point could be improved on by enclosing some
hidden metadata in the instance returned by the builder, or we add an
additional short-circuit in style of:

ftem.buildQueryForEntity( Hike.class ).all().getResultList();


--Sanne

From sanne at hibernate.org  Thu Jan 29 10:05:06 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 29 Jan 2015 15:05:06 +0000
Subject: [hibernate-dev] [HSEARCH] Faster way to get a query builder
In-Reply-To: <CADGJaX8KnKNbXoY_gVC=-HK15S3zOq-QktYQV6dtKWmc=QWWXQ@mail.gmail.com>
References: <F0D5CC4C-3A3F-46C3-B7BE-E58FC3DD3B7D@hibernate.org>
	<CADGJaX8KnKNbXoY_gVC=-HK15S3zOq-QktYQV6dtKWmc=QWWXQ@mail.gmail.com>
Message-ID: <CAFm4XO2HQrkt23HKCND3GcxF3R0hTf2CR=aoHtDcwKuTS-KSRg@mail.gmail.com>

On 29 January 2015 at 15:00, Gunnar Morling <gunnar at hibernate.org> wrote:
> How would the last one be done? You would define overridesForField on
> QueryBuilder and prohibit its usage after anything else on the builder has
> been invoked?
>
> Or, you could have two different methods:
>
>     QueryBuilder getQueryBuilder(Class<?> entityType);
>     QueryBuilderContext buildQueryBuilder(Class<?> entityType);
>
> And then
>
>     QueryBuilder qb = ftem. getQueryBuilder( Hike.class );
>     QueryBuilder qb = ftem. buildQueryBuilder( Hike.class
> ).overridesForField( "organizer", "custom_analzer1" ).get();
>
> Naming-wise, I find buildQueryForEntity() not totally right, as the method
> doesn't build a query but a query builder. So I'd name it
> getQueryBuilder(). Or getDefaultQueryBuilder() + getQueryBuilder().

I was puzzled by the name as well. As I've written in the
same-timestamp reply of mine, I'm assuming Emmanuel is thinking of a
full method chaining.

Sanne

From gunnar at hibernate.org  Thu Jan 29 11:25:11 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 29 Jan 2015 17:25:11 +0100
Subject: [hibernate-dev] [Search] Deprecating the @Key annotation
In-Reply-To: <20150129084231.GA31310@Sarmakand-4.local>
References: <CAFm4XO1w74aCa6UsQuYurF=t64M5J1O5WgHm-BpWGjMB2_dP9g@mail.gmail.com>
	<20150129084231.GA31310@Sarmakand-4.local>
Message-ID: <CADGJaX_KX3GRfWHOxcV4_omgD0eqcCLgaYxZm1CZ2hfqTwCuqQ@mail.gmail.com>

2015-01-29 9:42 GMT+01:00 Hardy Ferentschik <hardy at hibernate.org>:

> Hi,
>
> > It would be nice to simply remove the references to @Key in the
> > documentation, and avoid trying to explain when to choose between the
> > two alternatives.
> >
> > This would imply to deprecate the annotation.. any objection?
>
> +1 for not mentioning it in the docs. Not sure whether this implies that
> we need to deprecate it as well, but I have no hard feelings if we do.
>

I wouldn't like to remove it from the docs without deprecating it. It'd
appear as if a) we'd have forgotten to document this stuff or b) it's stuff
where no-one knows it's there and whether it works or not.

My vote goes for doc removal + deprecation in 5.1., followed by the removal
in 5.2 / 6 (depending on what the project guideline for this sort of change
is).


> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From m.schipperheyn at gmail.com  Thu Jan 29 14:27:11 2015
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Thu, 29 Jan 2015 17:27:11 -0200
Subject: [hibernate-dev] Some migration pains HSearch 5
Message-ID: <CAGvEgx5OS8_WAzJG-431KBayRNM1_6iXfivM4WSdA=LEFk8EOA@mail.gmail.com>

So, I've started migrating our production environment to HSearch 5 at long
last.

Some of the initial pains that may warrant some documentation love:

* @IndexedEmbedded basically inverts the default because before HSearch 5,
the default was essentially: @IndexedEmbedded(includeEmbeddedObjectId=true),
whereas now it's essentially: @IndexedEmbedded(includeEmbeddedObjectId=false).
Inverting defaults seems like a dangerous upgrade choice to me.

* I use a lot of indexedEmbedded(includePaths="id")  style includes.

public class MyClass{

@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Column(name="userId", nullable=false, insertable=false, updatable=false)
@DocumentId
public Long getId() {
   return id;
}

}

I always queried these as follows:

qb.keyword().onField("id").matching(myLongId).createQuery()

where the Long would implicitly converted to a String. and the term query
would be

+id:1

Now, it becomes a NumericRangeQuery based on the fact that I'm passing a
Long. But DocumentIds apparently are still strings by default. And this
query will fail to deliver results.

It makes most sense to me to convert DocumentId to NumericFields and adding
@NumericField to it seems to fix it, but I'm not sure if this could create
problems in other areas since this is the documentId. Anyway, this is
undocumented.

* The way to access a MutableSearchFactory has changed and is not
documented. This is more of an edge case

That's it for now.

Cheers,

Marc

From gbadner at redhat.com  Thu Jan 29 15:12:10 2015
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 29 Jan 2015 15:12:10 -0500 (EST)
Subject: [hibernate-dev] Hibernate ORM 4.2.18.Final released
Message-ID: <1832920321.3377603.1422562330729.JavaMail.zimbra@redhat.com>

I am having problems creating a weblog entry on in.relation.to. I will send another announcement with details when that is resolved.

Gail Badner
Red Hat, Hibernate ORM

From sanne at hibernate.org  Thu Jan 29 19:25:57 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 30 Jan 2015 00:25:57 +0000
Subject: [hibernate-dev] Some migration pains HSearch 5
In-Reply-To: <CAGvEgx5OS8_WAzJG-431KBayRNM1_6iXfivM4WSdA=LEFk8EOA@mail.gmail.com>
References: <CAGvEgx5OS8_WAzJG-431KBayRNM1_6iXfivM4WSdA=LEFk8EOA@mail.gmail.com>
Message-ID: <CAFm4XO0TpCsgR7Bt8T02fyX5db-e69rJSUmEY695+T84FUt9HQ@mail.gmail.com>

Thanks a lot Marc, that's very useful.
Some comments inline:

On 29 January 2015 at 19:27, Marc Schipperheyn <m.schipperheyn at gmail.com> wrote:
> So, I've started migrating our production environment to HSearch 5 at long
> last.
>
> Some of the initial pains that may warrant some documentation love:
>
> * @IndexedEmbedded basically inverts the default because before HSearch 5,
> the default was essentially: @IndexedEmbedded(includeEmbeddedObjectId=true),
> whereas now it's essentially: @IndexedEmbedded(includeEmbeddedObjectId=false).
> Inverting defaults seems like a dangerous upgrade choice to me.

Sorry we missed this in the Migration Guide. I've added it right now.

> * I use a lot of indexedEmbedded(includePaths="id")  style includes.
>
> public class MyClass{
>
> @Id
> @GeneratedValue(strategy = GenerationType.AUTO)
> @Column(name="userId", nullable=false, insertable=false, updatable=false)
> @DocumentId
> public Long getId() {
>    return id;
> }
>
> }
>
> I always queried these as follows:
>
> qb.keyword().onField("id").matching(myLongId).createQuery()
>
> where the Long would implicitly converted to a String. and the term query
> would be
>
> +id:1
>
> Now, it becomes a NumericRangeQuery based on the fact that I'm passing a
> Long. But DocumentIds apparently are still strings by default. And this
> query will fail to deliver results.
>
> It makes most sense to me to convert DocumentId to NumericFields and adding
> @NumericField to it seems to fix it, but I'm not sure if this could create
> problems in other areas since this is the documentId. Anyway, this is
> undocumented.

That's an ok workaround which should not cause other problems, but is
rather redundant so your resulting index is a bit larger than strictly
needed.

It's definitely unintended, I've opened a bug:
https://hibernate.atlassian.net/browse/HSEARCH-1791

>
> * The way to access a MutableSearchFactory has changed and is not
> documented. This is more of an edge case

Do you need any pointer to do that? Glad to help out, however we don't
consider it public API.
Could you describe what you need that for?

Thanks again!
Sanne

>
> That's it for now.
>
> Cheers,
>
> Marc
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Fri Jan 30 07:07:10 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 30 Jan 2015 12:07:10 +0000
Subject: [hibernate-dev] [Search] Deprecating the @Key annotation
In-Reply-To: <CADGJaX_KX3GRfWHOxcV4_omgD0eqcCLgaYxZm1CZ2hfqTwCuqQ@mail.gmail.com>
References: <CAFm4XO1w74aCa6UsQuYurF=t64M5J1O5WgHm-BpWGjMB2_dP9g@mail.gmail.com>
	<20150129084231.GA31310@Sarmakand-4.local>
	<CADGJaX_KX3GRfWHOxcV4_omgD0eqcCLgaYxZm1CZ2hfqTwCuqQ@mail.gmail.com>
Message-ID: <CAFm4XO1NpRnZn5ejwYYV6=N8QzC5YnQtbZMLnG08G=onwZZv6g@mail.gmail.com>

On 29 January 2015 at 16:25, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2015-01-29 9:42 GMT+01:00 Hardy Ferentschik <hardy at hibernate.org>:
>>
>> Hi,
>>
>> > It would be nice to simply remove the references to @Key in the
>> > documentation, and avoid trying to explain when to choose between the
>> > two alternatives.
>> >
>> > This would imply to deprecate the annotation.. any objection?
>>
>> +1 for not mentioning it in the docs. Not sure whether this implies that
>> we need to deprecate it as well, but I have no hard feelings if we do.
>
>
> I wouldn't like to remove it from the docs without deprecating it. It'd
> appear as if a) we'd have forgotten to document this stuff or b) it's stuff
> where no-one knows it's there and whether it works or not.
>
> My vote goes for doc removal + deprecation in 5.1., followed by the removal
> in 5.2 / 6 (depending on what the project guideline for this sort of change
> is).

+1, let's say we remove it in 6.. that can be adjusted if need be.

Sanne

>
>>
>> --Hardy
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From hardy at hibernate.org  Fri Jan 30 10:26:45 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 30 Jan 2015 16:26:45 +0100
Subject: [hibernate-dev] [Search] Native Java serialization support
Message-ID: <20150130152645.GB39262@Sarmakand-4.local>

Hi,

I would like to summarize a discussion we had on IRC to get some more feedback and come to 
a decision on how to move forward. 

I am currently in the need of extending our serialization support for the distributed Search
deployment scenarios. Basically we are serializing our different LuceneWork instances from slave
to master in this case. This includes things like Lucene's Document instances, which are part 
of add/update operations. Historically, this needs arose with Lucene dropping all serialization 
support for their classes, so we were forced to implement our custom serialization. To do so we
defined an SPI (org.hibernate.search.indexes.serialization.spi.*) and provided two implementations,
one based on native Java serialization and one based on Avro [1]. The two implementations are provided
as separate artifacts (the serialization/java and serialization/avro modules in our build) and
theoretically it should be possible to switch between them by exchanging jar files. 

I am saying theoretically, since I found out during my recent work, that the Java serialization module
is broken at several places. In its current state it would not work (I guess we never noticed since 
the default is Avro and we do not even document the possibility to change implementation. However, it also
shows that no one has even tried).

The question is, what do we do now? Do we want two implementations and should the Java serialization 
be fixed and then extended with the new functionality (btw, I need to serialize DocValues now) or is
it time to drop this module, reducing the amount of code we have to maintain and making it a bit 
easier to implement new serialization requirements. With dropping the module I mean to
remove the serialization/java module leaving everything else in place. So you still can write
your own serialization implementation, however, we provide no alternative to our preferred choice 
of Avro (which is afaik considerably faster than native Java serialization which was one of the 
driving factors of using it).

I think on IRC we already "kind of" agreed that we should drop native Java serialization. I
just wanted to put it out once more for everyone to comment/vote.

--Hardy

[1] http://avro.apache.org/ 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150130/a58485b8/attachment.bin 

From hardy at hibernate.org  Fri Jan 30 11:12:58 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 30 Jan 2015 17:12:58 +0100
Subject: [hibernate-dev] [Search]
 SearchNewEntityJmsMasterSlaveUsingInfinispanAs2ndCacheAndModulesIT failing
 on Mac
Message-ID: <20150130161258.GE39262@Sarmakand-4.local>

Hi,

for a couple days my master build of Search is broken. The integration test SearchNewEntityJmsMasterSlaveUsingInfinispanAs2ndCacheAndModulesIT
fails:

Failed tests:
SearchNewEntityJmsMasterSlaveUsingInfinispanAs2ndCacheAndModulesIT>SearchNewEntityJmsMasterSlave.searchNewMembersAfterSynchronizationOnSlave1:107->SearchNewEntityJmsMasterSlave.assertSearchResult:131 Unexpected number of results from search expected:<1> but was:<0>
SearchNewEntityJmsMasterSlaveUsingInfinispanAs2ndCacheAndModulesIT>SearchNewEntityJmsMasterSlave.searchNewMembersAfterSynchronizationOnSlave2:116->SearchNewEntityJmsMasterSlave.assertSearchResult:131 Unexpected number of results from search expected:<1> but was:<0>
SearchNewEntityJmsMasterSlaveUsingInfinispanAs2ndCacheAndModulesIT.secondLevelCacheShouldBeActive:50 Second level cache not enabled
  
A full build log is here [1]. Does anyone have an idea what it could be. AFAICT this test just extends SearchNewEntityJmsMasterSlave
and adds very little to it. Other sub-classes of this test pass. Then again, it is damn hard to tell what is actually supposed to
happen and why. I had a quick check of the server log files as well, but nothing which really sticks out, except maybe a JGroups 
warning about a buffer size. 

This is all related to the changes for HSEARCH-1324 [2]. 

As indicated in the subject, this seems to be a Mac problem (Linux works, don't know about Windows). My environment is:

Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
Maven home: /opt/java/maven
Java version: 1.7.0_45, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.10.1", arch: "x86_64", family: "mac"

Any ideas moving forward? Is it worth the effort to get to the bottom of this or is it a possibility to disable the 
test?

--Hardy

[1] https://gist.github.com/emmanuelbernard/853e712094365cee7205
[2] https://hibernate.atlassian.net/browse/HSEARCH-1324
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150130/35f888fb/attachment.bin 

From sfikes at redhat.com  Fri Jan 30 17:25:24 2015
From: sfikes at redhat.com (Stephen Fikes)
Date: Fri, 30 Jan 2015 16:25:24 -0600
Subject: [hibernate-dev] HHH-3555 Envers Enhancement
Message-ID: <1422656724.27518.16.camel@sfikes.localdomain>

We have an EAP 6/Hibernate 4 customer looking for an enhancement for
envers for which there is an existing "Closed - Won't Fix" Jira:

https://hibernate.atlassian.net/browse/HHH-3555

Before I create an RFE, wanted to make sure there was no obvious reason
I shouldn't begin the enhancement request process to look at adding this
in a future release. Also, do we have a sense of how much work it might
be should we decide to move forward.

Thanks!
Stephen


From steve at hibernate.org  Fri Jan 30 21:33:31 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 30 Jan 2015 20:33:31 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9sADREy6ohG9av04CVQsK0SrskmAUq_i0gHUPCOBRu5yA@mail.gmail.com>
References: <CAFdSV9u_pnGWUw_NuCKGbBBTteT6EPvfj-kZweVHQCNHUdWYnw@mail.gmail.com>
	<468EF275-F10B-4BB1-AAD2-70D67AEFC0C7@hibernate.org>
	<CAFdSV9u5YXMeDNdrLD++A-i8sY270BVxwiE4FJdm5pULHdOWyQ@mail.gmail.com>
	<CAFdSV9ttiEsjXsDA3X1a0re2Y_GejsKxTdQ+C=ZEQOzaGxd=iw@mail.gmail.com>
	<E1095FA3-D982-4AF4-AF49-3D713D9513B6@hibernate.org>
	<CAFdSV9vAptaR6VySYNA0y5uzsTMiZMgvJaE7FRp6YZdeNk5J1g@mail.gmail.com>
	<CAFdSV9sRVd2sJU2rRt0UEWUfPnQEMdiYxjhrANniRpEF-jfDQg@mail.gmail.com>
	<E3BFFD6B-1BEE-45A7-9263-E76ED261A899@redhat.com>
	<CAFdSV9sADREy6ohG9av04CVQsK0SrskmAUq_i0gHUPCOBRu5yA@mail.gmail.com>
Message-ID: <CAFdSV9sqsSL9tJc1GYin1uy9w30a=KjT6JMQKC85fViyZpx4DA@mail.gmail.com>

So here is what I have for implicit naming strategy, in simplified form:


   1. Table naming
      1. Entity primary table - @Table
      2. Join table - @JoinTable
      3. Collection table - @CollectionTable
      4. <secondary table are required to be explicitly named>
   2. Column naming
      1. basic attribute column
      2. entity discriminator column
      3. tenant id column
      4. @Any discriminator column
      5. @Any key column
      6. @JoinColumn
      7. @PrimaryKeyJoinColumn

Especially as far as column naming goes, can anyone see any I am missing?


On Fri, Jan 23, 2015 at 10:43 AM, Steve Ebersole <steve at hibernate.org>
wrote:

> Thanks Max for validating I am not going insane... at least in regards to
> this :)
>
> On Fri, Jan 23, 2015 at 10:19 AM, Max Rydahl Andersen <manderse at redhat.com
> > wrote:
>
>> On 23 Jan 2015, at 14:18, Steve Ebersole wrote:
>>
>>  [1] - I vaguely recall seeing that certain databases allow different
>>> length
>>> constraints for different types of identifiers (table name, versus column
>>> name, versus constrain name, ...).  Can anyone confirm that?
>>>
>>
>> I remember db2 have this fun.
>>
>> http://bytes.com/topic/db2/answers/183320-maximum-length-
>> table-names-colums-etc
>>
>> I believe Oracle has too but couldn't find evidence for it.
>>
>> /max
>> http://about.me/maxandersen
>>
>
>