From emmanuel at hibernate.org  Mon Feb  2 09:02:34 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 2 Feb 2015 15:02:34 +0100
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: <CF17279B-DFEC-4FF4-8D30-3FC40D5EF54D@hibernate.org>

+1 for 6

> On 29 Jan 2015, at 09: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  Mon Feb  2 09:04:14 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 2 Feb 2015 15:04:14 +0100
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: <5CC7A583-0D44-40C5-80FB-1FD88CFEE28C@hibernate.org>


> On 29 Jan 2015, at 16: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?

In my head that would have been a shorter version not allowing for field overriding. This is an advanced tool.



From emmanuel at hibernate.org  Mon Feb  2 09:22:57 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 2 Feb 2015 15:22:57 +0100
Subject: [hibernate-dev] [HSEARCH] Faster way to get a query builder
In-Reply-To: <CAFm4XO3bqys7c=rgExR_bm6aXJZjr+UkEJo0xhy1seODw9SjcQ@mail.gmail.com>
References: <F0D5CC4C-3A3F-46C3-B7BE-E58FC3DD3B7D@hibernate.org>
	<CAFm4XO3bqys7c=rgExR_bm6aXJZjr+UkEJo0xhy1seODw9SjcQ@mail.gmail.com>
Message-ID: <828AAD67-7B97-45DF-8AC3-6A97A91EAA83@hibernate.org>


> On 29 Jan 2015, at 16:03, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> 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();

That would be nice. I think there is a JIRA with the various experiments we did here - I cannot not find it. I think the result was that you could not easily do it without rewriting / copying the DSL API rather significantly.

PS: don?t worry to much about my proposed method names, I was not thinking to much about them.

From emmanuel at hibernate.org  Mon Feb  2 09:34:32 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 2 Feb 2015 15:34:32 +0100
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9sqsSL9tJc1GYin1uy9w30a=KjT6JMQKC85fViyZpx4DA@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>
	<CAFdSV9sqsSL9tJc1GYin1uy9w30a=KjT6JMQKC85fViyZpx4DA@mail.gmail.com>
Message-ID: <D911A508-D141-4E73-9FDF-3220B315F262@hibernate.org>

I think you?re missing things like @MapKeyColumn, @OrderColumn
Also, you might think about embedded objects. I think today the implicit contract received the qualified property names separated by dots e.g. ?homeAddress.street?. should that continue as it is or is there a need for abstraction?

Emmanuel


> On 31 Jan 2015, at 03:33, Steve Ebersole <steve at hibernate.org> wrote:
> 
> So here is what I have for implicit naming strategy, in simplified form:
> 
> Table naming
> Entity primary table - @Table
> Join table - @JoinTable
> Collection table - @CollectionTable
> <secondary table are required to be explicitly named>
> Column naming
> basic attribute column
> entity discriminator column
> tenant id column
> @Any discriminator column
> @Any key column
> @JoinColumn
> @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 <mailto: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 <mailto: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 <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 <http://about.me/maxandersen>
> 
> 


From steve at hibernate.org  Mon Feb  2 11:51:41 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 2 Feb 2015 10:51:41 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <D911A508-D141-4E73-9FDF-3220B315F262@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>
	<CAFdSV9vAptaR6VySYNA0y5uzsTMiZMgvJaE7FRp6YZdeNk5J1g@mail.gmail.com>
	<CAFdSV9sRVd2sJU2rRt0UEWUfPnQEMdiYxjhrANniRpEF-jfDQg@mail.gmail.com>
	<E3BFFD6B-1BEE-45A7-9263-E76ED261A899@redhat.com>
	<CAFdSV9sADREy6ohG9av04CVQsK0SrskmAUq_i0gHUPCOBRu5yA@mail.gmail.com>
	<CAFdSV9sqsSL9tJc1GYin1uy9w30a=KjT6JMQKC85fViyZpx4DA@mail.gmail.com>
	<D911A508-D141-4E73-9FDF-3220B315F262@hibernate.org>
Message-ID: <CAFdSV9u9_xL3-EOuwRRHRje0i0keAPV09rz1-sZSMRSiaX1UOg@mail.gmail.com>

On Mon, Feb 2, 2015 at 8:34 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

I think you?re missing things like @MapKeyColumn, @OrderColumn
>

So that's a good discussion.  These are things that have previously been
hard-coded defaults (at least on hbm side) and therefore had no specific
naming strategy hooks.  I'm all for being specific, so if everyone agrees
it is a good idea to add methods for stuff like this, I am fine with that.



> Also, you might think about embedded objects. I think today the implicit
> contract received the qualified property names separated by dots
> e.g. ?homeAddress.street?. should that continue as it is or is there a need
> for abstraction?
>

This is already handled well IMO.  The naming strategy is handed an
AttributePath, which is a "composite name" object.  E.g.
"homeAddress.street" is defined as:

new AttriubutePath().append( "homeAddress" ).append( "street" );

For completeness, there is also a paired AttributeRole for each
AttributePath which has the same "path", but which includes the base:

new AttributeRole( "com.acme."Company" ).append( "homeAddress" ).append(
"street" );

The naming strategy is only passed the AttributePath form.  They both give
access to each individual part of the path, as well as access to the "full
path" (e.g., ?homeAddress.street?).  So I think this is pretty well covered.



> Emmanuel
>
>
>
> On 31 Jan 2015, at 03:33, Steve Ebersole <steve at hibernate.org> wrote:
>
> 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
>>>
>>
>>
>
>

From emmanuel at hibernate.org  Mon Feb  2 12:28:53 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 2 Feb 2015 18:28:53 +0100
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9u9_xL3-EOuwRRHRje0i0keAPV09rz1-sZSMRSiaX1UOg@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>
	<CAFdSV9sqsSL9tJc1GYin1uy9w30a=KjT6JMQKC85fViyZpx4DA@mail.gmail.com>
	<D911A508-D141-4E73-9FDF-3220B315F262@hibernate.org>
	<CAFdSV9u9_xL3-EOuwRRHRje0i0keAPV09rz1-sZSMRSiaX1UOg@mail.gmail.com>
Message-ID: <57070315-9CB3-4CCF-84AB-5039172C7A18@hibernate.org>


> On 02 Feb 2015, at 17:51, Steve Ebersole <steve at hibernate.org> wrote:
> 
> On Mon, Feb 2, 2015 at 8:34 AM, Emmanuel Bernard <emmanuel at hibernate.org <mailto:emmanuel at hibernate.org>> wrote:
> 
> I think you?re missing things like @MapKeyColumn, @OrderColumn
>  
> So that's a good discussion.  These are things that have previously been hard-coded defaults (at least on hbm side) and therefore had no specific naming strategy hooks.  I'm all for being specific, so if everyone agrees it is a good idea to add methods for stuff like this, I am fine with that.

I know JPA has well defined values for these. I am not sure they match 100% the HBM version.

From emmanuel at hibernate.org  Mon Feb  2 12:39:46 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 2 Feb 2015 18:39:46 +0100
Subject: [hibernate-dev] [HSEARCH] Free form speed meeting
Message-ID: <09886B9A-F88E-4191-9598-06D5FD1030F8@hibernate.org>

This is a meeting to make sure everyone is on board with the same idea.
Need to be chewed and challenged :)

Meeting ended Mon Feb  2 16:53:46 2015 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
Minutes:        http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-02-02-16.10.html
Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-02-02-16.10.txt
Log:            http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-02-02-16.10.log.html

From steve at hibernate.org  Mon Feb  2 13:16:20 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 2 Feb 2015 12:16:20 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <57070315-9CB3-4CCF-84AB-5039172C7A18@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>
	<CAFdSV9vAptaR6VySYNA0y5uzsTMiZMgvJaE7FRp6YZdeNk5J1g@mail.gmail.com>
	<CAFdSV9sRVd2sJU2rRt0UEWUfPnQEMdiYxjhrANniRpEF-jfDQg@mail.gmail.com>
	<E3BFFD6B-1BEE-45A7-9263-E76ED261A899@redhat.com>
	<CAFdSV9sADREy6ohG9av04CVQsK0SrskmAUq_i0gHUPCOBRu5yA@mail.gmail.com>
	<CAFdSV9sqsSL9tJc1GYin1uy9w30a=KjT6JMQKC85fViyZpx4DA@mail.gmail.com>
	<D911A508-D141-4E73-9FDF-3220B315F262@hibernate.org>
	<CAFdSV9u9_xL3-EOuwRRHRje0i0keAPV09rz1-sZSMRSiaX1UOg@mail.gmail.com>
	<57070315-9CB3-4CCF-84AB-5039172C7A18@hibernate.org>
Message-ID: <CAFdSV9tfdBgnAdaPJq9vrGVtJmhHSQhPEO8WBT=0oE_JmYa1dw@mail.gmail.com>

They do not.  HBM, e.g., uses "idx" for map keys columns as well as
list/array index columns.  JPA says to use {attribute-name}_ORDER for list
index column.  Unless I missed it (which is completely possible in
annotation binding) we always use the JPA-defined default in those cases
rather than using any *implicit* naming hooks.

So that is really the question.  Do we want expand the breadth of what is
covered by implicit naming strategy in this new model?  I think its
reasonable.

On Mon, Feb 2, 2015 at 11:28 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

>
> On 02 Feb 2015, at 17:51, Steve Ebersole <steve at hibernate.org> wrote:
>
> On Mon, Feb 2, 2015 at 8:34 AM, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>
> I think you?re missing things like @MapKeyColumn, @OrderColumn
>>
>
> So that's a good discussion.  These are things that have previously been
> hard-coded defaults (at least on hbm side) and therefore had no specific
> naming strategy hooks.  I'm all for being specific, so if everyone agrees
> it is a good idea to add methods for stuff like this, I am fine with that.
>
>
> I know JPA has well defined values for these. I am not sure they match
> 100% the HBM version.
>

From hardy at hibernate.org  Mon Feb  2 14:15:31 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 2 Feb 2015 20:15:31 +0100
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9u9_xL3-EOuwRRHRje0i0keAPV09rz1-sZSMRSiaX1UOg@mail.gmail.com>
References: <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>
	<CAFdSV9sqsSL9tJc1GYin1uy9w30a=KjT6JMQKC85fViyZpx4DA@mail.gmail.com>
	<D911A508-D141-4E73-9FDF-3220B315F262@hibernate.org>
	<CAFdSV9u9_xL3-EOuwRRHRje0i0keAPV09rz1-sZSMRSiaX1UOg@mail.gmail.com>
Message-ID: <20150202191531.GC49146@Sarmakand-4.local>

Hi,

> > Also, you might think about embedded objects. I think today the implicit
> > contract received the qualified property names separated by dots
> > e.g. ?homeAddress.street?. should that continue as it is or is there a need
> > for abstraction?
> >
> 
> This is already handled well IMO.  The naming strategy is handed an
> AttributePath, which is a "composite name" object.  E.g.
> "homeAddress.street" is defined as:
> 
> new AttriubutePath().append( "homeAddress" ).append( "street" );
> 
> For completeness, there is also a paired AttributeRole for each
> AttributePath which has the same "path", but which includes the base:
> 
> new AttributeRole( "com.acme."Company" ).append( "homeAddress" ).append(
> "street" );

I like this. The dot notation and the required splitting of string is 
a very fiddly thing in the current code (and error prone). Switching to
a typed path is definitely a good idea.

--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/20150202/faa9bfb0/attachment.bin 

From emmanuel at hibernate.org  Mon Feb  2 16:13:03 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 2 Feb 2015 22:13:03 +0100
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9tfdBgnAdaPJq9vrGVtJmhHSQhPEO8WBT=0oE_JmYa1dw@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>
	<CAFdSV9sqsSL9tJc1GYin1uy9w30a=KjT6JMQKC85fViyZpx4DA@mail.gmail.com>
	<D911A508-D141-4E73-9FDF-3220B315F262@hibernate.org>
	<CAFdSV9u9_xL3-EOuwRRHRje0i0keAPV09rz1-sZSMRSiaX1UOg@mail.gmail.com>
	<57070315-9CB3-4CCF-84AB-5039172C7A18@hibernate.org>
	<CAFdSV9tfdBgnAdaPJq9vrGVtJmhHSQhPEO8WBT=0oE_JmYa1dw@mail.gmail.com>
Message-ID: <81CDE27F-838F-4E5E-AC78-AFA1623036CB@hibernate.org>

I?d say +1 for adding coverage of them in the implicit naming strategy.

> On 02 Feb 2015, at 19:16, Steve Ebersole <steve at hibernate.org> wrote:
> 
> They do not.  HBM, e.g., uses "idx" for map keys columns as well as list/array index columns.  JPA says to use {attribute-name}_ORDER for list index column.  Unless I missed it (which is completely possible in annotation binding) we always use the JPA-defined default in those cases rather than using any *implicit* naming hooks.
> 
> So that is really the question.  Do we want expand the breadth of what is covered by implicit naming strategy in this new model?  I think its reasonable.
> 
> On Mon, Feb 2, 2015 at 11:28 AM, Emmanuel Bernard <emmanuel at hibernate.org <mailto:emmanuel at hibernate.org>> wrote:
> 
>> On 02 Feb 2015, at 17:51, Steve Ebersole <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
>> 
>> On Mon, Feb 2, 2015 at 8:34 AM, Emmanuel Bernard <emmanuel at hibernate.org <mailto:emmanuel at hibernate.org>> wrote:
>> 
>> I think you?re missing things like @MapKeyColumn, @OrderColumn
>>  
>> So that's a good discussion.  These are things that have previously been hard-coded defaults (at least on hbm side) and therefore had no specific naming strategy hooks.  I'm all for being specific, so if everyone agrees it is a good idea to add methods for stuff like this, I am fine with that.
> 
> I know JPA has well defined values for these. I am not sure they match 100% the HBM version.
> 


From smarlow at redhat.com  Tue Feb  3 14:44:46 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 03 Feb 2015 14:44:46 -0500
Subject: [hibernate-dev] did hibernate.org crash?
In-Reply-To: <546CFEB6.3060704@redhat.com>
References: <546BE8EF.8030008@redhat.com>	<546BEEB2.7020700@redhat.com>	<CAFm4XO14NKxibiCmOcBWp068Cebko2QqjU54k-+kw2ifbHo81A@mail.gmail.com>	<546CBBB6.9050602@redhat.com>	<CADGJaX8Qdf=9Gkrv4hrBtSFJYq3EYaY1B=njHT4tc9nMPReCZw@mail.gmail.com>	<CAFdSV9tHA5=-wN9SgAoou7TF7oAQZiJCya_g4tvpD7nBNS1k1g@mail.gmail.com>	<546CC6C2.1080806@redhat.com>	<CAFdSV9v0QYMeSMHyG6ThgGRjLud4M-x9zFUnRwPirQ3Oege=Dw@mail.gmail.com>	<546CDE58.7050908@redhat.com>	<CAFdSV9uhigNPGpG0F-MqHpJwgDxjcEo+DEVuyP+3yWdVGV04yQ@mail.gmail.com>
	<546CFEB6.3060704@redhat.com>
Message-ID: <54D1252E.5070404@redhat.com>

Hibernate.org is down (seeing WildFly testsuite failures).

On 11/19/2014 03:33 PM, Scott Marlow wrote:
> On 11/19/2014 02:43 PM, Steve Ebersole wrote:
>> Ah, there is a difference in how core and hem are loading these.  This
>> is likely a bug, could you open a Jira?
>
> I created HHH-9511 for this.
>
>>
>> On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow <smarlow at redhat.com
>> <mailto:smarlow at redhat.com>> wrote:
>>
>>      http://pastebin.com/Baz7FRyf is an initial call stack into
>>      org.hibernate.service.__internal.JaxbProcessor.  I'm debugging on
>>      the Hibernate 4.3 branch and don't hit any break points in
>>      org.hibernate.cfg.__Configuration#entityResolver.  Perhaps I ended
>>      up in the wrong class, not sure.  I also set break points in
>>      org.hibernate.internal.util.__xml.DTDEntityResolver (don't see
>>      org.hibernate.internal.util.____xml.DTDEntityResolver).
>>
>>      The first exception that I see is http://pastebin.com/CYd0aNzE
>>
>>      On 11/19/2014 11:46 AM, Steve Ebersole wrote:
>>
>>          I should have been more complete :)
>>
>>          You can either set a breakpoint or crank up logging on that class.
>>          Breakpoint debugging is probably better as you could see the
>>          whole call
>>          stack.  These resolvers use a lot of delegation.  You could also
>>          look
>>          at org.hibernate.cfg.__Configuration#entityResolver to verify which
>>          specific resolver is being used.
>>
>>          On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow
>>          <smarlow at redhat.com <mailto:smarlow at redhat.com>
>>          <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>
>>               On 11/19/2014 11:26 AM, Steve Ebersole wrote:
>>
>>                   ORM has had local resolution of these DTDs forever.
>>          Something
>>                   is amiss
>>                   in your set up.  I just ran ORM tests and the DTDs are
>>          being
>>                   resolved
>>                   locally properly.
>>
>>
>>               Thanks for checking.
>>
>>
>>                   Can you make sure control is getting through our registered
>>                   EntityResolver?  Ultimately, this should be resolved
>>                   by org.hibernate.internal.util.____xml.DTDEntityResolver
>>
>>
>>               I'll give this a try.
>>
>>
>>
>>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From cdewolf at redhat.com  Tue Feb  3 15:19:07 2015
From: cdewolf at redhat.com (Carlo de Wolf)
Date: Tue, 03 Feb 2015 21:19:07 +0100
Subject: [hibernate-dev] did hibernate.org crash?
In-Reply-To: <54D1252E.5070404@redhat.com>
References: <546BE8EF.8030008@redhat.com>	<546BEEB2.7020700@redhat.com>	<CAFm4XO14NKxibiCmOcBWp068Cebko2QqjU54k-+kw2ifbHo81A@mail.gmail.com>	<546CBBB6.9050602@redhat.com>	<CADGJaX8Qdf=9Gkrv4hrBtSFJYq3EYaY1B=njHT4tc9nMPReCZw@mail.gmail.com>	<CAFdSV9tHA5=-wN9SgAoou7TF7oAQZiJCya_g4tvpD7nBNS1k1g@mail.gmail.com>	<546CC6C2.1080806@redhat.com>	<CAFdSV9v0QYMeSMHyG6ThgGRjLud4M-x9zFUnRwPirQ3Oege=Dw@mail.gmail.com>	<546CDE58.7050908@redhat.com>	<CAFdSV9uhigNPGpG0F-MqHpJwgDxjcEo+DEVuyP+3yWdVGV04yQ@mail.gmail.com>	<546CFEB6.3060704@redhat.com>
	<54D1252E.5070404@redhat.com>
Message-ID: <54D12D3B.20602@redhat.com>

Why and where do we have such a dependency?

Carlo

On 02/03/2015 08:44 PM, Scott Marlow wrote:
> Hibernate.org is down (seeing WildFly testsuite failures).
>
> On 11/19/2014 03:33 PM, Scott Marlow wrote:
>> On 11/19/2014 02:43 PM, Steve Ebersole wrote:
>>> Ah, there is a difference in how core and hem are loading these.  This
>>> is likely a bug, could you open a Jira?
>> I created HHH-9511 for this.
>>
>>> On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow <smarlow at redhat.com
>>> <mailto:smarlow at redhat.com>> wrote:
>>>
>>>       http://pastebin.com/Baz7FRyf is an initial call stack into
>>>       org.hibernate.service.__internal.JaxbProcessor.  I'm debugging on
>>>       the Hibernate 4.3 branch and don't hit any break points in
>>>       org.hibernate.cfg.__Configuration#entityResolver.  Perhaps I ended
>>>       up in the wrong class, not sure.  I also set break points in
>>>       org.hibernate.internal.util.__xml.DTDEntityResolver (don't see
>>>       org.hibernate.internal.util.____xml.DTDEntityResolver).
>>>
>>>       The first exception that I see is http://pastebin.com/CYd0aNzE
>>>
>>>       On 11/19/2014 11:46 AM, Steve Ebersole wrote:
>>>
>>>           I should have been more complete :)
>>>
>>>           You can either set a breakpoint or crank up logging on that class.
>>>           Breakpoint debugging is probably better as you could see the
>>>           whole call
>>>           stack.  These resolvers use a lot of delegation.  You could also
>>>           look
>>>           at org.hibernate.cfg.__Configuration#entityResolver to verify which
>>>           specific resolver is being used.
>>>
>>>           On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow
>>>           <smarlow at redhat.com <mailto:smarlow at redhat.com>
>>>           <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>>
>>>                On 11/19/2014 11:26 AM, Steve Ebersole wrote:
>>>
>>>                    ORM has had local resolution of these DTDs forever.
>>>           Something
>>>                    is amiss
>>>                    in your set up.  I just ran ORM tests and the DTDs are
>>>           being
>>>                    resolved
>>>                    locally properly.
>>>
>>>
>>>                Thanks for checking.
>>>
>>>
>>>                    Can you make sure control is getting through our registered
>>>                    EntityResolver?  Ultimately, this should be resolved
>>>                    by org.hibernate.internal.util.____xml.DTDEntityResolver
>>>
>>>
>>>                I'll give this a try.
>>>
>>>
>>>
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>


From steve at hibernate.org  Tue Feb  3 15:22:21 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 3 Feb 2015 14:22:21 -0600
Subject: [hibernate-dev] did hibernate.org crash?
In-Reply-To: <54D12D3B.20602@redhat.com>
References: <546BE8EF.8030008@redhat.com> <546BEEB2.7020700@redhat.com>
	<CAFm4XO14NKxibiCmOcBWp068Cebko2QqjU54k-+kw2ifbHo81A@mail.gmail.com>
	<546CBBB6.9050602@redhat.com>
	<CADGJaX8Qdf=9Gkrv4hrBtSFJYq3EYaY1B=njHT4tc9nMPReCZw@mail.gmail.com>
	<CAFdSV9tHA5=-wN9SgAoou7TF7oAQZiJCya_g4tvpD7nBNS1k1g@mail.gmail.com>
	<546CC6C2.1080806@redhat.com>
	<CAFdSV9v0QYMeSMHyG6ThgGRjLud4M-x9zFUnRwPirQ3Oege=Dw@mail.gmail.com>
	<546CDE58.7050908@redhat.com>
	<CAFdSV9uhigNPGpG0F-MqHpJwgDxjcEo+DEVuyP+3yWdVGV04yQ@mail.gmail.com>
	<546CFEB6.3060704@redhat.com> <54D1252E.5070404@redhat.com>
	<54D12D3B.20602@redhat.com>
Message-ID: <CAFdSV9ucLkZAZtqi1d=qb_K4z=mmpBa2xhtbh8aTXDjg2jR5Yw@mail.gmail.com>

Great question!  Scott?

On Tue, Feb 3, 2015 at 2:19 PM, Carlo de Wolf <cdewolf at redhat.com> wrote:

> Why and where do we have such a dependency?
>
> Carlo
>
>
> On 02/03/2015 08:44 PM, Scott Marlow wrote:
>
>> Hibernate.org is down (seeing WildFly testsuite failures).
>>
>> On 11/19/2014 03:33 PM, Scott Marlow wrote:
>>
>>> On 11/19/2014 02:43 PM, Steve Ebersole wrote:
>>>
>>>> Ah, there is a difference in how core and hem are loading these.  This
>>>> is likely a bug, could you open a Jira?
>>>>
>>> I created HHH-9511 for this.
>>>
>>>  On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow <smarlow at redhat.com
>>>> <mailto:smarlow at redhat.com>> wrote:
>>>>
>>>>       http://pastebin.com/Baz7FRyf is an initial call stack into
>>>>       org.hibernate.service.__internal.JaxbProcessor.  I'm debugging on
>>>>       the Hibernate 4.3 branch and don't hit any break points in
>>>>       org.hibernate.cfg.__Configuration#entityResolver.  Perhaps I
>>>> ended
>>>>       up in the wrong class, not sure.  I also set break points in
>>>>       org.hibernate.internal.util.__xml.DTDEntityResolver (don't see
>>>>       org.hibernate.internal.util.____xml.DTDEntityResolver).
>>>>
>>>>       The first exception that I see is http://pastebin.com/CYd0aNzE
>>>>
>>>>       On 11/19/2014 11:46 AM, Steve Ebersole wrote:
>>>>
>>>>           I should have been more complete :)
>>>>
>>>>           You can either set a breakpoint or crank up logging on that
>>>> class.
>>>>           Breakpoint debugging is probably better as you could see the
>>>>           whole call
>>>>           stack.  These resolvers use a lot of delegation.  You could
>>>> also
>>>>           look
>>>>           at org.hibernate.cfg.__Configuration#entityResolver to
>>>> verify which
>>>>           specific resolver is being used.
>>>>
>>>>           On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow
>>>>           <smarlow at redhat.com <mailto:smarlow at redhat.com>
>>>>           <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>>
>>>> wrote:
>>>>
>>>>                On 11/19/2014 11:26 AM, Steve Ebersole wrote:
>>>>
>>>>                    ORM has had local resolution of these DTDs forever.
>>>>           Something
>>>>                    is amiss
>>>>                    in your set up.  I just ran ORM tests and the DTDs
>>>> are
>>>>           being
>>>>                    resolved
>>>>                    locally properly.
>>>>
>>>>
>>>>                Thanks for checking.
>>>>
>>>>
>>>>                    Can you make sure control is getting through our
>>>> registered
>>>>                    EntityResolver?  Ultimately, this should be resolved
>>>>                    by org.hibernate.internal.util.__
>>>> __xml.DTDEntityResolver
>>>>
>>>>
>>>>                I'll give this a try.
>>>>
>>>>
>>>>
>>>>
>>>>  _______________________________________________
>>> 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 smarlow at redhat.com  Tue Feb  3 15:43:33 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 03 Feb 2015 15:43:33 -0500
Subject: [hibernate-dev] did hibernate.org crash?
In-Reply-To: <CAFdSV9ucLkZAZtqi1d=qb_K4z=mmpBa2xhtbh8aTXDjg2jR5Yw@mail.gmail.com>
References: <546BE8EF.8030008@redhat.com>	<546BEEB2.7020700@redhat.com>	<CAFm4XO14NKxibiCmOcBWp068Cebko2QqjU54k-+kw2ifbHo81A@mail.gmail.com>	<546CBBB6.9050602@redhat.com>	<CADGJaX8Qdf=9Gkrv4hrBtSFJYq3EYaY1B=njHT4tc9nMPReCZw@mail.gmail.com>	<CAFdSV9tHA5=-wN9SgAoou7TF7oAQZiJCya_g4tvpD7nBNS1k1g@mail.gmail.com>	<546CC6C2.1080806@redhat.com>	<CAFdSV9v0QYMeSMHyG6ThgGRjLud4M-x9zFUnRwPirQ3Oege=Dw@mail.gmail.com>	<546CDE58.7050908@redhat.com>	<CAFdSV9uhigNPGpG0F-MqHpJwgDxjcEo+DEVuyP+3yWdVGV04yQ@mail.gmail.com>	<546CFEB6.3060704@redhat.com>	<54D1252E.5070404@redhat.com>	<54D12D3B.20602@redhat.com>
	<CAFdSV9ucLkZAZtqi1d=qb_K4z=mmpBa2xhtbh8aTXDjg2jR5Yw@mail.gmail.com>
Message-ID: <54D132F5.5090308@redhat.com>

HHH-9511 shows the call stack (should answer where/why).

On 02/03/2015 03:22 PM, Steve Ebersole wrote:
> Great question!  Scott?
>
> On Tue, Feb 3, 2015 at 2:19 PM, Carlo de Wolf <cdewolf at redhat.com
> <mailto:cdewolf at redhat.com>> wrote:
>
>     Why and where do we have such a dependency?
>
>     Carlo
>
>
>     On 02/03/2015 08:44 PM, Scott Marlow wrote:
>
>         Hibernate.org is down (seeing WildFly testsuite failures).
>
>         On 11/19/2014 03:33 PM, Scott Marlow wrote:
>
>             On 11/19/2014 02:43 PM, Steve Ebersole wrote:
>
>                 Ah, there is a difference in how core and hem are
>                 loading these.  This
>                 is likely a bug, could you open a Jira?
>
>             I created HHH-9511 for this.
>
>                 On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow
>                 <smarlow at redhat.com <mailto:smarlow at redhat.com>
>                 <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>>
>                 wrote:
>
>                 http://pastebin.com/Baz7FRyf is an initial call stack into
>
>                 org.hibernate.service.____internal.JaxbProcessor.  I'm
>                 debugging on
>                        the Hibernate 4.3 branch and don't hit any break
>                 points in
>
>                 org.hibernate.cfg.____Configuration#entityResolver.
>                 Perhaps I ended
>                        up in the wrong class, not sure.  I also set
>                 break points in
>
>                 org.hibernate.internal.util.____xml.DTDEntityResolver
>                 (don't see
>
>                 org.hibernate.internal.util.______xml.DTDEntityResolver).
>
>                        The first exception that I see is
>                 http://pastebin.com/CYd0aNzE
>
>                        On 11/19/2014 11:46 AM, Steve Ebersole wrote:
>
>                            I should have been more complete :)
>
>                            You can either set a breakpoint or crank up
>                 logging on that class.
>                            Breakpoint debugging is probably better as
>                 you could see the
>                            whole call
>                            stack.  These resolvers use a lot of
>                 delegation.  You could also
>                            look
>                            at
>                 org.hibernate.cfg.____Configuration#entityResolver to
>                 verify which
>                            specific resolver is being used.
>
>                            On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow
>                            <smarlow at redhat.com
>                 <mailto:smarlow at redhat.com> <mailto:smarlow at redhat.com
>                 <mailto:smarlow at redhat.com>>
>                            <mailto:smarlow at redhat.com
>                 <mailto:smarlow at redhat.com> <mailto:smarlow at redhat.com
>                 <mailto:smarlow at redhat.com>>>> wrote:
>
>                                 On 11/19/2014 11:26 AM, Steve Ebersole
>                 wrote:
>
>                                     ORM has had local resolution of
>                 these DTDs forever.
>                            Something
>                                     is amiss
>                                     in your set up.  I just ran ORM
>                 tests and the DTDs are
>                            being
>                                     resolved
>                                     locally properly.
>
>
>                                 Thanks for checking.
>
>
>                                     Can you make sure control is getting
>                 through our registered
>                                     EntityResolver?  Ultimately, this
>                 should be resolved
>                                     by
>                 org.hibernate.internal.util.______xml.DTDEntityResolver
>
>
>                                 I'll give this a try.
>
>
>
>
>             _________________________________________________
>             hibernate-dev mailing list
>             hibernate-dev at lists.jboss.org
>             <mailto:hibernate-dev at lists.jboss.org>
>             https://lists.jboss.org/__mailman/listinfo/hibernate-dev
>             <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>         _________________________________________________
>         hibernate-dev mailing list
>         hibernate-dev at lists.jboss.org <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 Feb  4 04:15:25 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 4 Feb 2015 10:15:25 +0100
Subject: [hibernate-dev] did hibernate.org crash?
In-Reply-To: <54D1252E.5070404@redhat.com>
References: <546BE8EF.8030008@redhat.com> <546BEEB2.7020700@redhat.com>
	<CAFm4XO14NKxibiCmOcBWp068Cebko2QqjU54k-+kw2ifbHo81A@mail.gmail.com>
	<546CBBB6.9050602@redhat.com>
	<CADGJaX8Qdf=9Gkrv4hrBtSFJYq3EYaY1B=njHT4tc9nMPReCZw@mail.gmail.com>
	<CAFdSV9tHA5=-wN9SgAoou7TF7oAQZiJCya_g4tvpD7nBNS1k1g@mail.gmail.com>
	<546CC6C2.1080806@redhat.com>
	<CAFdSV9v0QYMeSMHyG6ThgGRjLud4M-x9zFUnRwPirQ3Oege=Dw@mail.gmail.com>
	<546CDE58.7050908@redhat.com>
	<CAFdSV9uhigNPGpG0F-MqHpJwgDxjcEo+DEVuyP+3yWdVGV04yQ@mail.gmail.com>
	<546CFEB6.3060704@redhat.com> <54D1252E.5070404@redhat.com>
Message-ID: <55B339BA-64E0-4C1A-9C76-9B7635B36CA8@hibernate.org>

For info hibernate.org <http://hibernate.org/> seems to be ?down? *if* you are behind the Red Hat VPN (I can still access though). So that?s probably some IT filtering going on because we are some kind of subversive site. That makes sense :)

Anyways, fixing the dtd resolution to go local only remains important.

> On 03 Feb 2015, at 20:44, Scott Marlow <smarlow at redhat.com> wrote:
> 
> Hibernate.org is down (seeing WildFly testsuite failures).
> 
> On 11/19/2014 03:33 PM, Scott Marlow wrote:
>> On 11/19/2014 02:43 PM, Steve Ebersole wrote:
>>> Ah, there is a difference in how core and hem are loading these.  This
>>> is likely a bug, could you open a Jira?
>> 
>> I created HHH-9511 for this.
>> 
>>> 
>>> On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow <smarlow at redhat.com
>>> <mailto:smarlow at redhat.com>> wrote:
>>> 
>>>     http://pastebin.com/Baz7FRyf is an initial call stack into
>>>     org.hibernate.service.__internal.JaxbProcessor.  I'm debugging on
>>>     the Hibernate 4.3 branch and don't hit any break points in
>>>     org.hibernate.cfg.__Configuration#entityResolver.  Perhaps I ended
>>>     up in the wrong class, not sure.  I also set break points in
>>>     org.hibernate.internal.util.__xml.DTDEntityResolver (don't see
>>>     org.hibernate.internal.util.____xml.DTDEntityResolver).
>>> 
>>>     The first exception that I see is http://pastebin.com/CYd0aNzE
>>> 
>>>     On 11/19/2014 11:46 AM, Steve Ebersole wrote:
>>> 
>>>         I should have been more complete :)
>>> 
>>>         You can either set a breakpoint or crank up logging on that class.
>>>         Breakpoint debugging is probably better as you could see the
>>>         whole call
>>>         stack.  These resolvers use a lot of delegation.  You could also
>>>         look
>>>         at org.hibernate.cfg.__Configuration#entityResolver to verify which
>>>         specific resolver is being used.
>>> 
>>>         On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow
>>>         <smarlow at redhat.com <mailto:smarlow at redhat.com>
>>>         <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>> 
>>>              On 11/19/2014 11:26 AM, Steve Ebersole wrote:
>>> 
>>>                  ORM has had local resolution of these DTDs forever.
>>>         Something
>>>                  is amiss
>>>                  in your set up.  I just ran ORM tests and the DTDs are
>>>         being
>>>                  resolved
>>>                  locally properly.
>>> 
>>> 
>>>              Thanks for checking.
>>> 
>>> 
>>>                  Can you make sure control is getting through our registered
>>>                  EntityResolver?  Ultimately, this should be resolved
>>>                  by org.hibernate.internal.util.____xml.DTDEntityResolver
>>> 
>>> 
>>>              I'll give this a try.
>>> 
>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> 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 nicolas.helleringer at gmail.com  Wed Feb  4 05:29:29 2015
From: nicolas.helleringer at gmail.com (Nicolas Helleringer)
Date: Wed, 4 Feb 2015 11:29:29 +0100
Subject: [hibernate-dev] did hibernate.org crash?
In-Reply-To: <55B339BA-64E0-4C1A-9C76-9B7635B36CA8@hibernate.org>
References: <546BE8EF.8030008@redhat.com> <546BEEB2.7020700@redhat.com>
	<CAFm4XO14NKxibiCmOcBWp068Cebko2QqjU54k-+kw2ifbHo81A@mail.gmail.com>
	<546CBBB6.9050602@redhat.com>
	<CADGJaX8Qdf=9Gkrv4hrBtSFJYq3EYaY1B=njHT4tc9nMPReCZw@mail.gmail.com>
	<CAFdSV9tHA5=-wN9SgAoou7TF7oAQZiJCya_g4tvpD7nBNS1k1g@mail.gmail.com>
	<546CC6C2.1080806@redhat.com>
	<CAFdSV9v0QYMeSMHyG6ThgGRjLud4M-x9zFUnRwPirQ3Oege=Dw@mail.gmail.com>
	<546CDE58.7050908@redhat.com>
	<CAFdSV9uhigNPGpG0F-MqHpJwgDxjcEo+DEVuyP+3yWdVGV04yQ@mail.gmail.com>
	<546CFEB6.3060704@redhat.com> <54D1252E.5070404@redhat.com>
	<55B339BA-64E0-4C1A-9C76-9B7635B36CA8@hibernate.org>
Message-ID: <CAPkKb_UqQS4ni2rmJ0ryysH6aUxpLsOMAk3kD=2bBMhfCKOyvA@mail.gmail.com>

Hi,

I am NOT in Red Hat VPN/Network and I do confirm the site is up.

Niko

2015-02-04 10:15 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> For info hibernate.org <http://hibernate.org/> seems to be ?down? *if* you are behind the Red Hat VPN (I can still access though). So that?s probably some IT filtering going on because we are some kind of subversive site. That makes sense :)
>
> Anyways, fixing the dtd resolution to go local only remains important.
>
>> On 03 Feb 2015, at 20:44, Scott Marlow <smarlow at redhat.com> wrote:
>>
>> Hibernate.org is down (seeing WildFly testsuite failures).
>>
>> On 11/19/2014 03:33 PM, Scott Marlow wrote:
>>> On 11/19/2014 02:43 PM, Steve Ebersole wrote:
>>>> Ah, there is a difference in how core and hem are loading these.  This
>>>> is likely a bug, could you open a Jira?
>>>
>>> I created HHH-9511 for this.
>>>
>>>>
>>>> On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow <smarlow at redhat.com
>>>> <mailto:smarlow at redhat.com>> wrote:
>>>>
>>>>     http://pastebin.com/Baz7FRyf is an initial call stack into
>>>>     org.hibernate.service.__internal.JaxbProcessor.  I'm debugging on
>>>>     the Hibernate 4.3 branch and don't hit any break points in
>>>>     org.hibernate.cfg.__Configuration#entityResolver.  Perhaps I ended
>>>>     up in the wrong class, not sure.  I also set break points in
>>>>     org.hibernate.internal.util.__xml.DTDEntityResolver (don't see
>>>>     org.hibernate.internal.util.____xml.DTDEntityResolver).
>>>>
>>>>     The first exception that I see is http://pastebin.com/CYd0aNzE
>>>>
>>>>     On 11/19/2014 11:46 AM, Steve Ebersole wrote:
>>>>
>>>>         I should have been more complete :)
>>>>
>>>>         You can either set a breakpoint or crank up logging on that class.
>>>>         Breakpoint debugging is probably better as you could see the
>>>>         whole call
>>>>         stack.  These resolvers use a lot of delegation.  You could also
>>>>         look
>>>>         at org.hibernate.cfg.__Configuration#entityResolver to verify which
>>>>         specific resolver is being used.
>>>>
>>>>         On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow
>>>>         <smarlow at redhat.com <mailto:smarlow at redhat.com>
>>>>         <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>>>>
>>>>              On 11/19/2014 11:26 AM, Steve Ebersole wrote:
>>>>
>>>>                  ORM has had local resolution of these DTDs forever.
>>>>         Something
>>>>                  is amiss
>>>>                  in your set up.  I just ran ORM tests and the DTDs are
>>>>         being
>>>>                  resolved
>>>>                  locally properly.
>>>>
>>>>
>>>>              Thanks for checking.
>>>>
>>>>
>>>>                  Can you make sure control is getting through our registered
>>>>                  EntityResolver?  Ultimately, this should be resolved
>>>>                  by org.hibernate.internal.util.____xml.DTDEntityResolver
>>>>
>>>>
>>>>              I'll give this a try.
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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 m.schipperheyn at gmail.com  Wed Feb  4 12:29:53 2015
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Wed, 4 Feb 2015 15:29:53 -0200
Subject: [hibernate-dev] autosuggest
Message-ID: <CAGvEgx73BVykS2xiQ5WAL2CNpWpiWNEEJ90u=Zh-c1d7vjk+fA@mail.gmail.com>

Lucene 4 has some great improvements in autosuggest/autocomplete,
e.g.AnalyzingInfixSuggester.
GroupingSearch and JoinUtil are other nice ones.

It would be interesting to see blog writeups on leveraging these new
features through HSearch.

Joins should imho even be considered as candidates for inclusion into the
querybuilder. Grouping might also be considered as a kind of projection
perhaps.

From m.schipperheyn at gmail.com  Wed Feb  4 13:04:02 2015
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Wed, 4 Feb 2015 16:04:02 -0200
Subject: [hibernate-dev] @IndexedEmbedded ids numeric in stead of Strings
Message-ID: <CAGvEgx58g4NeGzh2EGcVpHTruG_p_jKwbYVubVfDEPYRibDVGw@mail.gmail.com>

I'm noticing that on @IndexedEmbedded HSearch 5, an id reference is indexed
as a numeric field, when, that same id is indexed as a string being a
@DocumentId. I had some seemingly inconsistent behaviour in my tests so now
I'm not so sure what is the intended behaviour?

So,

@Entity
@Indexed
public class Post{

   @Id
   @DocumentId
    private Long id;

    @ManyToOne
    @IndexedEmbedded(includePaths={"id"})
    private Post parent;
}

id would be a string
parent.id would be numeric

is this intended? I guess I can see the logic but it seems a little
inconsistent and something that should be mentioned in the migration guide.

Cheers,
Marc

From m.schipperheyn at gmail.com  Wed Feb  4 13:34:28 2015
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Wed, 4 Feb 2015 16:34:28 -0200
Subject: [hibernate-dev] @IndexedEmbedded ids numeric in stead of Strings
In-Reply-To: <CAGvEgx58g4NeGzh2EGcVpHTruG_p_jKwbYVubVfDEPYRibDVGw@mail.gmail.com>
References: <CAGvEgx58g4NeGzh2EGcVpHTruG_p_jKwbYVubVfDEPYRibDVGw@mail.gmail.com>
Message-ID: <CAGvEgx67HKquh-jKM7wm463rEyVZdDF8JKZNPx_Q6cFmB5sn-g@mail.gmail.com>

Yeah, I'm now seeing that parent.id is not actually stored as numeric.
However, when I project on it, it's returned as a Long for some reason.
Hmm, confusing.

From hardy at hibernate.org  Wed Feb  4 17:39:27 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 4 Feb 2015 23:39:27 +0100
Subject: [hibernate-dev] @IndexedEmbedded ids numeric in stead of Strings
In-Reply-To: <CAGvEgx67HKquh-jKM7wm463rEyVZdDF8JKZNPx_Q6cFmB5sn-g@mail.gmail.com>
References: <CAGvEgx58g4NeGzh2EGcVpHTruG_p_jKwbYVubVfDEPYRibDVGw@mail.gmail.com>
	<CAGvEgx67HKquh-jKM7wm463rEyVZdDF8JKZNPx_Q6cFmB5sn-g@mail.gmail.com>
Message-ID: <20150204223927.GA74009@Sarmakand-4.local>

On Wed, Feb 04, 2015 at 04:34:28PM -0200, Marc Schipperheyn wrote:
> Yeah, I'm now seeing that parent.id is not actually stored as numeric.
> However, when I project on it, it's returned as a Long for some reason.
> Hmm, confusing.

I am also seeing some strange behaviour using projections when playing with
some tests for HSEARCH-1791. I am taking a closer look at 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/20150204/74127849/attachment.bin 

From sanne at hibernate.org  Thu Feb  5 16:30:48 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 5 Feb 2015 21:30:48 +0000
Subject: [hibernate-dev] @IndexedEmbedded ids numeric in stead of Strings
In-Reply-To: <20150204223927.GA74009@Sarmakand-4.local>
References: <CAGvEgx58g4NeGzh2EGcVpHTruG_p_jKwbYVubVfDEPYRibDVGw@mail.gmail.com>
	<CAGvEgx67HKquh-jKM7wm463rEyVZdDF8JKZNPx_Q6cFmB5sn-g@mail.gmail.com>
	<20150204223927.GA74009@Sarmakand-4.local>
Message-ID: <CAFm4XO2Qd98dHm_3iguaxj0GLh4nP8k9oFnDrma_-s_+1jcKfA@mail.gmail.com>

On 4 February 2015 at 22:39, Hardy Ferentschik <hardy at hibernate.org> wrote:
> On Wed, Feb 04, 2015 at 04:34:28PM -0200, Marc Schipperheyn wrote:
>> Yeah, I'm now seeing that parent.id is not actually stored as numeric.
>> However, when I project on it, it's returned as a Long for some reason.
>> Hmm, confusing.

Hi Marc,

all "id" fields receive special treatment, for example the @DocumentId
is automatic, and we never encode these as Numeric. This should allow
us to take advantage of some of the neat stuff of Lucene 4, like joins
or DocValue on ids. With a NumericField these are not possible, but
you can definitely add the same field as a @NumericField as well.
That's the same reason which you'd use the very specific
IndexedEmbedded(includeEmbeddedObjectId) boolean attribute, rather
than using the "paths" attribute: ids are a special case. Given the
confusion, I'm wondering if we shouldn't hide them completely, as in
prohibit projection on the special field, as disallow queries to
target "our" id field. We could still allow users to add a custom
field as usual, and target that... that would maybe be slightly easier
to use, but I fear it could be more confusing as in some advanced
cases we wouldn't be able to fully hide this internal field. Not
least, it would be bloating your index with some duplication.

That's just the background. In practice though, Projection results are
independent on how stuff gets encoded: a query will always return the
type you're using in your class.
So in your specific example it's returning a Long because your field
type is a Long. If it's using a NumericField to encode that, that's an
unrelated concern.

Sorry for the confusion, suggestions to improve on this are very welcome.

Sanne

>
> I am also seeing some strange behaviour using projections when playing with
> some tests for HSEARCH-1791. I am taking a closer look at this...
>
> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Thu Feb  5 16:38:52 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 5 Feb 2015 21:38:52 +0000
Subject: [hibernate-dev] autosuggest
In-Reply-To: <CAGvEgx73BVykS2xiQ5WAL2CNpWpiWNEEJ90u=Zh-c1d7vjk+fA@mail.gmail.com>
References: <CAGvEgx73BVykS2xiQ5WAL2CNpWpiWNEEJ90u=Zh-c1d7vjk+fA@mail.gmail.com>
Message-ID: <CAFm4XO0PwCrNFbZafzZ0emfZnU05E7eJt80urs41-cbNULpr7Q@mail.gmail.com>

On 4 February 2015 at 17:29, Marc Schipperheyn <m.schipperheyn at gmail.com> wrote:
> Lucene 4 has some great improvements in autosuggest/autocomplete,
> e.g.AnalyzingInfixSuggester.
> GroupingSearch and JoinUtil are other nice ones.
>
> It would be interesting to see blog writeups on leveraging these new
> features through HSearch.

Good point. We'd need to do some research first though :-/
Rather than blogging how to bypass the Search API I'd prefer to create
an easy to use API first.

> Joins should imho even be considered as candidates for inclusion into the
> querybuilder. Grouping might also be considered as a kind of projection
> perhaps.

+1 Joins are high on my wishlist too, but not on the top yet. Would
you like to sketch a proposal patch?
HSEARCH-1237

Sanne

From sanne at hibernate.org  Mon Feb  9 08:44:34 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 9 Feb 2015 13:44:34 +0000
Subject: [hibernate-dev] Updated JDKs on ci.hibernate.org
Message-ID: <CAFm4XO3oqWtsWjsa-OP9bE9KgmOWWKM5BhzsgWa6_=8OjSJxzQ@mail.gmail.com>

Hi all,
I just downloaded these versions of the OpenJDK and replaced the
existing ones on ci.hibernate.org:

jdk-7u80-ea-bin-b05-linux-x64-20_jan_2015.tar.gz
jdk-8u40-ea-bin-b23-linux-x64-27_jan_2015.tar.gz
jdk-9-ea-bin-b49-linux-x64-04_feb_2015.tar.gz

I now triggered several builds of various JDK/project combinations. I
don't expect any regression, but in case there are broken builds,
that's an additional reason to consider.

Thanks,
Sanne

From sanne at hibernate.org  Mon Feb  9 09:12:50 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 9 Feb 2015 14:12:50 +0000
Subject: [hibernate-dev] Updated JDKs on ci.hibernate.org
In-Reply-To: <CAFm4XO3oqWtsWjsa-OP9bE9KgmOWWKM5BhzsgWa6_=8OjSJxzQ@mail.gmail.com>
References: <CAFm4XO3oqWtsWjsa-OP9bE9KgmOWWKM5BhzsgWa6_=8OjSJxzQ@mail.gmail.com>
Message-ID: <CAFm4XO15SR2sCRvpf0+QtotkccrsUVtJfiqtFfqn-kTuLmV+1w@mail.gmail.com>

All tests relating to Lucene which use the FSDirectory are failing
because of an issue the Lucene team already reported.
That obviously "kills" the Hibernate Search testsuite, but also
created a couple of failures with Hibernate OGM.

Sorry for the noise, I'll disable both until we get to know what fix
will be needed.

It's a controversial issue, as the Lucene was taking advantage of a
not-explicitly documented semantic of NIO to flush all files of a
directory in a single atomic operation, but requesting a flush on the
File instance which represents the Directory.
The JDK now disallows this; I'm not sure yet if Lucene will need to
find an alternative flushing strategy or rather if the OpenJDK team
will reconsider.

Sanne

On 9 February 2015 at 13:44, Sanne Grinovero <sanne at hibernate.org> wrote:
> Hi all,
> I just downloaded these versions of the OpenJDK and replaced the
> existing ones on ci.hibernate.org:
>
> jdk-7u80-ea-bin-b05-linux-x64-20_jan_2015.tar.gz
> jdk-8u40-ea-bin-b23-linux-x64-27_jan_2015.tar.gz
> jdk-9-ea-bin-b49-linux-x64-04_feb_2015.tar.gz
>
> I now triggered several builds of various JDK/project combinations. I
> don't expect any regression, but in case there are broken builds,
> that's an additional reason to consider.
>
> Thanks,
> Sanne

From sanne at hibernate.org  Mon Feb  9 09:33:10 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 9 Feb 2015 14:33:10 +0000
Subject: [hibernate-dev] Updated JDKs on ci.hibernate.org
In-Reply-To: <CAFm4XO15SR2sCRvpf0+QtotkccrsUVtJfiqtFfqn-kTuLmV+1w@mail.gmail.com>
References: <CAFm4XO3oqWtsWjsa-OP9bE9KgmOWWKM5BhzsgWa6_=8OjSJxzQ@mail.gmail.com>
	<CAFm4XO15SR2sCRvpf0+QtotkccrsUVtJfiqtFfqn-kTuLmV+1w@mail.gmail.com>
Message-ID: <CAFm4XO2uNJU3V5LydPsfrWvni-ww3KW8i_kiE2DHyza-kf1=LA@mail.gmail.com>

Some more references on the NIO issue:
 - http://mail.openjdk.java.net/pipermail/nio-dev/2015-January/002981.html
 - https://issues.apache.org/jira/browse/LUCENE-6169

On 9 February 2015 at 14:12, Sanne Grinovero <sanne at hibernate.org> wrote:
> All tests relating to Lucene which use the FSDirectory are failing
> because of an issue the Lucene team already reported.
> That obviously "kills" the Hibernate Search testsuite, but also
> created a couple of failures with Hibernate OGM.
>
> Sorry for the noise, I'll disable both until we get to know what fix
> will be needed.
>
> It's a controversial issue, as the Lucene was taking advantage of a
> not-explicitly documented semantic of NIO to flush all files of a
> directory in a single atomic operation, but requesting a flush on the
> File instance which represents the Directory.
> The JDK now disallows this; I'm not sure yet if Lucene will need to
> find an alternative flushing strategy or rather if the OpenJDK team
> will reconsider.
>
> Sanne
>
> On 9 February 2015 at 13:44, Sanne Grinovero <sanne at hibernate.org> wrote:
>> Hi all,
>> I just downloaded these versions of the OpenJDK and replaced the
>> existing ones on ci.hibernate.org:
>>
>> jdk-7u80-ea-bin-b05-linux-x64-20_jan_2015.tar.gz
>> jdk-8u40-ea-bin-b23-linux-x64-27_jan_2015.tar.gz
>> jdk-9-ea-bin-b49-linux-x64-04_feb_2015.tar.gz
>>
>> I now triggered several builds of various JDK/project combinations. I
>> don't expect any regression, but in case there are broken builds,
>> that's an additional reason to consider.
>>
>> Thanks,
>> Sanne

From janarioliver at gmail.com  Mon Feb  9 09:39:22 2015
From: janarioliver at gmail.com (Janario Oliveira)
Date: Mon, 9 Feb 2015 12:39:22 -0200
Subject: [hibernate-dev] Sequence Pool
Message-ID: <CAOTwREESHMKDJkUuOFa4TL2yAY1xJDamUGm5V3C8qW-hKunmxg@mail.gmail.com>

Hi guys,

I am migrating some code base and I have some problems using sequence.
As I see it works with a pool together to allocationSize. But it expects
that the sequence have the same increment by (50 as default).

Is there a global configuration that disable pool and always read from the
sequence?

In my case scripts are generated manually and everyone will have to
remember to add increment by 50 or allocationSize = 1.


Also this would change order creation vs order id.
e.g.
If I create 2 rows with hibernate it will keep pooling from 1 to 50. (id 1
and 2)
After that some procedure or script can create another one with nextval of
the sequence. (id 51)
Next hibernate create another row. (id 3)

The right order of creation is: 1, 2, 51, 3
But ordering by id will load a wrong order.

From unmeshjoshi at gmail.com  Tue Feb 10 19:35:46 2015
From: unmeshjoshi at gmail.com (Unmesh Joshi)
Date: Wed, 11 Feb 2015 06:05:46 +0530
Subject: [hibernate-dev] Multiple joined-subclass mappings to same table
Message-ID: <CAOk+zfeiTGNXyAuHDgCbEs-WyEurazfy+Lk129q0iLnf+nFgWQ@mail.gmail.com>

Hi,

I am bit puzzled with this. I am looking at a codebase, where there are
multiple joined-subclass mappings (in separate hbm.xml files) which map to
same table. For union-subclass, we correctly get exception for duplicate
mapping. But for joined-subclass it allows multiple mappings to same table.
In the hibernate source code, I see that for Joined subclass, the table
mapping is added with following method call.

Table mytable = mappings.addTable(
schema,
catalog,
getClassTableName( joinedSubclass, node, schema, catalog, null, mappings ),
getSubselect( node ),
false

For union-subclass, the mapping gets added with

Table mytable = mappings.addDenormalizedTable(
schema,
catalog,
getClassTableName(unionSubclass, node, schema, catalog,
denormalizedSuperTable, mappings ),
unionSubclass.isAbstract() != null && unionSubclass.isAbstract(),
getSubselect( node ),
denormalizedSuperTable
);

mappings.addTable doesnt throw exception if the table mapping already
exists.

Is the behaviour for joined subclass by design? Because I see this fact
being used in some projects, where to extend an already created
joined-subclass, a new hibernate-config file is added with joined-subclass
definition duplicated, with additional attributes (and columns) added to
existing table. So essentially, you have two joined-subclass definitions,
mapping two separate entities to same table.
This does look like using some loop hole in the code?

Thanks,
Unmesh

From Josiah.Haswell at ca.com  Tue Feb 10 20:40:21 2015
From: Josiah.Haswell at ca.com (Haswell, Josiah D)
Date: Wed, 11 Feb 2015 01:40:21 +0000
Subject: [hibernate-dev] Question about substituting IDs in Hibernate OGM
Message-ID: <00fc7bb78a234c13a684e540955c7312@uslims213.ca.com>

Hi folks,

I'm creating a Hibernate OGM implementation for Datomic, and I have a question about IDs.

Say I have the entity

@Entity
public class Person {
@Id
@GeneratedValue
Long id;


}

In Datomic, you have to assign a temporary ID before submitting the transaction.  Datomic will then return the actual persistence ID after the transaction has completed.  My question is, how can I get the actual ID back into the entity?

Thanks!

Josiah

From gunnar at hibernate.org  Wed Feb 11 03:42:33 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 11 Feb 2015 09:42:33 +0100
Subject: [hibernate-dev] Question about substituting IDs in Hibernate OGM
In-Reply-To: <00fc7bb78a234c13a684e540955c7312@uslims213.ca.com>
References: <00fc7bb78a234c13a684e540955c7312@uslims213.ca.com>
Message-ID: <CADGJaX8aXy2vA1eKEKRs4QUzaORHK3+9dKPjCUiCPwXwwrQF9A@mail.gmail.com>

Hi Josiah,

It's great to hear that you are working an a backend for Hibernate OGM!

Regarding ids, it should work for you if they are mapped using the IDENTITY
strategy:

    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    Long id;

This causes the Hibernate ORM engine to read back the id value generated by
the datastore upon insertion. To make it work, your GridDialect for OGM
needs to implement the IdentityColumnAwareGridDialect facet [1]. You can
check out the MongoDB dialect for an example.

If this works and this kind of id generation is the only one which is
useful for Datomic (i.e. table/sequence strategies don't make any sense),
you may validate mapped entities by means of a SchemaDefiner [2] (an
experimental contract of OGM). An example is CouchDBSchemaDefiner.

Let us know how it goes or in case you run into any other issues.

--Gunnar

[1]
https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/dialect/identity/spi/IdentityColumnAwareGridDialect.java
[2]
https://github.com/hibernate/hibernate-ogm/blob/master/couchdb/src/main/java/org/hibernate/ogm/datastore/couchdb/impl/CouchDBSchemaSchemaDefiner.java



2015-02-11 2:40 GMT+01:00 Haswell, Josiah D <Josiah.Haswell at ca.com>:

> Hi folks,
>
> I'm creating a Hibernate OGM implementation for Datomic, and I have a
> question about IDs.
>
> Say I have the entity
>
> @Entity
> public class Person {
> @Id
> @GeneratedValue
> Long id;
>
>
> }
>
> In Datomic, you have to assign a temporary ID before submitting the
> transaction.  Datomic will then return the actual persistence ID after the
> transaction has completed.  My question is, how can I get the actual ID
> back into the entity?
>
> Thanks!
>
> Josiah
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Feb 11 09:23:08 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 11 Feb 2015 08:23:08 -0600
Subject: [hibernate-dev] Sequence Pool
In-Reply-To: <CAOTwREESHMKDJkUuOFa4TL2yAY1xJDamUGm5V3C8qW-hKunmxg@mail.gmail.com>
References: <CAOTwREESHMKDJkUuOFa4TL2yAY1xJDamUGm5V3C8qW-hKunmxg@mail.gmail.com>
Message-ID: <CAFdSV9uu8f1REc8QuC3qO-SJLjew=Y6YeTXCh19hpqV_ELPd9g@mail.gmail.com>

First, this is a list for discussing the development of the Hibernate
projects, not for user/usage questions.

As to your question... Yes 50 was an unfortunately choice as the default
within the spec group.  At the moment there is no global "ignore the
specified increment value" setting, and even though you did not explicitly
specify it the way annotations and the JDK work we have no way of telling
that[1].

I'd be open to this as a Feature Request.

[1] To code consuming annotations @SequenceGenerator(name="blah") and
@SequenceGenerator(name="blah", increment=50) look exactly the same.  Well,
there is *a* way, but it requires us using Jandex (or similar annotation
processing library) that parses the source representation of the
annotation.  Then @SequenceGenerator(name="blah") and
@SequenceGenerator(name="blah", increment=50) look different in terms of
the value for increment.  I have tentatively scheduled looking at moving to
Jandex for 5.0, or 5.1, or 6.0


On Feb 9, 2015 8:40 AM, "Janario Oliveira" <janarioliver at gmail.com> wrote:

> Hi guys,
>
> I am migrating some code base and I have some problems using sequence.
> As I see it works with a pool together to allocationSize. But it expects
> that the sequence have the same increment by (50 as default).
>
> Is there a global configuration that disable pool and always read from the
> sequence?
>
> In my case scripts are generated manually and everyone will have to
> remember to add increment by 50 or allocationSize = 1.
>
>
> Also this would change order creation vs order id.
> e.g.
> If I create 2 rows with hibernate it will keep pooling from 1 to 50. (id 1
> and 2)
> After that some procedure or script can create another one with nextval of
> the sequence. (id 51)
> Next hibernate create another row. (id 3)
>
> The right order of creation is: 1, 2, 51, 3
> But ordering by id will load a wrong order.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From davide at hibernate.org  Wed Feb 11 10:42:52 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 11 Feb 2015 15:42:52 +0000
Subject: [hibernate-dev] in.relation.to error when posting a new blog entry
Message-ID: <CANoTJYNDL=YezU0rF8yq5n6ELyGb62QEX4VMzfQ-n=WVR2VryQ@mail.gmail.com>

Hi,
I'm trying to create a new blog entry on in.relation.to
but an exception occurs about the violation of an integrity constraint.

Any idea on how to solve the issue?

Thanks,
Davide

From Josiah.Haswell at ca.com  Wed Feb 11 19:37:46 2015
From: Josiah.Haswell at ca.com (Haswell, Josiah D)
Date: Thu, 12 Feb 2015 00:37:46 +0000
Subject: [hibernate-dev] Question about substituting IDs in Hibernate OGM
In-Reply-To: <CADGJaX8aXy2vA1eKEKRs4QUzaORHK3+9dKPjCUiCPwXwwrQF9A@mail.gmail.com>
References: <00fc7bb78a234c13a684e540955c7312@uslims213.ca.com>
	<CADGJaX8aXy2vA1eKEKRs4QUzaORHK3+9dKPjCUiCPwXwwrQF9A@mail.gmail.com>
Message-ID: <8a2b69228d724b2cb0a75a06ef5caa0b@uslims213.ca.com>

Perfect.  That worked?thanks for the help!

I?ve made some pretty good progress?you can save entities and some associations, and retrieve some properties lazily.  Unfortunately, I?m having a bit of trouble with getting access to all of the type information I need.


In particular, say you have the hierarchy:


@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)  (1)
@Entity
@Table(name = ?persistable?)
Public class Persistable {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
Long id;

@Basic
String persistableName;


}


@Entity
@Table(?person_table?)
Public class Person extends Persistable {

@Basic
@Column(name = ?first_name?)
String firstName;

@Basic
@Column
String lastName;

}

I need to generate the schema:

:persistable/persistableName

:Person/first_name
:Person/lastName

And access it from a few contexts.


Schema Definition

When generating the schema, I need to be able to get the table name, which I was able to from the EntityPersisters available in SessionFactoryImpl.  From there, I needed to be able to get each property on each class, its type, and its alias (as defined by @Column), which I couldn?t figure out how to do.  I looked through both the EntityMetamodel and the ClassMetamodels on each persister, but it wasn?t clear how to get that.

Looking in the ClassMetadata, I found the property names, but that included all of the properties for all of the linear supertypes of the associated entity.
Looking at the EntityMetamodel, I found I could get all of the properties, but I couldn?t figure out how to filter out the properties declared in the current entity type.

I ended up scanning the annotations again to get the information I needed to generate the schema, which doesn?t seem like a good solution.


Now, I?m running into the same problem retrieving a tuple:



public Tuple getTuple(EntityKey k, TupleContext c) {
final Long id = getOrThrowUnexpectedId(k);
final Entity entity = retrieveEntity(id);
return new Tuple(new LazyEntityBackedTupleSnapshot(entity, tupleContext));
}


public class LazyEntityBackedTupleSnapshot implements TupleSnapshot {
final Entity entity;
final TupleContext context;
//constructor, etc.

public Object get(String column) {
return entity.get(column);

}


}


Now, the problem is, say the entity that I retrieved was a Person.  If I call p.getPersistableName() , then entity.get(column) needs to be
Entity.get(?:persistable/persistableName?) to get the value.  I could search through the linear supertypes of the current type if I could get it.  I notice that the actual TupleContext that I?m getting has an OptionsContextImpl with an entity type that I can use to search for the appropriate entity type, but that?s private, and I don?t want to use reflection to get it.

I?m sure I?m just missing some cool feature of OGM here, and couldn?t find it looking through the other implementations.  Any additional help would be fantastic.

Thanks!



From: gunnar.morling at googlemail.com [mailto:gunnar.morling at googlemail.com] On Behalf Of Gunnar Morling
Sent: Wednesday, February 11, 2015 12:43 AM
To: Haswell, Josiah D
Cc: hibernate-dev at lists.jboss.org
Subject: Re: [hibernate-dev] Question about substituting IDs in Hibernate OGM

Hi Josiah,

It's great to hear that you are working an a backend for Hibernate OGM!

Regarding ids, it should work for you if they are mapped using the IDENTITY strategy:

    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    Long id;

This causes the Hibernate ORM engine to read back the id value generated by the datastore upon insertion. To make it work, your GridDialect for OGM needs to implement the IdentityColumnAwareGridDialect facet [1]. You can check out the MongoDB dialect for an example.

If this works and this kind of id generation is the only one which is useful for Datomic (i.e. table/sequence strategies don't make any sense), you may validate mapped entities by means of a SchemaDefiner [2] (an experimental contract of OGM). An example is CouchDBSchemaDefiner.

Let us know how it goes or in case you run into any other issues.

--Gunnar

[1] https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/dialect/identity/spi/IdentityColumnAwareGridDialect.java
[2] https://github.com/hibernate/hibernate-ogm/blob/master/couchdb/src/main/java/org/hibernate/ogm/datastore/couchdb/impl/CouchDBSchemaSchemaDefiner.java



2015-02-11 2:40 GMT+01:00 Haswell, Josiah D <Josiah.Haswell at ca.com<mailto:Josiah.Haswell at ca.com>>:
Hi folks,

I'm creating a Hibernate OGM implementation for Datomic, and I have a question about IDs.

Say I have the entity

@Entity
public class Person {
@Id
@GeneratedValue
Long id;


}

In Datomic, you have to assign a temporary ID before submitting the transaction.  Datomic will then return the actual persistence ID after the transaction has completed.  My question is, how can I get the actual ID back into the entity?

Thanks!

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


From gbadner at redhat.com  Wed Feb 11 20:36:16 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 11 Feb 2015 20:36:16 -0500 (EST)
Subject: [hibernate-dev] in.relation.to error when posting a new blog
 entry
In-Reply-To: <CANoTJYNDL=YezU0rF8yq5n6ELyGb62QEX4VMzfQ-n=WVR2VryQ@mail.gmail.com>
References: <CANoTJYNDL=YezU0rF8yq5n6ELyGb62QEX4VMzfQ-n=WVR2VryQ@mail.gmail.com>
Message-ID: <2058705871.10879457.1423704976067.JavaMail.zimbra@redhat.com>

I ran into the same thing a couple of weeks ago when I deleted some spam comments before trying to create new weblog. I asked Sanne about this and he mentioned that he's seen this happen after deleting spam comments. He said it would require some clean up, but he didn't have time.

Sanne, I know you're very busy. Can you point one of us in the right direction to clean up what is necessary?

Thanks,
Gail
----- Original Message -----
> From: "Davide D'Alto" <davide at hibernate.org>
> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Wednesday, February 11, 2015 7:42:52 AM
> Subject: [hibernate-dev] in.relation.to error when posting a new blog entry
> 
> Hi,
> I'm trying to create a new blog entry on in.relation.to
> but an exception occurs about the violation of an integrity constraint.
> 
> Any idea on how to solve the issue?
> 
> Thanks,
> Davide
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Thu Feb 12 01:57:55 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 12 Feb 2015 06:57:55 +0000
Subject: [hibernate-dev] in.relation.to error when posting a new blog
	entry
References: <CANoTJYNDL=YezU0rF8yq5n6ELyGb62QEX4VMzfQ-n=WVR2VryQ@mail.gmail.com>
	<2058705871.10879457.1423704976067.JavaMail.zimbra@redhat.com>
Message-ID: <CAFm4XO3XNzBbbcLDG8iNV7bq_H9O-zSc4DZjERq4GXFmncZmrg@mail.gmail.com>

Hi, sorry I forgot about this and I'm currently away so if someone could
look at it that would be great.
I suspect it's a broken foreign key on MySQL, hopefully the error message
will have some details? Some table maintenance should do the trick.
You'll have to ssh into in.relation.to and from there connect to the MySQL
console. The connection details are in the datasource description deployed
in the AS (I don't remember them but that's a good place to read the
hostname and access credentials to the db).
The firewall on the db server will not allow you to connect from your own
place, so make sure you use the MySQL console from the in.relation.to
server.
An alternative might be to use the AWS dashboard, maybe it has some tools
for db maintenance? I usually use the terminal myself.

Thanks
Sanne

On Thu, 12 Feb 2015 02:36 Gail Badner <gbadner at redhat.com> wrote:

> I ran into the same thing a couple of weeks ago when I deleted some spam
> comments before trying to create new weblog. I asked Sanne about this and
> he mentioned that he's seen this happen after deleting spam comments. He
> said it would require some clean up, but he didn't have time.
>
> Sanne, I know you're very busy. Can you point one of us in the right
> direction to clean up what is necessary?
>
> Thanks,
> Gail
> ----- Original Message -----
> > From: "Davide D'Alto" <davide at hibernate.org>
> > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > Sent: Wednesday, February 11, 2015 7:42:52 AM
> > Subject: [hibernate-dev] in.relation.to error when posting a new blog
> entry
> >
> > Hi,
> > I'm trying to create a new blog entry on in.relation.to
> > but an exception occurs about the violation of an integrity constraint.
> >
> > Any idea on how to solve the issue?
> >
> > Thanks,
> > Davide
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Thu Feb 12 03:42:37 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 12 Feb 2015 09:42:37 +0100
Subject: [hibernate-dev] Question about substituting IDs in Hibernate OGM
In-Reply-To: <8a2b69228d724b2cb0a75a06ef5caa0b@uslims213.ca.com>
References: <00fc7bb78a234c13a684e540955c7312@uslims213.ca.com>
	<CADGJaX8aXy2vA1eKEKRs4QUzaORHK3+9dKPjCUiCPwXwwrQF9A@mail.gmail.com>
	<8a2b69228d724b2cb0a75a06ef5caa0b@uslims213.ca.com>
Message-ID: <CADGJaX_03kJdLVXJoAOhi7jvMkm65T5W8vz_FfRqXDv8dd-keA@mail.gmail.com>

2015-02-12 1:37 GMT+01:00 Haswell, Josiah D <Josiah.Haswell at ca.com>:

>  Perfect.  That worked?thanks for the help!
>

Cool :)


> I?ve made some pretty good progress?you can save entities and some
> associations, and retrieve some properties lazily.  Unfortunately, I?m
> having a bit of trouble with getting access to all of the type information
> I need.
>
>
>
>
>
> In particular, say you have the hierarchy:
>
>
>
>
>
> @Inheritance(strategy = InheritanceType.*TABLE_PER_CLASS*)  (1)
>
> @Entity
>
> @Table(name = ?persistable?)
>
> Public class Persistable {
>
> @Id
>
> @GeneratedValue(strategy = GenerationType.IDENTITY)
>
> Long id;
>
>
>
> @Basic
>
> String persistableName;
>
>
>
>
>
> }
>
>
>
>
>
> @Entity
>
> @Table(?person_table?)
>
> Public class Person extends Persistable {
>
>
>
> @Basic
>
> @Column(name = ?first_name?)
>
> String firstName;
>
>
>
> @Basic
>
> @Column
>
> String lastName;
>
>
>
> }
>
>
>
> I need to generate the schema:
>
>
>
> :persistable/persistableName
>
>
>
> :Person/first_name
>
> :Person/lastName
>


TABLE_PER_CLASS is meant to create a table for each type of the hierarchy
with *all* its attributes. So actually you'd have to generate the following
schema:

    :Persistable/persistableName

    :Person/persistableName
    :Person/first_name
    :Person/lastName

We also support SINGLE_TABLE which creates one table for all the types of
the hierarchy, so the schema would have to be the following:

    :Persistable/persistableName
    :Persistable/first_name
    :Persistable/lastName
    :Persistable/DTYPE //denotes the entity type

Atm. we don't support JOINED (which may be what you had in mind).

And access it from a few contexts.
>
>
>
>
>
> *Schema Definition*
>
>
>
> When generating the schema, I need to be able to get the table name, which
> I was able to from the EntityPersisters available in SessionFactoryImpl.
> From there, I needed to be able to get each property on each class, its
> type, and its alias (as defined by @Column), which I couldn?t figure out
> how to do.  I looked through both the EntityMetamodel and the
> ClassMetamodels on each persister, but it wasn?t clear how to get that.
>
>
>
> Looking in the ClassMetadata, I found the property names, but that
> included all of the properties for all of the linear supertypes of the
> associated entity.
>
> Looking at the EntityMetamodel, I found I could get all of the properties,
> but I couldn?t figure out how to filter out the properties declared in the
> current entity type.
>
>
>
> I ended up scanning the annotations again to get the information I needed
> to generate the schema, which doesn?t seem like a good solution.
>

Schema definition is still a weak point in OGM atm., the grid dialects we
began with tend to have no strong schema. There is the SchemaDefiner
contract which you need to implement for this (and make known via
YourDatastoreProvider#getSchemaDefinerType()). In
YourSchemaDefiner#initializeSchema() you can obtain everything you need
e.g. like so:

    @Override
    public void initializeSchema(Configuration configuration,
SessionFactoryImplementor factory) {
        Iterator<PersistentClass> classMappings = configuration
.getClassMappings();

        while ( classMappings.hasNext() ) {
            PersistentClass mapping = classMappings.next();
            Table table = mapping.getTable();

            Iterator<Column> columnIterator = table.getColumnIterator();
            while(columnIterator.hasNext()) {
                Column column = columnIterator.next();
                String columnName = column.getName();

                // do something with column...
            }
        }
    }

Note that this API stems straight from Hibernate ORM and is not exactly
what we'd like to have for Hibernate OGM. So be prepared for changes in
this area in future revisions (the entire SchemaDefiner contract is
considered experimental atm., also Configuration will go away in Hibernate
ORM in the future), but for now it should allow you to do the right thing.
Definitely better than doing manual annotation scanning :)


> Now, I?m running into the same problem retrieving a tuple:
>
>
>
>
>
>
>
> public Tuple getTuple(EntityKey k, TupleContext c) {
>
> final Long id = getOrThrowUnexpectedId(k);
>
> final Entity entity = retrieveEntity(id);
>
> return new Tuple(*new LazyEntityBackedTupleSnapshot(entity, tupleContex*
> t));
>
> }
>
>
>
>
>
> public class LazyEntityBackedTupleSnapshot implements TupleSnapshot {
>
> final Entity entity;
>
> final TupleContext context;
>
> //constructor, etc.
>
>
>
> public Object get(String column) {
>
> *return entity.get(column);*
>
>
>
> }
>
>
>
>
>
> }
>
>
>
>
>
> Now, the problem is, say the entity that I retrieved was a Person.  If I
> call *p.getPersistableName() , *then entity.get(column) needs to be
>
> Entity.get(?:persistable/persistableName?) to get the value.  I could
> search through the linear supertypes of the current type if I could get
> it.  I notice that the actual TupleContext that I?m getting has an
> OptionsContextImpl with an entity type that I can use to search for the
> appropriate entity type, but that?s private, and I don?t want to use
> reflection to get it.
>

See above, you should take all the column values from the Person table (or
the Persistable table when working with SINGLE_TABLE). You can get the
table name from the given entity key. From the tuple context btw. you can
get the columns we actually need, so you don't need to fetch any unmapped
columns from the datastore.


> I?m sure I?m just missing some cool feature of OGM here, and couldn?t find
> it looking through the other implementations.  Any additional help would be
> fantastic.
>
>
>
> Thanks!
>

No problem. Hope it helps,

--Gunnar

*From:* gunnar.morling at googlemail.com [mailto:gunnar.morling at googlemail.com]
> *On Behalf Of *Gunnar Morling
> *Sent:* Wednesday, February 11, 2015 12:43 AM
> *To:* Haswell, Josiah D
> *Cc:* hibernate-dev at lists.jboss.org
> *Subject:* Re: [hibernate-dev] Question about substituting IDs in
> Hibernate OGM
>
>
>
> Hi Josiah,
>
>
>
> It's great to hear that you are working an a backend for Hibernate OGM!
>
>
>
> Regarding ids, it should work for you if they are mapped using the
> IDENTITY strategy:
>
>
>
>     @Id
>
>     @GeneratedValue(strategy=GenerationType.IDENTITY)
>
>     Long id;
>
>
>
> This causes the Hibernate ORM engine to read back the id value generated
> by the datastore upon insertion. To make it work, your GridDialect for OGM
> needs to implement the IdentityColumnAwareGridDialect facet [1]. You can
> check out the MongoDB dialect for an example.
>
>
>
> If this works and this kind of id generation is the only one which is
> useful for Datomic (i.e. table/sequence strategies don't make any sense),
> you may validate mapped entities by means of a SchemaDefiner [2] (an
> experimental contract of OGM). An example is CouchDBSchemaDefiner.
>
>
>
> Let us know how it goes or in case you run into any other issues.
>
>
>
> --Gunnar
>
>
>
> [1]
> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/dialect/identity/spi/IdentityColumnAwareGridDialect.java
>
> [2]
> https://github.com/hibernate/hibernate-ogm/blob/master/couchdb/src/main/java/org/hibernate/ogm/datastore/couchdb/impl/CouchDBSchemaSchemaDefiner.java
>
>
>
>
>
>
>
> 2015-02-11 2:40 GMT+01:00 Haswell, Josiah D <Josiah.Haswell at ca.com>:
>
> Hi folks,
>
> I'm creating a Hibernate OGM implementation for Datomic, and I have a
> question about IDs.
>
> Say I have the entity
>
> @Entity
> public class Person {
> @Id
> @GeneratedValue
> Long id;
>
>
> }
>
> In Datomic, you have to assign a temporary ID before submitting the
> transaction.  Datomic will then return the actual persistence ID after the
> transaction has completed.  My question is, how can I get the actual ID
> back into the entity?
>
> Thanks!
>
> Josiah
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>

From janarioliver at gmail.com  Thu Feb 12 08:05:58 2015
From: janarioliver at gmail.com (Janario Oliveira)
Date: Thu, 12 Feb 2015 11:05:58 -0200
Subject: [hibernate-dev] Sequence Pool
In-Reply-To: <CAFdSV9uu8f1REc8QuC3qO-SJLjew=Y6YeTXCh19hpqV_ELPd9g@mail.gmail.com>
References: <CAOTwREESHMKDJkUuOFa4TL2yAY1xJDamUGm5V3C8qW-hKunmxg@mail.gmail.com>
	<CAFdSV9uu8f1REc8QuC3qO-SJLjew=Y6YeTXCh19hpqV_ELPd9g@mail.gmail.com>
Message-ID: <CAOTwREHrdaVMDPKm_=Ke1uvE80nF3uG=-yAa1ghfT+CLbO_G6w@mail.gmail.com>

Thanks Steve,

I'm going to open a Feature Request.

Sorry for the wrong list :)


On Wed, Feb 11, 2015 at 12:23 PM, Steve Ebersole <steve at hibernate.org>
wrote:

> First, this is a list for discussing the development of the Hibernate
> projects, not for user/usage questions.
>
> As to your question... Yes 50 was an unfortunately choice as the default
> within the spec group.  At the moment there is no global "ignore the
> specified increment value" setting, and even though you did not explicitly
> specify it the way annotations and the JDK work we have no way of telling
> that[1].
>
> I'd be open to this as a Feature Request.
>
> [1] To code consuming annotations @SequenceGenerator(name="blah") and
> @SequenceGenerator(name="blah", increment=50) look exactly the same.  Well,
> there is *a* way, but it requires us using Jandex (or similar annotation
> processing library) that parses the source representation of the
> annotation.  Then @SequenceGenerator(name="blah") and
> @SequenceGenerator(name="blah", increment=50) look different in terms of
> the value for increment.  I have tentatively scheduled looking at moving to
> Jandex for 5.0, or 5.1, or 6.0
>
>
> On Feb 9, 2015 8:40 AM, "Janario Oliveira" <janarioliver at gmail.com> wrote:
>
>> Hi guys,
>>
>> I am migrating some code base and I have some problems using sequence.
>> As I see it works with a pool together to allocationSize. But it expects
>> that the sequence have the same increment by (50 as default).
>>
>> Is there a global configuration that disable pool and always read from the
>> sequence?
>>
>> In my case scripts are generated manually and everyone will have to
>> remember to add increment by 50 or allocationSize = 1.
>>
>>
>> Also this would change order creation vs order id.
>> e.g.
>> If I create 2 rows with hibernate it will keep pooling from 1 to 50. (id 1
>> and 2)
>> After that some procedure or script can create another one with nextval of
>> the sequence. (id 51)
>> Next hibernate create another row. (id 3)
>>
>> The right order of creation is: 1, 2, 51, 3
>> But ordering by id will load a wrong order.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From paranoiabla at gmail.com  Thu Feb 12 08:26:13 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Thu, 12 Feb 2015 15:26:13 +0200
Subject: [hibernate-dev] Preparing to release 4.3.8 and 4.2.17
In-Reply-To: <CAKnbemVJ_9Cr79oWCiBmH05oBQ0WsRgWX17gSxQZ9cq+wAzxUA@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>
	<CAKnbemVJ_9Cr79oWCiBmH05oBQ0WsRgWX17gSxQZ9cq+wAzxUA@mail.gmail.com>
Message-ID: <CAKnbemVYWhADYebaryqHtJeREYD7yPFKeEAfcWjb9r+cJY33=w@mail.gmail.com>

Any updated on this? Will it be included in the next release?

2015-01-06 14:06 GMT+02:00 Petar Tahchiev <paranoiabla at 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
>



-- 
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 m.schipperheyn at gmail.com  Thu Feb 12 09:03:50 2015
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Thu, 12 Feb 2015 12:03:50 -0200
Subject: [hibernate-dev] Inconsistent projection result
Message-ID: <CAGvEgx4LQpnxeb1Aw3+7oC3BR_rBV5EGnjwRw88gYqz-ggfvvA@mail.gmail.com>

Projecting on an id is giving me inconsistent results.

On the same method, sometimes a String is returned, other times a Number.
I'm even seeing this difference running the test twice in a row.

I haven't been able to find what makes it switch, but I am 100% sure it
happens. I have this structure.

 List<Object[]> result = fts .createFullTextQuery( mj.createQuery(),
BaseWallPost.class) .setProjection(ProjectionConstants.ID, "post.id")
.list(); for(Object[] tuple : result){ // Long postId = tuple[1] != null?
Long.valueOf((String) tuple[1]) : null; Long postId = (Long) tuple[1]; }
@Entity public abstract class BaseComment{ @Id @GeneratedValue(strategy =
GenerationType.AUTO) @Column
@Field(name="longCommentId",index=Index.YES,store=Store.YES,analyze=Analyze.NO)
@DocumentId public Long id; } @Entity public abstract class BasePost
extends BaseComment{ @ManyToOne @JoinColumn
@IndexedEmbedded(includePaths={"id","type","longCommentId"},indexNullAs=Field.DEFAULT_NULL_TOKEN,includeEmbeddedObjectId=true)
@ContainedIn//Update the shareCount public Post post; } @Entity public
class Post extends BasePost{ } @Entity public class Comment extends
BaseComment{ @ManyToOne @JoinColumn
@IndexedEmbedded(includePaths={"id","type","blocked","longCommentId"},indexNullAs=Field.DEFAULT_NULL_TOKEN,includeEmbeddedObjectId=true)
@ContainedIn public BasePost post; }

From Josiah.Haswell at ca.com  Thu Feb 12 16:13:58 2015
From: Josiah.Haswell at ca.com (Haswell, Josiah D)
Date: Thu, 12 Feb 2015 21:13:58 +0000
Subject: [hibernate-dev] Question about substituting IDs in Hibernate OGM
In-Reply-To: <CADGJaX_03kJdLVXJoAOhi7jvMkm65T5W8vz_FfRqXDv8dd-keA@mail.gmail.com>
References: <00fc7bb78a234c13a684e540955c7312@uslims213.ca.com>
	<CADGJaX8aXy2vA1eKEKRs4QUzaORHK3+9dKPjCUiCPwXwwrQF9A@mail.gmail.com>
	<8a2b69228d724b2cb0a75a06ef5caa0b@uslims213.ca.com>
	<CADGJaX_03kJdLVXJoAOhi7jvMkm65T5W8vz_FfRqXDv8dd-keA@mail.gmail.com>
Message-ID: <1bff9485340b4a589e7dc8977741e365@uslims213.ca.com>

Hi Gunnar,

I didn?t even think to look at the configuration, thanks ?.   All of the inheritance strategies are supported in Datomic, but Join is probably going to be most commonly used (it certainly is in our schemata).

While it?s not a blocking concern, an important optimization would be to link all of the associations by temp ID and commit them in a big transaction, which I think will require some extension to OGM.  I suspect that you folks on OGM will have some good ideas about mapping JPA transactions to Datomic transactions.


I?d certainly be happy to work on getting some of this stuff into OGM if there are existing designs that I could help implement.  I?d also like to start contributing the project to OGM if it?s appropriate in order to get some more experienced eyes on it.

Any suggestions on how to proceed?

Thanks!

Josiah

From: gunnar.morling at googlemail.com [mailto:gunnar.morling at googlemail.com] On Behalf Of Gunnar Morling
Sent: Thursday, February 12, 2015 12:43 AM
To: Haswell, Josiah D
Cc: hibernate-dev at lists.jboss.org
Subject: Re: [hibernate-dev] Question about substituting IDs in Hibernate OGM

2015-02-12 1:37 GMT+01:00 Haswell, Josiah D <Josiah.Haswell at ca.com<mailto:Josiah.Haswell at ca.com>>:
Perfect.  That worked?thanks for the help!

Cool :)

I?ve made some pretty good progress?you can save entities and some associations, and retrieve some properties lazily.  Unfortunately, I?m having a bit of trouble with getting access to all of the type information I need.


In particular, say you have the hierarchy:


@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)  (1)
@Entity
@Table(name = ?persistable?)
Public class Persistable {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
Long id;

@Basic
String persistableName;


}


@Entity
@Table(?person_table?)
Public class Person extends Persistable {

@Basic
@Column(name = ?first_name?)
String firstName;

@Basic
@Column
String lastName;

}

I need to generate the schema:

:persistable/persistableName

:Person/first_name
:Person/lastName


TABLE_PER_CLASS is meant to create a table for each type of the hierarchy with *all* its attributes. So actually you'd have to generate the following schema:

    :Persistable/persistableName

    :Person/persistableName
    :Person/first_name
    :Person/lastName

We also support SINGLE_TABLE which creates one table for all the types of the hierarchy, so the schema would have to be the following:

    :Persistable/persistableName
    :Persistable/first_name
    :Persistable/lastName
    :Persistable/DTYPE //denotes the entity type

Atm. we don't support JOINED (which may be what you had in mind).

And access it from a few contexts.


Schema Definition

When generating the schema, I need to be able to get the table name, which I was able to from the EntityPersisters available in SessionFactoryImpl.  From there, I needed to be able to get each property on each class, its type, and its alias (as defined by @Column), which I couldn?t figure out how to do.  I looked through both the EntityMetamodel and the ClassMetamodels on each persister, but it wasn?t clear how to get that.

Looking in the ClassMetadata, I found the property names, but that included all of the properties for all of the linear supertypes of the associated entity.
Looking at the EntityMetamodel, I found I could get all of the properties, but I couldn?t figure out how to filter out the properties declared in the current entity type.

I ended up scanning the annotations again to get the information I needed to generate the schema, which doesn?t seem like a good solution.

Schema definition is still a weak point in OGM atm., the grid dialects we began with tend to have no strong schema. There is the SchemaDefiner contract which you need to implement for this (and make known via YourDatastoreProvider#getSchemaDefinerType()). In YourSchemaDefiner#initializeSchema() you can obtain everything you need e.g. like so:

    @Override
    public void initializeSchema(Configuration configuration, SessionFactoryImplementor factory) {
        Iterator<PersistentClass> classMappings = configuration.getClassMappings();

        while ( classMappings.hasNext() ) {
            PersistentClass mapping = classMappings.next();
            Table table = mapping.getTable();

            Iterator<Column> columnIterator = table.getColumnIterator();
            while(columnIterator.hasNext()) {
                Column column = columnIterator.next();
                String columnName = column.getName();

                // do something with column...
            }
        }
    }

Note that this API stems straight from Hibernate ORM and is not exactly what we'd like to have for Hibernate OGM. So be prepared for changes in this area in future revisions (the entire SchemaDefiner contract is considered experimental atm., also Configuration will go away in Hibernate ORM in the future), but for now it should allow you to do the right thing. Definitely better than doing manual annotation scanning :)

Now, I?m running into the same problem retrieving a tuple:



public Tuple getTuple(EntityKey k, TupleContext c) {
final Long id = getOrThrowUnexpectedId(k);
final Entity entity = retrieveEntity(id);
return new Tuple(new LazyEntityBackedTupleSnapshot(entity, tupleContext));
}


public class LazyEntityBackedTupleSnapshot implements TupleSnapshot {
final Entity entity;
final TupleContext context;
//constructor, etc.

public Object get(String column) {
return entity.get(column);

}


}


Now, the problem is, say the entity that I retrieved was a Person.  If I call p.getPersistableName() , then entity.get(column) needs to be
Entity.get(?:persistable/persistableName?) to get the value.  I could search through the linear supertypes of the current type if I could get it.  I notice that the actual TupleContext that I?m getting has an OptionsContextImpl with an entity type that I can use to search for the appropriate entity type, but that?s private, and I don?t want to use reflection to get it.

See above, you should take all the column values from the Person table (or the Persistable table when working with SINGLE_TABLE). You can get the table name from the given entity key. From the tuple context btw. you can get the columns we actually need, so you don't need to fetch any unmapped columns from the datastore.

I?m sure I?m just missing some cool feature of OGM here, and couldn?t find it looking through the other implementations.  Any additional help would be fantastic.

Thanks!

No problem. Hope it helps,

--Gunnar

From: gunnar.morling at googlemail.com<mailto:gunnar.morling at googlemail.com> [mailto:gunnar.morling at googlemail.com<mailto:gunnar.morling at googlemail.com>] On Behalf Of Gunnar Morling
Sent: Wednesday, February 11, 2015 12:43 AM
To: Haswell, Josiah D
Cc: hibernate-dev at lists.jboss.org<mailto:hibernate-dev at lists.jboss.org>
Subject: Re: [hibernate-dev] Question about substituting IDs in Hibernate OGM

Hi Josiah,

It's great to hear that you are working an a backend for Hibernate OGM!

Regarding ids, it should work for you if they are mapped using the IDENTITY strategy:

    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    Long id;

This causes the Hibernate ORM engine to read back the id value generated by the datastore upon insertion. To make it work, your GridDialect for OGM needs to implement the IdentityColumnAwareGridDialect facet [1]. You can check out the MongoDB dialect for an example.

If this works and this kind of id generation is the only one which is useful for Datomic (i.e. table/sequence strategies don't make any sense), you may validate mapped entities by means of a SchemaDefiner [2] (an experimental contract of OGM). An example is CouchDBSchemaDefiner.

Let us know how it goes or in case you run into any other issues.

--Gunnar

[1] https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/dialect/identity/spi/IdentityColumnAwareGridDialect.java
[2] https://github.com/hibernate/hibernate-ogm/blob/master/couchdb/src/main/java/org/hibernate/ogm/datastore/couchdb/impl/CouchDBSchemaSchemaDefiner.java



2015-02-11 2:40 GMT+01:00 Haswell, Josiah D <Josiah.Haswell at ca.com<mailto:Josiah.Haswell at ca.com>>:
Hi folks,

I'm creating a Hibernate OGM implementation for Datomic, and I have a question about IDs.

Say I have the entity

@Entity
public class Person {
@Id
@GeneratedValue
Long id;


}

In Datomic, you have to assign a temporary ID before submitting the transaction.  Datomic will then return the actual persistence ID after the transaction has completed.  My question is, how can I get the actual ID back into the entity?

Thanks!

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



From gbadner at redhat.com  Fri Feb 13 00:15:30 2015
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 13 Feb 2015 00:15:30 -0500 (EST)
Subject: [hibernate-dev] Enum object bound to SQLQuery
In-Reply-To: <83804758.11583742.1423804278230.JavaMail.zimbra@redhat.com>
Message-ID: <1608293521.11584506.1423804530271.JavaMail.zimbra@redhat.com>

Should enum objects be converted to the appropriate type when bound to a native query?

It looks like they are converted properly when bound using a Criteria or HQL Query, but not for a SQLQuery.

Attached is a patch for EnumTypeTest that shows that it works for Criteria and HQL queries, and fails for SQLQuery.

Is this a bug?

Thanks,
Gail

From gbadner at redhat.com  Fri Feb 13 01:40:11 2015
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 13 Feb 2015 01:40:11 -0500 (EST)
Subject: [hibernate-dev] in.relation.to error when posting a new blog
 entry
In-Reply-To: <CAFm4XO3XNzBbbcLDG8iNV7bq_H9O-zSc4DZjERq4GXFmncZmrg@mail.gmail.com>
References: <CANoTJYNDL=YezU0rF8yq5n6ELyGb62QEX4VMzfQ-n=WVR2VryQ@mail.gmail.com>
	<2058705871.10879457.1423704976067.JavaMail.zimbra@redhat.com>
	<CAFm4XO3XNzBbbcLDG8iNV7bq_H9O-zSc4DZjERq4GXFmncZmrg@mail.gmail.com>
Message-ID: <1213606316.11612007.1423809611180.JavaMail.zimbra@redhat.com>

I can look into this tomorrow. Please let me know if someone is already working on this.
Thanks,
Gail

----- Original Message -----
> From: "Sanne Grinovero" <sanne at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>, "Davide D'Alto" <davide at hibernate.org>
> Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>, "Sanne Grinovero" <sanne at hibernate.org>
> Sent: Wednesday, February 11, 2015 10:57:55 PM
> Subject: Re: [hibernate-dev] in.relation.to error when posting a new blog entry
> 
> Hi, sorry I forgot about this and I'm currently away so if someone could
> look at it that would be great.
> I suspect it's a broken foreign key on MySQL, hopefully the error message
> will have some details? Some table maintenance should do the trick.
> You'll have to ssh into in.relation.to and from there connect to the MySQL
> console. The connection details are in the datasource description deployed
> in the AS (I don't remember them but that's a good place to read the
> hostname and access credentials to the db).
> The firewall on the db server will not allow you to connect from your own
> place, so make sure you use the MySQL console from the in.relation.to
> server.
> An alternative might be to use the AWS dashboard, maybe it has some tools
> for db maintenance? I usually use the terminal myself.
> 
> Thanks
> Sanne
> 
> On Thu, 12 Feb 2015 02:36 Gail Badner <gbadner at redhat.com> wrote:
> 
> > I ran into the same thing a couple of weeks ago when I deleted some spam
> > comments before trying to create new weblog. I asked Sanne about this and
> > he mentioned that he's seen this happen after deleting spam comments. He
> > said it would require some clean up, but he didn't have time.
> >
> > Sanne, I know you're very busy. Can you point one of us in the right
> > direction to clean up what is necessary?
> >
> > Thanks,
> > Gail
> > ----- Original Message -----
> > > From: "Davide D'Alto" <davide at hibernate.org>
> > > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > > Sent: Wednesday, February 11, 2015 7:42:52 AM
> > > Subject: [hibernate-dev] in.relation.to error when posting a new blog
> > entry
> > >
> > > Hi,
> > > I'm trying to create a new blog entry on in.relation.to
> > > but an exception occurs about the violation of an integrity constraint.
> > >
> > > Any idea on how to solve the issue?
> > >
> > > Thanks,
> > > Davide
> > >
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> 

From hardy at hibernate.org  Fri Feb 13 04:53:21 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 13 Feb 2015 10:53:21 +0100
Subject: [hibernate-dev] in.relation.to error when posting a new blog
 entry
In-Reply-To: <CAFm4XO3XNzBbbcLDG8iNV7bq_H9O-zSc4DZjERq4GXFmncZmrg@mail.gmail.com>
References: <CANoTJYNDL=YezU0rF8yq5n6ELyGb62QEX4VMzfQ-n=WVR2VryQ@mail.gmail.com>
	<2058705871.10879457.1423704976067.JavaMail.zimbra@redhat.com>
	<CAFm4XO3XNzBbbcLDG8iNV7bq_H9O-zSc4DZjERq4GXFmncZmrg@mail.gmail.com>
Message-ID: <20150213095321.GC77073@Sarmakand-4.local>

On Thu, Feb 12, 2015 at 06:57:55AM +0000, Sanne Grinovero wrote:
> I suspect it's a broken foreign key on MySQL, hopefully the error message
> will have some details? Some table maintenance should do the trick.

Do you literally talk about the table maintenance commands like
REPAIR TABLE (http://dev.mysql.com/doc/refman/5.1/en/table-maintenance-sql.html),
or do you have something else in mind? 

Is it not a bit dangerous to let the uninitiated work against the prod database?
Is there at least a nightly or at least regular copy of the database which can be
restored in case something goes wrong? And if so where is it and how do I get hold
of it?

--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/20150213/fb258d4a/attachment.bin 

From gbadner at redhat.com  Fri Feb 13 20:13:52 2015
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 13 Feb 2015 20:13:52 -0500 (EST)
Subject: [hibernate-dev] in.relation.to error when posting a new blog
 entry
In-Reply-To: <20150213095321.GC77073@Sarmakand-4.local>
References: <CANoTJYNDL=YezU0rF8yq5n6ELyGb62QEX4VMzfQ-n=WVR2VryQ@mail.gmail.com>
	<2058705871.10879457.1423704976067.JavaMail.zimbra@redhat.com>
	<CAFm4XO3XNzBbbcLDG8iNV7bq_H9O-zSc4DZjERq4GXFmncZmrg@mail.gmail.com>
	<20150213095321.GC77073@Sarmakand-4.local>
Message-ID: <1577213149.12156742.1423876432646.JavaMail.zimbra@redhat.com>

Good questions. I'll wait for a reply...

----- Original Message -----
> From: "Hardy Ferentschik" <hardy at hibernate.org>
> To: "Sanne Grinovero" <sanne at hibernate.org>
> Cc: "Gail Badner" <gbadner at redhat.com>, "Davide D'Alto" <davide at hibernate.org>, "hibernate-dev"
> <hibernate-dev at lists.jboss.org>
> Sent: Friday, February 13, 2015 1:53:21 AM
> Subject: Re: [hibernate-dev] in.relation.to error when posting a new blog entry
> 
> On Thu, Feb 12, 2015 at 06:57:55AM +0000, Sanne Grinovero wrote:
> > I suspect it's a broken foreign key on MySQL, hopefully the error message
> > will have some details? Some table maintenance should do the trick.
> 
> Do you literally talk about the table maintenance commands like
> REPAIR TABLE
> (http://dev.mysql.com/doc/refman/5.1/en/table-maintenance-sql.html),
> or do you have something else in mind?
> 
> Is it not a bit dangerous to let the uninitiated work against the prod
> database?
> Is there at least a nightly or at least regular copy of the database which
> can be
> restored in case something goes wrong? And if so where is it and how do I get
> hold
> of it?
> 
> --Hardy
> 

From sanne at hibernate.org  Sat Feb 14 11:05:29 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 14 Feb 2015 16:05:29 +0000
Subject: [hibernate-dev] Enum object bound to SQLQuery
In-Reply-To: <1608293521.11584506.1423804530271.JavaMail.zimbra@redhat.com>
References: <83804758.11583742.1423804278230.JavaMail.zimbra@redhat.com>
	<1608293521.11584506.1423804530271.JavaMail.zimbra@redhat.com>
Message-ID: <CAFm4XO0uKwZPVUYpS0AUWgAVMEdXE_igb2zyZoBbfDk9qv-pGg@mail.gmail.com>

As a personal uninformed opinion, I would expect that when setting
parameters to a Native Query there would be no transformations.

I'm wondering if there is a (significant) population of users who
expect the opposite?

(BTW I didn't find the attachment, I think this list drops them..
better to attach them to a JIRA, so you can also use that to document
a decision?)

Sanne


On 13 February 2015 at 05:15, Gail Badner <gbadner at redhat.com> wrote:
> Should enum objects be converted to the appropriate type when bound to a native query?
>
> It looks like they are converted properly when bound using a Criteria or HQL Query, but not for a SQLQuery.
>
> Attached is a patch for EnumTypeTest that shows that it works for Criteria and HQL queries, and fails for SQLQuery.
>
> Is this a bug?
>
> Thanks,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From m.schipperheyn at gmail.com  Sun Feb 15 15:05:20 2015
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Sun, 15 Feb 2015 18:05:20 -0200
Subject: [hibernate-dev] CachingWrapperFilter
Message-ID: <CAGvEgx6e4V5WrpAHvSH2fHChQ9XdUZOCfh+NkOCUeqVtkCoZ-Q@mail.gmail.com>

Just wondering with Lucene 4 whether the Hibernate CachingWrapperFilter
should leverage that instead of using its own caching implementation. Given
the discussion in LUCENE-1536.

I'm not superfamiliar with this part of the code, but it looks like the
LUCENE-1536 allows optimization at a deeper level.

From sanne at hibernate.org  Mon Feb 16 11:07:12 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 16 Feb 2015 16:07:12 +0000
Subject: [hibernate-dev] CachingWrapperFilter
In-Reply-To: <CAGvEgx6e4V5WrpAHvSH2fHChQ9XdUZOCfh+NkOCUeqVtkCoZ-Q@mail.gmail.com>
References: <CAGvEgx6e4V5WrpAHvSH2fHChQ9XdUZOCfh+NkOCUeqVtkCoZ-Q@mail.gmail.com>
Message-ID: <CAFm4XO0qS7t3tFphyMOm-XwZBnt_Da-dwQvCKCvAK3KuaiRh3A@mail.gmail.com>

Hi Marc,
in theory we apply all the same optimisations as the "Lucene edition",
including the "acceptDocs" Bits as described in LUCENE-1536.

These are the main differences of our implementation:
 - uses the SoftLimitMRUCache rather than a synchronized WeakHashMap
 - uses Soft rather than Weak references
 - we do prevent duplicate computation for the same segments in case
of race conditions to prevent unnecessary CPU usage

Overall I'd expect this to perform better than the Lucene vanilla
version; that's probably not something I could state as an universal
truth but it's reasonable for our kind of integration. For example,
making those keys "weak" rather than "soft" would keep all filter
instances in memory, without any kind of upper bound: yes that might
look like "faster" in a couple of small tests but it's probably not
what you want!

Am I wrong? Please let me know if you've been measuring this and got
to different conclusions.

The drawback of soft keys is of course that in case you need a full gc
for other reasons, your cache is cleared. If that's your problem, we
should discuss about more advanced cache tuning options.

Sanne


On 15 February 2015 at 20:05, Marc Schipperheyn
<m.schipperheyn at gmail.com> wrote:
> Just wondering with Lucene 4 whether the Hibernate CachingWrapperFilter
> should leverage that instead of using its own caching implementation. Given
> the discussion in LUCENE-1536.
>
> I'm not superfamiliar with this part of the code, but it looks like the
> LUCENE-1536 allows optimization at a deeper level.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From emmanuel at hibernate.org  Mon Feb 16 11:33:44 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 16 Feb 2015 17:33:44 +0100
Subject: [hibernate-dev] Enum object bound to SQLQuery
In-Reply-To: <1608293521.11584506.1423804530271.JavaMail.zimbra@redhat.com>
References: <1608293521.11584506.1423804530271.JavaMail.zimbra@redhat.com>
Message-ID: <F6BA88F4-1E65-450F-B378-AB7350918350@hibernate.org>

Do we do any other conversion in SQLQueries from the property type to the SQL type? I don?t think we do.

> On 13 Feb 2015, at 06:15, Gail Badner <gbadner at redhat.com> wrote:
> 
> Should enum objects be converted to the appropriate type when bound to a native query?
> 
> It looks like they are converted properly when bound using a Criteria or HQL Query, but not for a SQLQuery.
> 
> Attached is a patch for EnumTypeTest that shows that it works for Criteria and HQL queries, and fails for SQLQuery.
> 
> Is this a bug?
> 
> Thanks,
> Gail_______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From steve at hibernate.org  Mon Feb 16 14:55:54 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 16 Feb 2015 13:55:54 -0600
Subject: [hibernate-dev] Enum object bound to SQLQuery
In-Reply-To: <F6BA88F4-1E65-450F-B378-AB7350918350@hibernate.org>
References: <1608293521.11584506.1423804530271.JavaMail.zimbra@redhat.com>
	<F6BA88F4-1E65-450F-B378-AB7350918350@hibernate.org>
Message-ID: <CAFdSV9sfyNVGCqqkJLUYeNOohy2BrRO53zuA6Um3_4DuLUmJ0g@mail.gmail.com>

Probably the difference is the idea of "auto determination" of a
parameter's "expected" Type.  In HQL/JPQL and Criteria queries I have a lot
of code in place to determine the expected type of a parameter based any
"corresponding property reference".  In native SQL queries there is no such
opportunity to perform this "auto determination".

On Mon, Feb 16, 2015 at 10:33 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> Do we do any other conversion in SQLQueries from the property type to the
> SQL type? I don?t think we do.
>
> > On 13 Feb 2015, at 06:15, Gail Badner <gbadner at redhat.com> wrote:
> >
> > Should enum objects be converted to the appropriate type when bound to a
> native query?
> >
> > It looks like they are converted properly when bound using a Criteria or
> HQL Query, but not for a SQLQuery.
> >
> > Attached is a patch for EnumTypeTest that shows that it works for
> Criteria and HQL queries, and fails for SQLQuery.
> >
> > Is this a bug?
> >
> > 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
>

From gbadner at redhat.com  Mon Feb 16 15:34:53 2015
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 16 Feb 2015 15:34:53 -0500 (EST)
Subject: [hibernate-dev] Enum object bound to SQLQuery
In-Reply-To: <CAFdSV9sfyNVGCqqkJLUYeNOohy2BrRO53zuA6Um3_4DuLUmJ0g@mail.gmail.com>
References: <1608293521.11584506.1423804530271.JavaMail.zimbra@redhat.com>
	<F6BA88F4-1E65-450F-B378-AB7350918350@hibernate.org>
	<CAFdSV9sfyNVGCqqkJLUYeNOohy2BrRO53zuA6Um3_4DuLUmJ0g@mail.gmail.com>
Message-ID: <401984172.13067037.1424118893145.JavaMail.zimbra@redhat.com>

OK, so this is expected.
Thanks!
Gail

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Emmanuel Bernard" <emmanuel at hibernate.org>
> Cc: "Gail Badner" <gbadner at redhat.com>, "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Monday, February 16, 2015 11:55:54 AM
> Subject: Re: [hibernate-dev] Enum object bound to SQLQuery
> 
> Probably the difference is the idea of "auto determination" of a
> parameter's "expected" Type.  In HQL/JPQL and Criteria queries I have a lot
> of code in place to determine the expected type of a parameter based any
> "corresponding property reference".  In native SQL queries there is no such
> opportunity to perform this "auto determination".
> 
> On Mon, Feb 16, 2015 at 10:33 AM, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> 
> > Do we do any other conversion in SQLQueries from the property type to the
> > SQL type? I don?t think we do.
> >
> > > On 13 Feb 2015, at 06:15, Gail Badner <gbadner at redhat.com> wrote:
> > >
> > > Should enum objects be converted to the appropriate type when bound to a
> > native query?
> > >
> > > It looks like they are converted properly when bound using a Criteria or
> > HQL Query, but not for a SQLQuery.
> > >
> > > Attached is a patch for EnumTypeTest that shows that it works for
> > Criteria and HQL queries, and fails for SQLQuery.
> > >
> > > Is this a bug?
> > >
> > > 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
> >
> 


From emmanuel at hibernate.org  Tue Feb 17 09:52:46 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 17 Feb 2015 15:52:46 +0100
Subject: [hibernate-dev] [HV] Meeting minutes
Message-ID: <20150217145246.GA59466@hibernate.org>

We discussed the HV release coming and dived into the custom constraint + resourcebundle solution.
This beast needs a better name.

Minutes:        http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-02-17-13.59.html
Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-02-17-13.59.txt
Log:            http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-02-17-13.59.log.html


From emond.papegaaij at topicus.nl  Wed Feb 18 07:53:49 2015
From: emond.papegaaij at topicus.nl (Emond Papegaaij)
Date: Wed, 18 Feb 2015 13:53:49 +0100
Subject: [hibernate-dev] Bad performance with collection fetching and
	@BatchSize (HHH-9592)
Message-ID: <5127059.ugIKndkdAt@papegaaij>

Hi all,

For the past few weeks, we've been struggling with bad performance caused by 
HHH-9592. In short, even with @BatchSize(size=100) on all entities, the vast 
majority of queries (up to 70%) is in the form of 'SELECT a, b, c FROM foo 
WHERE id=123'. As far as I can see, almost all of these queries are caused by 
PersistentBag.initializeFromCache.

This method assumes an entity can be loaded from cache if the collection that 
contains it, was loaded from cache. However, as entities and collections do 
not live in the cache together, this often is not the case. The current 
implementation triggers a separate query for every record that cannot be 
loaded from the cache, ignoring the @BatchSize on that entity.

As this issue is effecting of our application severely, I'm investigating 
possible solutions. Pre-fetching entities that are likely to be fetched later 
on in the request, in a separate query helps a bit, but requires a lot of 
work. So, I'm looking for a more fundamental solution. In the ideal world, 
Hibernate would fetch a full batch (100 in our case) at once, not only from 
the collection being loaded, but also from other collections with unloaded 
entities. Is this possible? If not, what can we do to improve the situation?

Best regards,
Emond Papegaaij

From emmanuel at hibernate.org  Fri Feb 20 05:07:11 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 20 Feb 2015 11:07:11 +0100
Subject: [hibernate-dev] [OGM] Sprint organization
Message-ID: <20150220100711.GA23252@hibernate.org>

I have walked through all of the issues and sorted what I think should
be done.

## Plan of action

Within these 3 weeks, we will do:

* 4.1.2 (bug fixes) -> code freeze Friday 27th
* 4.2 Alpha1 -> code freeze Friday 27th
* 4.2 Alpha2 or Beta we will see -> code freeze Friday 6th
* 4.2 Beta or CR we will see -> code freeze Wed 11th

The rookie team + me will work on the 4.1.2 tagged issues.
This work will continue even past the release of 4.1.2 but will be
likely incorporated into the 4.2 branch.

Davide and Gunnar will work on the 4.2 tagged issues.
It might make sense to have a single one focus on the numerous query
improvements and the other on the rest. See below.

Take the top issue of the list ordered by decreasing priority or one
with the same level of priority. Kill it. Move to the next.

## Priorities

For 4.1.2, I have sorted issues by decreasing importance with one little
twist. All issues created after a direct user feedback is marked
blocker. This is to speed our feedback loop time.

https://hibernate.atlassian.net/browse/OGM-740?jql=project%20%3D%20OGM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20%22Awaiting%20Test%20Case%22)%20AND%20fixVersion%20%3D%204.1.2%20ORDER%20BY%20priority%20DESC%2C%20updated%20ASC

For 4.2, it is also sorted by decreasing importance but I also gave the
release a theme.
The main focus is significantly improving JP-QL queries.
Secondary and must have target is the error report API.
Tertiary is everything else. That includes some improvements in ORM itself to unlock us.

There are too many tasks to address them all but let's first focus on
making a dent up to the major priority level.

Remarks?

Emmanuel

From davide at hibernate.org  Fri Feb 20 06:56:13 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Fri, 20 Feb 2015 11:56:13 +0000
Subject: [hibernate-dev] in.relation.to error when posting a new blog
	entry
In-Reply-To: <1577213149.12156742.1423876432646.JavaMail.zimbra@redhat.com>
References: <CANoTJYNDL=YezU0rF8yq5n6ELyGb62QEX4VMzfQ-n=WVR2VryQ@mail.gmail.com>
	<2058705871.10879457.1423704976067.JavaMail.zimbra@redhat.com>
	<CAFm4XO3XNzBbbcLDG8iNV7bq_H9O-zSc4DZjERq4GXFmncZmrg@mail.gmail.com>
	<20150213095321.GC77073@Sarmakand-4.local>
	<1577213149.12156742.1423876432646.JavaMail.zimbra@redhat.com>
Message-ID: <CANoTJYPUiU+oZhuwoyGTO-YKjixnE0TGhxs84szx09+34iiYHQ@mail.gmail.com>

I'm currently trying to fix it

On Sat, Feb 14, 2015 at 1:13 AM, Gail Badner <gbadner at redhat.com> wrote:

> Good questions. I'll wait for a reply...
>
> ----- Original Message -----
> > From: "Hardy Ferentschik" <hardy at hibernate.org>
> > To: "Sanne Grinovero" <sanne at hibernate.org>
> > Cc: "Gail Badner" <gbadner at redhat.com>, "Davide D'Alto" <
> davide at hibernate.org>, "hibernate-dev"
> > <hibernate-dev at lists.jboss.org>
> > Sent: Friday, February 13, 2015 1:53:21 AM
> > Subject: Re: [hibernate-dev] in.relation.to error when posting a new
> blog entry
> >
> > On Thu, Feb 12, 2015 at 06:57:55AM +0000, Sanne Grinovero wrote:
> > > I suspect it's a broken foreign key on MySQL, hopefully the error
> message
> > > will have some details? Some table maintenance should do the trick.
> >
> > Do you literally talk about the table maintenance commands like
> > REPAIR TABLE
> > (http://dev.mysql.com/doc/refman/5.1/en/table-maintenance-sql.html),
> > or do you have something else in mind?
> >
> > Is it not a bit dangerous to let the uninitiated work against the prod
> > database?
> > Is there at least a nightly or at least regular copy of the database
> which
> > can be
> > restored in case something goes wrong? And if so where is it and how do
> I get
> > hold
> > of it?
> >
> > --Hardy
> >
>

From sanne at hibernate.org  Fri Feb 20 07:34:32 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 20 Feb 2015 12:34:32 +0000
Subject: [hibernate-dev] in.relation.to error when posting a new blog
	entry
In-Reply-To: <CANoTJYPUiU+oZhuwoyGTO-YKjixnE0TGhxs84szx09+34iiYHQ@mail.gmail.com>
References: <CANoTJYNDL=YezU0rF8yq5n6ELyGb62QEX4VMzfQ-n=WVR2VryQ@mail.gmail.com>
	<2058705871.10879457.1423704976067.JavaMail.zimbra@redhat.com>
	<CAFm4XO3XNzBbbcLDG8iNV7bq_H9O-zSc4DZjERq4GXFmncZmrg@mail.gmail.com>
	<20150213095321.GC77073@Sarmakand-4.local>
	<1577213149.12156742.1423876432646.JavaMail.zimbra@redhat.com>
	<CANoTJYPUiU+oZhuwoyGTO-YKjixnE0TGhxs84szx09+34iiYHQ@mail.gmail.com>
Message-ID: <CAFm4XO0YSOm70L6J4V1wCV06QTrPZRUoSM7BEoq_2b7ny+hTJw@mail.gmail.com>

Thanks Davide :)

All: sorry I forgot the answer here. Still getting used to a new email client.
Since you work with databases professionally, I'm assuming you know
how to be careful. When you have console access to mysql, it's a one
liner to make your own backup, and it's two lines to create a staging
copy.

But also, I had put a daily snapshot job in place, so for most
operations there's no need to be too paranoid, I know nobody here will
type commands randomly.

Sanne

On 20 February 2015 at 11:56, Davide D'Alto <davide at hibernate.org> wrote:
> I'm currently trying to fix it
>
> On Sat, Feb 14, 2015 at 1:13 AM, Gail Badner <gbadner at redhat.com> wrote:
>>
>> Good questions. I'll wait for a reply...
>>
>> ----- Original Message -----
>> > From: "Hardy Ferentschik" <hardy at hibernate.org>
>> > To: "Sanne Grinovero" <sanne at hibernate.org>
>> > Cc: "Gail Badner" <gbadner at redhat.com>, "Davide D'Alto"
>> > <davide at hibernate.org>, "hibernate-dev"
>> > <hibernate-dev at lists.jboss.org>
>> > Sent: Friday, February 13, 2015 1:53:21 AM
>> > Subject: Re: [hibernate-dev] in.relation.to error when posting a new
>> > blog entry
>> >
>> > On Thu, Feb 12, 2015 at 06:57:55AM +0000, Sanne Grinovero wrote:
>> > > I suspect it's a broken foreign key on MySQL, hopefully the error
>> > > message
>> > > will have some details? Some table maintenance should do the trick.
>> >
>> > Do you literally talk about the table maintenance commands like
>> > REPAIR TABLE
>> > (http://dev.mysql.com/doc/refman/5.1/en/table-maintenance-sql.html),
>> > or do you have something else in mind?
>> >
>> > Is it not a bit dangerous to let the uninitiated work against the prod
>> > database?
>> > Is there at least a nightly or at least regular copy of the database
>> > which
>> > can be
>> > restored in case something goes wrong? And if so where is it and how do
>> > I get
>> > hold
>> > of it?
>> >
>> > --Hardy
>> >
>
>

From steve at hibernate.org  Fri Feb 20 13:57:37 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 20 Feb 2015 12:57:37 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <81CDE27F-838F-4E5E-AC78-AFA1623036CB@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>
	<CAFdSV9vAptaR6VySYNA0y5uzsTMiZMgvJaE7FRp6YZdeNk5J1g@mail.gmail.com>
	<CAFdSV9sRVd2sJU2rRt0UEWUfPnQEMdiYxjhrANniRpEF-jfDQg@mail.gmail.com>
	<E3BFFD6B-1BEE-45A7-9263-E76ED261A899@redhat.com>
	<CAFdSV9sADREy6ohG9av04CVQsK0SrskmAUq_i0gHUPCOBRu5yA@mail.gmail.com>
	<CAFdSV9sqsSL9tJc1GYin1uy9w30a=KjT6JMQKC85fViyZpx4DA@mail.gmail.com>
	<D911A508-D141-4E73-9FDF-3220B315F262@hibernate.org>
	<CAFdSV9u9_xL3-EOuwRRHRje0i0keAPV09rz1-sZSMRSiaX1UOg@mail.gmail.com>
	<57070315-9CB3-4CCF-84AB-5039172C7A18@hibernate.org>
	<CAFdSV9tfdBgnAdaPJq9vrGVtJmhHSQhPEO8WBT=0oE_JmYa1dw@mail.gmail.com>
	<81CDE27F-838F-4E5E-AC78-AFA1623036CB@hibernate.org>
Message-ID: <CAFdSV9veYJjk25OeiLAYbhcVuwHuQnFw5jAGzbf6o5kTkzBp6g@mail.gmail.com>

So at the moment I have the following ImplicitNamingStrategy impls:

1) ImplicitNamingStrategyStandardImpl - Which is compliant with the rules
set forth in the JPA standard
2) ImplicitNamingStrategyLegacyJpaImpl - Which implements the initial
support done for JPA 1, before JPA 2 clarified some things.
3) ImplicitNamingStrategyLegacyHbmImpl - Support dating back to the dawn of
time...
4) ImplicitNamingStrategyComponentSafeImpl - Mainly a port
of DefaultComponentSafeNamingStrategy, although leveraging the
AttributePath stuff I discussed earlier

Couple of thoughts...

First, we might want to rename ImplicitNamingStrategyLegacyJpaImpl to
ImplicitNamingStrategyStandardImpl, and ImplicitNamingStrategyStandardImpl
to ImplicitNamingStrategyJpaCompliantImpl.  WDYT?

Second, I do not really like the phrase "component safe".  "Safe" from
what?  The difference is that the whole component path is used in
determining the name; so how about ImplicitNamingStrategyComponentPathImpl?

I do not plan on porting any of the other NamingStrategy impls.


Also, here is the complete list of implicit naming hooks:
1) primary table
2) join table
3) collection table
4) discriminator column
5) tenant id column
6) id column (entity and idbag)
7) basic column
8) join column
9) pk join column
10 ) @Any discriminator column
11) @Any key column
12) map key column
13) list index column
14) foreign key name
15) unique key name
16) index name


On Mon, Feb 2, 2015 at 3:13 PM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> I?d say +1 for adding coverage of them in the implicit naming strategy.
>
> On 02 Feb 2015, at 19:16, Steve Ebersole <steve at hibernate.org> wrote:
>
> They do not.  HBM, e.g., uses "idx" for map keys columns as well as
> list/array index columns.  JPA says to use {attribute-name}_ORDER for list
> index column.  Unless I missed it (which is completely possible in
> annotation binding) we always use the JPA-defined default in those cases
> rather than using any *implicit* naming hooks.
>
> So that is really the question.  Do we want expand the breadth of what is
> covered by implicit naming strategy in this new model?  I think its
> reasonable.
>
> On Mon, Feb 2, 2015 at 11:28 AM, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>
>>
>> On 02 Feb 2015, at 17:51, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> On Mon, Feb 2, 2015 at 8:34 AM, Emmanuel Bernard <emmanuel at hibernate.org>
>>  wrote:
>>
>> I think you?re missing things like @MapKeyColumn, @OrderColumn
>>>
>>
>> So that's a good discussion.  These are things that have previously been
>> hard-coded defaults (at least on hbm side) and therefore had no specific
>> naming strategy hooks.  I'm all for being specific, so if everyone agrees
>> it is a good idea to add methods for stuff like this, I am fine with that.
>>
>>
>> I know JPA has well defined values for these. I am not sure they match
>> 100% the HBM version.
>>
>
>
>

From gunnar at hibernate.org  Mon Feb 23 03:15:26 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 23 Feb 2015 09:15:26 +0100
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <20150220100711.GA23252@hibernate.org>
References: <20150220100711.GA23252@hibernate.org>
Message-ID: <CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>

Hi,

Thanks for grooming the backlog and preparing these releases!

I'm curious how the weekly release scheme is going to work out. In the last
two sprints we created none (although I thought we wanted to release HS?)
and one (HV, as planned) release. Planning for four releases now may be
over-stretching it a bit, esp. when splitting up powers as we do in the
first week. I would have planned for 4.1.2 and a 4.2 release.

As you say, it's too many issues, we will not be able to do them all.
Personally, I like a realistic schedule more, IMO it gives you a better
sense of achievement if you actually managed to tackle what you had
planned. Now we'll more likely get the feeling that we failed to do half of
the things planned (as we know that's expected, still I find it
sub-optimal).

The 4.1.2/4.2 release split make sense. It may be a good idea to either
pull you, Emmanuel, or Sanne (which I wouldn't count as a newbie in terms
of OGM) over to 4.2 issues at some stage, depending on the progress we make
with the respective backlogs.

Nice to have the five of us working on OGM, looking forward to get new
functionality out there!

--Gunnar




2015-02-20 11:07 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> I have walked through all of the issues and sorted what I think should
> be done.
>
> ## Plan of action
>
> Within these 3 weeks, we will do:
>
> * 4.1.2 (bug fixes) -> code freeze Friday 27th
> * 4.2 Alpha1 -> code freeze Friday 27th
> * 4.2 Alpha2 or Beta we will see -> code freeze Friday 6th
> * 4.2 Beta or CR we will see -> code freeze Wed 11th
>
> The rookie team + me will work on the 4.1.2 tagged issues.
> This work will continue even past the release of 4.1.2 but will be
> likely incorporated into the 4.2 branch.
>
> Davide and Gunnar will work on the 4.2 tagged issues.
> It might make sense to have a single one focus on the numerous query
> improvements and the other on the rest. See below.
>
> Take the top issue of the list ordered by decreasing priority or one
> with the same level of priority. Kill it. Move to the next.
>
> ## Priorities
>
> For 4.1.2, I have sorted issues by decreasing importance with one little
> twist. All issues created after a direct user feedback is marked
> blocker. This is to speed our feedback loop time.
>
>
> https://hibernate.atlassian.net/browse/OGM-740?jql=project%20%3D%20OGM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20%22Awaiting%20Test%20Case%22)%20AND%20fixVersion%20%3D%204.1.2%20ORDER%20BY%20priority%20DESC%2C%20updated%20ASC
>
> For 4.2, it is also sorted by decreasing importance but I also gave the
> release a theme.
> The main focus is significantly improving JP-QL queries.
> Secondary and must have target is the error report API.
> Tertiary is everything else. That includes some improvements in ORM itself
> to unlock us.
>
> There are too many tasks to address them all but let's first focus on
> making a dent up to the major priority level.
>
> Remarks?
>
> 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 Feb 23 03:40:27 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 23 Feb 2015 09:40:27 +0100
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
References: <20150220100711.GA23252@hibernate.org>
	<CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
Message-ID: <CADGJaX8m=VCE9g+F5cJcQu2DBmK98d62eSOitwjV=sSf2B0PHQ@mail.gmail.com>

Hey,

Some pointers for those who haven't worked on the OGM code base in a while:

* Contribution guide: http://hibernate.org/ogm/contribute/
* Build instructions: in the readme.md in the root dir;
* You need to install CouchDB separately and configure the COUCHDB_HOSTNAME
env variable if you want to test that backend; By default only the code of
this module is compiled
* When running the CLI build, MongoDB is started and stopped automatically
via Maven. For running a test against MongoDB from within you IDE, MongoDB
needs to be installed and started separately.
* There are two types of tests in core: a) unit tests for stuff in core
itself and b) the "backendtck" which are high-level (i.e. Session/EM-level)
tests and which are executed for all backends. To run a specific test
against a specific store in your IDE, simplest is to copy it into that
project and run it from there.
* Packages are organized with the SPI/impl split at the lowest level (I was
talked into that ;). SPI is geared towards grid dialect implementors. The
split is not complete yet, at some parts "our" dialects refer to "impl"
classes from core. Anything not "spi" or "impl" is public API. Naturally,
that's not very much though as OGM's main user API is JPA/Hibernate ORM.
The main thing is the configuration API.

Let me know in case there is anything I can help with to get you started.

--Gunnar


2015-02-23 9:15 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:

> Hi,
>
> Thanks for grooming the backlog and preparing these releases!
>
> I'm curious how the weekly release scheme is going to work out. In the
> last two sprints we created none (although I thought we wanted to release
> HS?) and one (HV, as planned) release. Planning for four releases now may
> be over-stretching it a bit, esp. when splitting up powers as we do in the
> first week. I would have planned for 4.1.2 and a 4.2 release.
>
> As you say, it's too many issues, we will not be able to do them all.
> Personally, I like a realistic schedule more, IMO it gives you a better
> sense of achievement if you actually managed to tackle what you had
> planned. Now we'll more likely get the feeling that we failed to do half of
> the things planned (as we know that's expected, still I find it
> sub-optimal).
>
> The 4.1.2/4.2 release split make sense. It may be a good idea to either
> pull you, Emmanuel, or Sanne (which I wouldn't count as a newbie in terms
> of OGM) over to 4.2 issues at some stage, depending on the progress we make
> with the respective backlogs.
>
> Nice to have the five of us working on OGM, looking forward to get new
> functionality out there!
>
> --Gunnar
>
>
>
>
> 2015-02-20 11:07 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>
>> I have walked through all of the issues and sorted what I think should
>> be done.
>>
>> ## Plan of action
>>
>> Within these 3 weeks, we will do:
>>
>> * 4.1.2 (bug fixes) -> code freeze Friday 27th
>> * 4.2 Alpha1 -> code freeze Friday 27th
>> * 4.2 Alpha2 or Beta we will see -> code freeze Friday 6th
>> * 4.2 Beta or CR we will see -> code freeze Wed 11th
>>
>> The rookie team + me will work on the 4.1.2 tagged issues.
>> This work will continue even past the release of 4.1.2 but will be
>> likely incorporated into the 4.2 branch.
>>
>> Davide and Gunnar will work on the 4.2 tagged issues.
>> It might make sense to have a single one focus on the numerous query
>> improvements and the other on the rest. See below.
>>
>> Take the top issue of the list ordered by decreasing priority or one
>> with the same level of priority. Kill it. Move to the next.
>>
>> ## Priorities
>>
>> For 4.1.2, I have sorted issues by decreasing importance with one little
>> twist. All issues created after a direct user feedback is marked
>> blocker. This is to speed our feedback loop time.
>>
>>
>> https://hibernate.atlassian.net/browse/OGM-740?jql=project%20%3D%20OGM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20%22Awaiting%20Test%20Case%22)%20AND%20fixVersion%20%3D%204.1.2%20ORDER%20BY%20priority%20DESC%2C%20updated%20ASC
>>
>> For 4.2, it is also sorted by decreasing importance but I also gave the
>> release a theme.
>> The main focus is significantly improving JP-QL queries.
>> Secondary and must have target is the error report API.
>> Tertiary is everything else. That includes some improvements in ORM
>> itself to unlock us.
>>
>> There are too many tasks to address them all but let's first focus on
>> making a dent up to the major priority level.
>>
>> Remarks?
>>
>> Emmanuel
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From emmanuel at hibernate.org  Mon Feb 23 03:59:11 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 23 Feb 2015 09:59:11 +0100
Subject: [hibernate-dev] Fwd: Hibernate Assist Open Source Query Analysis
	Tool
References: <CANw7q3aQc3pSRN49Dv1GoNsW8bSM=pODcWB1JCMD6Z002C27rA@mail.gmail.com>
Message-ID: <6E160B0E-5F30-49B4-A946-C7C76A045731@hibernate.org>

Hi Vicky,

I?m not sure what you are asking is super easy (nor that we are ready to commit an API to it) but I?ll let Steve comment.

Emmanuel

PS your attachement has been removed, any chance you can host it somewhere on a webserver?

> Begin forwarded message:
> 
> From: Vicky Thakor <vicky.thakor at javaquery.com>
> Date: 22 Feb 2015 19:23:24 CET
> Subject: Hibernate Assist Open Source Query Analysis Tool
> To: [?]
> 
> There was an attachment in this email that has been removed due to security restrictions. Email with attachments containing Microsoft Windows executable files inside archives are not permitted.
> Dear Hibernate Team,
> I'm Vicky Thakor from Gujarat, India. I'm working on Query Analysis tool called HibernateAssist. HibernateAssist helps developer to understand how query executed at database level and what could be done to improve the query performance. 
> 
> What have been done so far?
> Thats good question. Using Hibernate built-in methods I extracted Query from Criteria and used that query to get execution plan from Microsoft SQL Server. 
> 
> Now I parse that XML and generate HTML report with same graphical representation that Microsoft SQL Server generates. All node contains basic information like Index Scanned, Index Seek, Predicate, Estimated I/O, CPU Cost, etc...
> 
> I've attached sample HTML report with this email please take a look at that.
> 
> What I require from you?
> As I said Hibernate built-in methods allows to extract Query from Criteria only. I want query generated by saveOrUpdate(Object) and delete(Object) so I can use that query to get Execution Plan from Microsoft SQL Server. If you guys can make this possible for developer like me than it'd be great help. 
> 
> Hibernate Assist
> Hibernate Assist, is an open source query analysis tool so I'm not making money out of it. I just wanna help developers to understand the query execution at database level.
> 
> Useful links
> I'm also a part time blogger and write articles on Programming Languages here you can find about me...
> 
> Blog: www.javaquery.com <http://www.javaquery.com/>
> HIbernateAssist: http://www.javaquery.com/p/hibernateassist.html <http://www.javaquery.com/p/hibernateassist.html>
> HibernateAssist GitHub: http://github.com/javaquery/HibernateAssist <http://github.com/javaquery/HibernateAssist>
> 
> 
> -- 
> Regards,
> Vicky


From emmanuel at hibernate.org  Mon Feb 23 04:25:59 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 23 Feb 2015 10:25:59 +0100
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <CADGJaX8m=VCE9g+F5cJcQu2DBmK98d62eSOitwjV=sSf2B0PHQ@mail.gmail.com>
References: <20150220100711.GA23252@hibernate.org>
	<CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
	<CADGJaX8m=VCE9g+F5cJcQu2DBmK98d62eSOitwjV=sSf2B0PHQ@mail.gmail.com>
Message-ID: <20150223092559.GA706@hibernate.org>

Nice, thanks. I have updated the contribute page with that content.
http://hibernate.org/ogm/contribute/

On Mon 2015-02-23  9:40, Gunnar Morling wrote:
> Hey,
> 
> Some pointers for those who haven't worked on the OGM code base in a while:
> 
> * Contribution guide: http://hibernate.org/ogm/contribute/
> * Build instructions: in the readme.md in the root dir;
> * You need to install CouchDB separately and configure the COUCHDB_HOSTNAME
> env variable if you want to test that backend; By default only the code of
> this module is compiled
> * When running the CLI build, MongoDB is started and stopped automatically
> via Maven. For running a test against MongoDB from within you IDE, MongoDB
> needs to be installed and started separately.
> * There are two types of tests in core: a) unit tests for stuff in core
> itself and b) the "backendtck" which are high-level (i.e. Session/EM-level)
> tests and which are executed for all backends. To run a specific test
> against a specific store in your IDE, simplest is to copy it into that
> project and run it from there.
> * Packages are organized with the SPI/impl split at the lowest level (I was
> talked into that ;). SPI is geared towards grid dialect implementors. The
> split is not complete yet, at some parts "our" dialects refer to "impl"
> classes from core. Anything not "spi" or "impl" is public API. Naturally,
> that's not very much though as OGM's main user API is JPA/Hibernate ORM.
> The main thing is the configuration API.
> 
> Let me know in case there is anything I can help with to get you started.
> 
> --Gunnar
> 
> 
> 2015-02-23 9:15 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:
> 
> > Hi,
> >
> > Thanks for grooming the backlog and preparing these releases!
> >
> > I'm curious how the weekly release scheme is going to work out. In the
> > last two sprints we created none (although I thought we wanted to release
> > HS?) and one (HV, as planned) release. Planning for four releases now may
> > be over-stretching it a bit, esp. when splitting up powers as we do in the
> > first week. I would have planned for 4.1.2 and a 4.2 release.
> >
> > As you say, it's too many issues, we will not be able to do them all.
> > Personally, I like a realistic schedule more, IMO it gives you a better
> > sense of achievement if you actually managed to tackle what you had
> > planned. Now we'll more likely get the feeling that we failed to do half of
> > the things planned (as we know that's expected, still I find it
> > sub-optimal).
> >
> > The 4.1.2/4.2 release split make sense. It may be a good idea to either
> > pull you, Emmanuel, or Sanne (which I wouldn't count as a newbie in terms
> > of OGM) over to 4.2 issues at some stage, depending on the progress we make
> > with the respective backlogs.
> >
> > Nice to have the five of us working on OGM, looking forward to get new
> > functionality out there!
> >
> > --Gunnar
> >
> >
> >
> >
> > 2015-02-20 11:07 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> >
> >> I have walked through all of the issues and sorted what I think should
> >> be done.
> >>
> >> ## Plan of action
> >>
> >> Within these 3 weeks, we will do:
> >>
> >> * 4.1.2 (bug fixes) -> code freeze Friday 27th
> >> * 4.2 Alpha1 -> code freeze Friday 27th
> >> * 4.2 Alpha2 or Beta we will see -> code freeze Friday 6th
> >> * 4.2 Beta or CR we will see -> code freeze Wed 11th
> >>
> >> The rookie team + me will work on the 4.1.2 tagged issues.
> >> This work will continue even past the release of 4.1.2 but will be
> >> likely incorporated into the 4.2 branch.
> >>
> >> Davide and Gunnar will work on the 4.2 tagged issues.
> >> It might make sense to have a single one focus on the numerous query
> >> improvements and the other on the rest. See below.
> >>
> >> Take the top issue of the list ordered by decreasing priority or one
> >> with the same level of priority. Kill it. Move to the next.
> >>
> >> ## Priorities
> >>
> >> For 4.1.2, I have sorted issues by decreasing importance with one little
> >> twist. All issues created after a direct user feedback is marked
> >> blocker. This is to speed our feedback loop time.
> >>
> >>
> >> https://hibernate.atlassian.net/browse/OGM-740?jql=project%20%3D%20OGM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20%22Awaiting%20Test%20Case%22)%20AND%20fixVersion%20%3D%204.1.2%20ORDER%20BY%20priority%20DESC%2C%20updated%20ASC
> >>
> >> For 4.2, it is also sorted by decreasing importance but I also gave the
> >> release a theme.
> >> The main focus is significantly improving JP-QL queries.
> >> Secondary and must have target is the error report API.
> >> Tertiary is everything else. That includes some improvements in ORM
> >> itself to unlock us.
> >>
> >> There are too many tasks to address them all but let's first focus on
> >> making a dent up to the major priority level.
> >>
> >> Remarks?
> >>
> >> Emmanuel
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> >

From emmanuel at hibernate.org  Mon Feb 23 04:33:08 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 23 Feb 2015 10:33:08 +0100
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9veYJjk25OeiLAYbhcVuwHuQnFw5jAGzbf6o5kTkzBp6g@mail.gmail.com>
References: <CAFdSV9sRVd2sJU2rRt0UEWUfPnQEMdiYxjhrANniRpEF-jfDQg@mail.gmail.com>
	<E3BFFD6B-1BEE-45A7-9263-E76ED261A899@redhat.com>
	<CAFdSV9sADREy6ohG9av04CVQsK0SrskmAUq_i0gHUPCOBRu5yA@mail.gmail.com>
	<CAFdSV9sqsSL9tJc1GYin1uy9w30a=KjT6JMQKC85fViyZpx4DA@mail.gmail.com>
	<D911A508-D141-4E73-9FDF-3220B315F262@hibernate.org>
	<CAFdSV9u9_xL3-EOuwRRHRje0i0keAPV09rz1-sZSMRSiaX1UOg@mail.gmail.com>
	<57070315-9CB3-4CCF-84AB-5039172C7A18@hibernate.org>
	<CAFdSV9tfdBgnAdaPJq9vrGVtJmhHSQhPEO8WBT=0oE_JmYa1dw@mail.gmail.com>
	<81CDE27F-838F-4E5E-AC78-AFA1623036CB@hibernate.org>
	<CAFdSV9veYJjk25OeiLAYbhcVuwHuQnFw5jAGzbf6o5kTkzBp6g@mail.gmail.com>
Message-ID: <20150223093308.GB706@hibernate.org>

Which one do you intend being the default?
In 4.x AFAIR, it was

* ImplicitNamingStrategyLegacyHbmImpl's behavior if you started ORM with the classic APIs.
* ImplicitNamingStrategyLegacyJpaImpl's behavior if you started ORM via the JPA APIS (or was it ImplicitNamingStrategyStandardImpl?)

About names, I'm tempted to have:

* ImplicitNamingStrategyJpaCompliantImpl
* ImplicitNamingStrategyLegacyJpaImpl
* ImplicitNamingStrategyLegacyHbmImpl
* ImplicitNamingStrategyComponentPathImpl

The idea is to make the names explicit with the intent. "Standard" does
not mean much per se.

Emmanuel

On Fri 2015-02-20 12:57, Steve Ebersole wrote:
> So at the moment I have the following ImplicitNamingStrategy impls:
> 
> 1) ImplicitNamingStrategyStandardImpl - Which is compliant with the rules
> set forth in the JPA standard
> 2) ImplicitNamingStrategyLegacyJpaImpl - Which implements the initial
> support done for JPA 1, before JPA 2 clarified some things.
> 3) ImplicitNamingStrategyLegacyHbmImpl - Support dating back to the dawn of
> time...
> 4) ImplicitNamingStrategyComponentSafeImpl - Mainly a port
> of DefaultComponentSafeNamingStrategy, although leveraging the
> AttributePath stuff I discussed earlier
> 
> Couple of thoughts...
> 
> First, we might want to rename ImplicitNamingStrategyLegacyJpaImpl to
> ImplicitNamingStrategyStandardImpl, and ImplicitNamingStrategyStandardImpl
> to ImplicitNamingStrategyJpaCompliantImpl.  WDYT?
> 
> Second, I do not really like the phrase "component safe".  "Safe" from
> what?  The difference is that the whole component path is used in
> determining the name; so how about ImplicitNamingStrategyComponentPathImpl?
> 
> I do not plan on porting any of the other NamingStrategy impls.
> 
> 
> Also, here is the complete list of implicit naming hooks:
> 1) primary table
> 2) join table
> 3) collection table
> 4) discriminator column
> 5) tenant id column
> 6) id column (entity and idbag)
> 7) basic column
> 8) join column
> 9) pk join column
> 10 ) @Any discriminator column
> 11) @Any key column
> 12) map key column
> 13) list index column
> 14) foreign key name
> 15) unique key name
> 16) index name
> 
> 
> On Mon, Feb 2, 2015 at 3:13 PM, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> 
> > I?d say +1 for adding coverage of them in the implicit naming strategy.
> >
> > On 02 Feb 2015, at 19:16, Steve Ebersole <steve at hibernate.org> wrote:
> >
> > They do not.  HBM, e.g., uses "idx" for map keys columns as well as
> > list/array index columns.  JPA says to use {attribute-name}_ORDER for list
> > index column.  Unless I missed it (which is completely possible in
> > annotation binding) we always use the JPA-defined default in those cases
> > rather than using any *implicit* naming hooks.
> >
> > So that is really the question.  Do we want expand the breadth of what is
> > covered by implicit naming strategy in this new model?  I think its
> > reasonable.
> >
> > On Mon, Feb 2, 2015 at 11:28 AM, Emmanuel Bernard <emmanuel at hibernate.org>
> > wrote:
> >
> >>
> >> On 02 Feb 2015, at 17:51, Steve Ebersole <steve at hibernate.org> wrote:
> >>
> >> On Mon, Feb 2, 2015 at 8:34 AM, Emmanuel Bernard <emmanuel at hibernate.org>
> >>  wrote:
> >>
> >> I think you?re missing things like @MapKeyColumn, @OrderColumn
> >>>
> >>
> >> So that's a good discussion.  These are things that have previously been
> >> hard-coded defaults (at least on hbm side) and therefore had no specific
> >> naming strategy hooks.  I'm all for being specific, so if everyone agrees
> >> it is a good idea to add methods for stuff like this, I am fine with that.
> >>
> >>
> >> I know JPA has well defined values for these. I am not sure they match
> >> 100% the HBM version.
> >>
> >
> >
> >

From hardy at hibernate.org  Mon Feb 23 04:40:58 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 23 Feb 2015 10:40:58 +0100
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
References: <20150220100711.GA23252@hibernate.org>
	<CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
Message-ID: <20150223094058.GA58413@Sarmakand-4.local>

Hi,

On Mon, Feb 23, 2015 at 09:15:26AM +0100, Gunnar Morling wrote:

> I'm curious how the weekly release scheme is going to work out. In the last
> two sprints we created none (although I thought we wanted to release HS?)
> and one (HV, as planned) release. Planning for four releases now may be
> over-stretching it a bit, esp. when splitting up powers as we do in the
> first week. I would have planned for 4.1.2 and a 4.2 release.

I agree. I was surprised to see 4 schedules releases for this sprint.
I have a hard time seeing this as realistic and to a certain degree scary.

> As you say, it's too many issues, we will not be able to do them all.
> Personally, I like a realistic schedule more, IMO it gives you a better
> sense of achievement if you actually managed to tackle what you had
> planned. 

+1

> Now we'll more likely get the feeling that we failed to do half of
> the things planned (as we know that's expected, still I find it
> sub-optimal).

+1 

I started with compiling the OGM code base and now need to set it up
in my IDE and read some docs. Once I am a bit more familiar with all I'll
pick an issue from the list.

Before that though, I need to finish the Validator blog? What is the status 
on in.relation.to? Can one create blog entries again?

--Hardy

P.S.: I know this might not go down so well, but depending on the state
of in.relation.to we might have to consider to put some effort into the blog
conversion.



-------------- 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/20150223/310a4be7/attachment.bin 

From emmanuel at hibernate.org  Mon Feb 23 04:46:55 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 23 Feb 2015 10:46:55 +0100
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
References: <20150220100711.GA23252@hibernate.org>
	<CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
Message-ID: <20150223094655.GA4153@hibernate.org>

On Mon 2015-02-23  9:15, Gunnar Morling wrote:
> Hi,
> 
> Thanks for grooming the backlog and preparing these releases!
> 
> I'm curious how the weekly release scheme is going to work out. In the last
> two sprints we created none (although I thought we wanted to release HS?)
> and one (HV, as planned) release. Planning for four releases now may be
> over-stretching it a bit, esp. when splitting up powers as we do in the
> first week. I would have planned for 4.1.2 and a 4.2 release.

Let's see how much we can crank this week.
You guys keep telling me doing a release does not take much time per se.

4.1.2 is easy I think. The challenge is 4.2.0.Alpha1, but let's decide
later this week and code first.

> As you say, it's too many issues, we will not be able to do them all.
> Personally, I like a realistic schedule more, IMO it gives you a better
> sense of achievement if you actually managed to tackle what you had
> planned. Now we'll more likely get the feeling that we failed to do half of
> the things planned (as we know that's expected, still I find it
> sub-optimal).

My problem was, when do I stop ? 1 issue, 7 issues, 42 issues ?
Let's code and see how far we are end of each week.

> 
> The 4.1.2/4.2 release split make sense. It may be a good idea to either
> pull you, Emmanuel, or Sanne (which I wouldn't count as a newbie in terms
> of OGM) over to 4.2 issues at some stage, depending on the progress we make
> with the respective backlogs.

Yes that was my idea as well but the email was getting too long.

From daltodavide at gmail.com  Mon Feb 23 04:50:57 2015
From: daltodavide at gmail.com (Davide D'Alto)
Date: Mon, 23 Feb 2015 09:50:57 +0000
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <20150223094058.GA58413@Sarmakand-4.local>
References: <20150220100711.GA23252@hibernate.org>
	<CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
	<20150223094058.GA58413@Sarmakand-4.local>
Message-ID: <CANoTJYNBnfJ7MS3-RBKtxToa3oOPc7xVMdFNtvfc9=NwFMk3xw@mail.gmail.com>

> Before that though, I need to finish the Validator blog? What is the
status on in.relation.to? Can one create blog entries again?

in.relation.to it stills not working and I'm not sure how to solve the
issue.

The content in the db seems correct and I think the problem is related to
some operations
it's trying to perform on the db. It seems it's trying to delete a comment
and it is failing.

I'm open to suggestion.


On Mon, Feb 23, 2015 at 9:40 AM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> On Mon, Feb 23, 2015 at 09:15:26AM +0100, Gunnar Morling wrote:
>
> > I'm curious how the weekly release scheme is going to work out. In the
> last
> > two sprints we created none (although I thought we wanted to release HS?)
> > and one (HV, as planned) release. Planning for four releases now may be
> > over-stretching it a bit, esp. when splitting up powers as we do in the
> > first week. I would have planned for 4.1.2 and a 4.2 release.
>
> I agree. I was surprised to see 4 schedules releases for this sprint.
> I have a hard time seeing this as realistic and to a certain degree scary.
>
> > As you say, it's too many issues, we will not be able to do them all.
> > Personally, I like a realistic schedule more, IMO it gives you a better
> > sense of achievement if you actually managed to tackle what you had
> > planned.
>
> +1
>
> > Now we'll more likely get the feeling that we failed to do half of
> > the things planned (as we know that's expected, still I find it
> > sub-optimal).
>
> +1
>
> I started with compiling the OGM code base and now need to set it up
> in my IDE and read some docs. Once I am a bit more familiar with all I'll
> pick an issue from the list.
>
> Before that though, I need to finish the Validator blog? What is the status
> on in.relation.to? Can one create blog entries again?
>
> --Hardy
>
> P.S.: I know this might not go down so well, but depending on the state
> of in.relation.to we might have to consider to put some effort into the
> blog
> conversion.
>
>
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Mon Feb 23 05:40:19 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 23 Feb 2015 11:40:19 +0100
Subject: [hibernate-dev] [OGM] Moving to Java 7
Message-ID: <CADGJaX9aVme-oOfTHBVqeSrko_zijB9vPhTmtmMQi4WrUjpkkQ@mail.gmail.com>

Hi,

So far Hibernate OGM has been usable quite well when running on Java 6. But
as more and more of our dependencies require Java 7, the number of cases
where 6 is sufficient, decreases.

With two out of four backends (Infinispan and Neo4j) as well as HSEARCH
requiring 7 by now, I think it's about time to move on and take advantage
of 7 ourselves as well.

Are there any objections?

Thanks,

--Gunnar

From daltodavide at gmail.com  Mon Feb 23 05:46:16 2015
From: daltodavide at gmail.com (Davide D'Alto)
Date: Mon, 23 Feb 2015 10:46:16 +0000
Subject: [hibernate-dev] [OGM] Moving to Java 7
In-Reply-To: <CADGJaX9aVme-oOfTHBVqeSrko_zijB9vPhTmtmMQi4WrUjpkkQ@mail.gmail.com>
References: <CADGJaX9aVme-oOfTHBVqeSrko_zijB9vPhTmtmMQi4WrUjpkkQ@mail.gmail.com>
Message-ID: <CANoTJYNziyLW7HJ1wjtYz=if7A86NSR0OnD3jyQ_muRAbPcUsw@mail.gmail.com>

+1

Let's move to java 7

On Mon, Feb 23, 2015 at 10:40 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> So far Hibernate OGM has been usable quite well when running on Java 6. But
> as more and more of our dependencies require Java 7, the number of cases
> where 6 is sufficient, decreases.
>
> With two out of four backends (Infinispan and Neo4j) as well as HSEARCH
> requiring 7 by now, I think it's about time to move on and take advantage
> of 7 ourselves as well.
>
> Are there any objections?
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Mon Feb 23 05:56:45 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 23 Feb 2015 10:56:45 +0000
Subject: [hibernate-dev] [OGM] Moving to Java 7
In-Reply-To: <CANoTJYNziyLW7HJ1wjtYz=if7A86NSR0OnD3jyQ_muRAbPcUsw@mail.gmail.com>
References: <CADGJaX9aVme-oOfTHBVqeSrko_zijB9vPhTmtmMQi4WrUjpkkQ@mail.gmail.com>
	<CANoTJYNziyLW7HJ1wjtYz=if7A86NSR0OnD3jyQ_muRAbPcUsw@mail.gmail.com>
Message-ID: <CAFm4XO1PvEctXFCthNrKhV1Wtf4_vw=z=UoRzWEfQqXuFM+jRQ@mail.gmail.com>

+1

Also related:
http://lists.jboss.org/pipermail/hibernate-dev/2013-October/010490.html

On 23 February 2015 at 10:46, Davide D'Alto <daltodavide at gmail.com> wrote:
> +1
>
> Let's move to java 7
>
> On Mon, Feb 23, 2015 at 10:40 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Hi,
>>
>> So far Hibernate OGM has been usable quite well when running on Java 6. But
>> as more and more of our dependencies require Java 7, the number of cases
>> where 6 is sufficient, decreases.
>>
>> With two out of four backends (Infinispan and Neo4j) as well as HSEARCH
>> requiring 7 by now, I think it's about time to move on and take advantage
>> of 7 ourselves as well.
>>
>> Are there any objections?
>>
>> Thanks,
>>
>> --Gunnar
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From hardy at hibernate.org  Mon Feb 23 06:32:40 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 23 Feb 2015 12:32:40 +0100
Subject: [hibernate-dev] [OGM] Moving to Java 7
In-Reply-To: <CADGJaX9aVme-oOfTHBVqeSrko_zijB9vPhTmtmMQi4WrUjpkkQ@mail.gmail.com>
References: <CADGJaX9aVme-oOfTHBVqeSrko_zijB9vPhTmtmMQi4WrUjpkkQ@mail.gmail.com>
Message-ID: <20150223113240.GB58413@Sarmakand-4.local>

sure +1


On Mon, Feb 23, 2015 at 11:40:19AM +0100, Gunnar Morling wrote:
> Hi,
> 
> So far Hibernate OGM has been usable quite well when running on Java 6. But
> as more and more of our dependencies require Java 7, the number of cases
> where 6 is sufficient, decreases.
> 
> With two out of four backends (Infinispan and Neo4j) as well as HSEARCH
> requiring 7 by now, I think it's about time to move on and take advantage
> of 7 ourselves as well.
> 
> Are there any objections?
> 
> Thanks,
> 
> --Gunnar
> _______________________________________________
> 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/20150223/3bdc45ac/attachment.bin 

From davide at hibernate.org  Mon Feb 23 11:38:09 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Mon, 23 Feb 2015 16:38:09 +0000
Subject: [hibernate-dev] in.relation.to error when posting a new blog
	entry
In-Reply-To: <CANoTJYOMqw7wNhw_aM6PiuUheqYwyUzmfc_GMoPEtMF+1Xg=8Q@mail.gmail.com>
References: <CANoTJYNDL=YezU0rF8yq5n6ELyGb62QEX4VMzfQ-n=WVR2VryQ@mail.gmail.com>
	<2058705871.10879457.1423704976067.JavaMail.zimbra@redhat.com>
	<CAFm4XO3XNzBbbcLDG8iNV7bq_H9O-zSc4DZjERq4GXFmncZmrg@mail.gmail.com>
	<20150213095321.GC77073@Sarmakand-4.local>
	<1577213149.12156742.1423876432646.JavaMail.zimbra@redhat.com>
	<CANoTJYPUiU+oZhuwoyGTO-YKjixnE0TGhxs84szx09+34iiYHQ@mail.gmail.com>
	<20150220132011.GA6317@Sarmakand-4.local>
	<CANoTJYOy8wgJfR-k_RzTkFOtWtegDN65X2bDbkc4Un+ekwGj-w@mail.gmail.com>
	<CANoTJYOMqw7wNhw_aM6PiuUheqYwyUzmfc_GMoPEtMF+1Xg=8Q@mail.gmail.com>
Message-ID: <CANoTJYNbQXTDe+EgMOT8s8tM2dKAT_aY1a_Jo8xUGUd0PYXFRw@mail.gmail.com>

I've finally found out the culprit of the constraint violation.

You should be able to post new blog entries now.

Thanks everyone for the help.

Cheers

On Fri, Feb 20, 2015 at 5:12 PM, Davide D'Alto <davide at hibernate.org> wrote:

> I've tried to restart the server and it doesn't help.
>
> I'm thinking that I should disable foreign keys while running the query
> and see what happens.
>
> Any better idea?
>
> On Fri, Feb 20, 2015 at 3:35 PM, Davide D'Alto <davide at hibernate.org>
> wrote:
>
>> It's not going well,
>> I'm not sure how to solve this issue,
>>
>> It seems it's trying to delete something (from the log):
>>
>> Caused by: org.hibernate.exception.ConstraintViolationException: could
>> not delete: [org.jboss.seam.wiki.core.model.WikiCommentFeedEntry#40142]
>>
>> And that it is causing:
>>
>> Caused by:
>> com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException:
>> Cannot delete or update a parent row: a foreign key constraint fails
>> (`inrelationto`.`FEED_FEEDENTRY`,CONSTRAINT
>> `FK_FEED_FEEDENTRY_FEEDENTRY_ID` FOREIGN KEY (`FEEDENTRY_ID`) REFERENCES
>> `FEEDENTRY` (`FEEDENTRY_ID`))
>>
>>
>> I've attached the complete stacktrace.
>>
>> Should I restart everything?
>> I'm open to suggestion.
>>
>>
>>
>>
>> On Fri, Feb 20, 2015 at 1:20 PM, Hardy Ferentschik <hardy at hibernate.org>
>> wrote:
>>
>>> On Fri, Feb 20, 2015 at 11:56:13AM +0000, Davide D'Alto wrote:
>>> > I'm currently trying to fix it
>>>
>>> Cool. I was about to ask what the status is on this. Let me know how it
>>> goes.
>>> I am preparing a HV release blog. Would be nice to be able to publish it
>>> as well.
>>>
>>> --Hardy
>>>
>>
>>
>

From davide at hibernate.org  Mon Feb 23 11:47:41 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Mon, 23 Feb 2015 16:47:41 +0000
Subject: [hibernate-dev] in.relation.to works again
Message-ID: <CANoTJYNq+Sy5vqT9DB-1bJ0jWYHv2EZVan2tGdz-Ec-=BbZBmg@mail.gmail.com>

Hi,
you should be able to blog again on in.relation.to now

Thanks for everyone help.

Cheers,
Davide

From steve at hibernate.org  Mon Feb 23 13:43:55 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 23 Feb 2015 12:43:55 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <20150223093308.GB706@hibernate.org>
References: <CAFdSV9sRVd2sJU2rRt0UEWUfPnQEMdiYxjhrANniRpEF-jfDQg@mail.gmail.com>
	<E3BFFD6B-1BEE-45A7-9263-E76ED261A899@redhat.com>
	<CAFdSV9sADREy6ohG9av04CVQsK0SrskmAUq_i0gHUPCOBRu5yA@mail.gmail.com>
	<CAFdSV9sqsSL9tJc1GYin1uy9w30a=KjT6JMQKC85fViyZpx4DA@mail.gmail.com>
	<D911A508-D141-4E73-9FDF-3220B315F262@hibernate.org>
	<CAFdSV9u9_xL3-EOuwRRHRje0i0keAPV09rz1-sZSMRSiaX1UOg@mail.gmail.com>
	<57070315-9CB3-4CCF-84AB-5039172C7A18@hibernate.org>
	<CAFdSV9tfdBgnAdaPJq9vrGVtJmhHSQhPEO8WBT=0oE_JmYa1dw@mail.gmail.com>
	<81CDE27F-838F-4E5E-AC78-AFA1623036CB@hibernate.org>
	<CAFdSV9veYJjk25OeiLAYbhcVuwHuQnFw5jAGzbf6o5kTkzBp6g@mail.gmail.com>
	<20150223093308.GB706@hibernate.org>
Message-ID: <CAFdSV9uh=Hi6QutUAZiYMLgw7-Xv_PcEg91hbaPiHfW5cK57dQ@mail.gmail.com>

See below...

On Mon, Feb 23, 2015 at 3:33 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> Which one do you intend being the default?
> In 4.x AFAIR, it was
>
> * ImplicitNamingStrategyLegacyHbmImpl's behavior if you started ORM with
> the classic APIs.
> * ImplicitNamingStrategyLegacyJpaImpl's behavior if you started ORM via
> the JPA APIS (or was it ImplicitNamingStrategyStandardImpl?)
>

Actually, no.  It was always org.hibernate.cfg.EJB3NamingStrategy no matter
how you bootstrapped.  EJB3NamingStartegy is, unfortunately, not really any
of these.  To be honest, I am not really sure why that one was ever named
EJB3; it does not follow the spec in many many cases (even the 1.0 spec).
I guess we should make ImplicitNamingStrategyLegacyJpaImpl conform to
EJB3NamingStartegy and have that be the default.


> About names, I'm tempted to have:
>
> * ImplicitNamingStrategyJpaCompliantImpl
> * ImplicitNamingStrategyLegacyJpaImpl
> * ImplicitNamingStrategyLegacyHbmImpl
> * ImplicitNamingStrategyComponentPathImpl


> The idea is to make the names explicit with the intent. "Standard" does
> not mean much per se.
>

Well you asked the question perfectly above :)  "Standard" was not used at
all to indicate compliance with the spec/standard.  It was used because it
is the standard/default impl. But still I prefer
ImplicitNamingStrategyJpaCompliantImpl



>
> Emmanuel
>
> On Fri 2015-02-20 12:57, Steve Ebersole wrote:
> > So at the moment I have the following ImplicitNamingStrategy impls:
> >
> > 1) ImplicitNamingStrategyStandardImpl - Which is compliant with the rules
> > set forth in the JPA standard
> > 2) ImplicitNamingStrategyLegacyJpaImpl - Which implements the initial
> > support done for JPA 1, before JPA 2 clarified some things.
> > 3) ImplicitNamingStrategyLegacyHbmImpl - Support dating back to the dawn
> of
> > time...
> > 4) ImplicitNamingStrategyComponentSafeImpl - Mainly a port
> > of DefaultComponentSafeNamingStrategy, although leveraging the
> > AttributePath stuff I discussed earlier
> >
> > Couple of thoughts...
> >
> > First, we might want to rename ImplicitNamingStrategyLegacyJpaImpl to
> > ImplicitNamingStrategyStandardImpl, and
> ImplicitNamingStrategyStandardImpl
> > to ImplicitNamingStrategyJpaCompliantImpl.  WDYT?
> >
> > Second, I do not really like the phrase "component safe".  "Safe" from
> > what?  The difference is that the whole component path is used in
> > determining the name; so how about
> ImplicitNamingStrategyComponentPathImpl?
> >
> > I do not plan on porting any of the other NamingStrategy impls.
> >
> >
> > Also, here is the complete list of implicit naming hooks:
> > 1) primary table
> > 2) join table
> > 3) collection table
> > 4) discriminator column
> > 5) tenant id column
> > 6) id column (entity and idbag)
> > 7) basic column
> > 8) join column
> > 9) pk join column
> > 10 ) @Any discriminator column
> > 11) @Any key column
> > 12) map key column
> > 13) list index column
> > 14) foreign key name
> > 15) unique key name
> > 16) index name
> >
> >
> > On Mon, Feb 2, 2015 at 3:13 PM, Emmanuel Bernard <emmanuel at hibernate.org
> >
> > wrote:
> >
> > > I?d say +1 for adding coverage of them in the implicit naming strategy.
> > >
> > > On 02 Feb 2015, at 19:16, Steve Ebersole <steve at hibernate.org> wrote:
> > >
> > > They do not.  HBM, e.g., uses "idx" for map keys columns as well as
> > > list/array index columns.  JPA says to use {attribute-name}_ORDER for
> list
> > > index column.  Unless I missed it (which is completely possible in
> > > annotation binding) we always use the JPA-defined default in those
> cases
> > > rather than using any *implicit* naming hooks.
> > >
> > > So that is really the question.  Do we want expand the breadth of what
> is
> > > covered by implicit naming strategy in this new model?  I think its
> > > reasonable.
> > >
> > > On Mon, Feb 2, 2015 at 11:28 AM, Emmanuel Bernard <
> emmanuel at hibernate.org>
> > > wrote:
> > >
> > >>
> > >> On 02 Feb 2015, at 17:51, Steve Ebersole <steve at hibernate.org> wrote:
> > >>
> > >> On Mon, Feb 2, 2015 at 8:34 AM, Emmanuel Bernard <
> emmanuel at hibernate.org>
> > >>  wrote:
> > >>
> > >> I think you?re missing things like @MapKeyColumn, @OrderColumn
> > >>>
> > >>
> > >> So that's a good discussion.  These are things that have previously
> been
> > >> hard-coded defaults (at least on hbm side) and therefore had no
> specific
> > >> naming strategy hooks.  I'm all for being specific, so if everyone
> agrees
> > >> it is a good idea to add methods for stuff like this, I am fine with
> that.
> > >>
> > >>
> > >> I know JPA has well defined values for these. I am not sure they match
> > >> 100% the HBM version.
> > >>
> > >
> > >
> > >
>

From hardy at hibernate.org  Mon Feb 23 14:21:09 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 23 Feb 2015 20:21:09 +0100
Subject: [hibernate-dev] in.relation.to works again
In-Reply-To: <CANoTJYNq+Sy5vqT9DB-1bJ0jWYHv2EZVan2tGdz-Ec-=BbZBmg@mail.gmail.com>
References: <CANoTJYNq+Sy5vqT9DB-1bJ0jWYHv2EZVan2tGdz-Ec-=BbZBmg@mail.gmail.com>
Message-ID: <20150223192109.GE58413@Sarmakand-4.local>

Thanks awesome.

On Mon, Feb 23, 2015 at 04:47:41PM +0000, Davide D'Alto wrote:
> Hi,
> you should be able to blog again on in.relation.to now
> 
> Thanks for everyone help.
> 
> Cheers,
> Davide
> _______________________________________________
> 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/20150223/8dda94d8/attachment.bin 

From m.schipperheyn at gmail.com  Mon Feb 23 16:28:45 2015
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Mon, 23 Feb 2015 18:28:45 -0300
Subject: [hibernate-dev] Lucene-suggest
Message-ID: <CAGvEgx7a3rw1XWC4UG=kDB=oDJ7LYe4LAND_2JiR0noRsEnmdg@mail.gmail.com>

Lucene 4.x offers some interesting new functionality with regards to
autosuggest and google style suggestions.

As part of this functionality, as I understand it, the suggester builds a
separate index based on the available data with a specific .build()
function.

I'm assuming that this separate index would not be automatically updated
when an index record is created through HSEARCH and I'm wondering what
would be the best way to go about this.

Any suggestions? It would seem that the build step should be executed
through a FullTextEventListener (not sure how to sue that these days). But
obviously during a MassIndexer operation, you would only want to execute
after the entire process completes.

Marc

From sanne at hibernate.org  Tue Feb 24 06:51:36 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 24 Feb 2015 11:51:36 +0000
Subject: [hibernate-dev] Lucene-suggest
In-Reply-To: <CAGvEgx7a3rw1XWC4UG=kDB=oDJ7LYe4LAND_2JiR0noRsEnmdg@mail.gmail.com>
References: <CAGvEgx7a3rw1XWC4UG=kDB=oDJ7LYe4LAND_2JiR0noRsEnmdg@mail.gmail.com>
Message-ID: <CAFm4XO25Qu0w-hUSyqLrAUMaaJ3hEoR7KjJtsUwqEVvNVn84Vw@mail.gmail.com>

Hi Marc,
I didn't run any real performance test with it myself yet, but what
I'm understood from other Lucene users is that with the finite state
machine approach for auto-suggestion, the "index" (more appropriately
the state machine) isn't suited for real-time rebuilding.

We'll have to create a method which can rebuild it on demand -
similarly to the MassIndexer.
I expect it to take much less time as it wouldn't need to literally
reload all of your database, but still it might take some minutes so
not something that we should do on a per-commit operation.

Maybe we could do it in background, on a fixed periodicity. I'd prefer
to delegate such cron jobs to user's coding responsbility (which could
be our first implementation step), but there might be some additional
optimisations which we could do when controlling the process.

I'm thinking of:
 - disable it when running the MassIndexer
 - automatically run it at end of MassIndexer
 - disable a timed event if there have been no changes during the period

Would you see a use for it be "guaranteed" to be always in synch,
synchronously, even if it took you - say - 2 minutes of intense CPU
and IO operations to build?

Sanne


On 23 February 2015 at 21:28, Marc Schipperheyn
<m.schipperheyn at gmail.com> wrote:
> Lucene 4.x offers some interesting new functionality with regards to
> autosuggest and google style suggestions.
>
> As part of this functionality, as I understand it, the suggester builds a
> separate index based on the available data with a specific .build()
> function.
>
> I'm assuming that this separate index would not be automatically updated
> when an index record is created through HSEARCH and I'm wondering what
> would be the best way to go about this.
>
> Any suggestions? It would seem that the build step should be executed
> through a FullTextEventListener (not sure how to sue that these days). But
> obviously during a MassIndexer operation, you would only want to execute
> after the entire process completes.
>
> Marc
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From m.schipperheyn at gmail.com  Tue Feb 24 07:53:17 2015
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Tue, 24 Feb 2015 09:53:17 -0300
Subject: [hibernate-dev] Lucene-suggest
In-Reply-To: <CAFm4XO25Qu0w-hUSyqLrAUMaaJ3hEoR7KjJtsUwqEVvNVn84Vw@mail.gmail.com>
References: <CAGvEgx7a3rw1XWC4UG=kDB=oDJ7LYe4LAND_2JiR0noRsEnmdg@mail.gmail.com>
	<CAFm4XO25Qu0w-hUSyqLrAUMaaJ3hEoR7KjJtsUwqEVvNVn84Vw@mail.gmail.com>
Message-ID: <CAGvEgx4xBj6v50WhcYZbckUeSHHh5UKwWZE7wc2K6psSEdwpBg@mail.gmail.com>

Hi Sanne,

I would not see a use for such an intense CPU hit since we intend to run it
as an autocomplete against forum posts titles (e.g. stackoverflow). So,
that would be changing on a continuous basis.

A cron job would suit just fine for that. We can tune that to our needs.

Cheers,
Marc

From hardy at hibernate.org  Tue Feb 24 10:49:39 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 24 Feb 2015 16:49:39 +0100
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <CADGJaX8m=VCE9g+F5cJcQu2DBmK98d62eSOitwjV=sSf2B0PHQ@mail.gmail.com>
References: <20150220100711.GA23252@hibernate.org>
	<CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
	<CADGJaX8m=VCE9g+F5cJcQu2DBmK98d62eSOitwjV=sSf2B0PHQ@mail.gmail.com>
Message-ID: <20150224154939.GI67632@Sarmakand-4.local>

> * There are two types of tests in core: a) unit tests for stuff in core
> itself and b) the "backendtck" which are high-level (i.e. Session/EM-level)
> tests and which are executed for all backends.

Wouldn't it make sense to have these backendtck tests defined in a dedicated 
module? When you mentioned it, I was literally searching for the tests you were
referring to.

> To run a specific test
> against a specific store in your IDE, simplest is to copy it into that
> project and run it from there.

I tried using a custom runner called ClasspathSuite. See also pull request https://github.com/hibernate/hibernate-ogm/pull/487.
Works fine for me and seems better than copying things around.

--Hardy

P.S. And what's the state of this TODO.txt in the core module? Shouldn't it be removed?
-------------- 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/20150224/d66849cf/attachment.bin 

From gunnar at hibernate.org  Tue Feb 24 11:36:30 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 24 Feb 2015 17:36:30 +0100
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <20150224154939.GI67632@Sarmakand-4.local>
References: <20150220100711.GA23252@hibernate.org>
	<CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
	<CADGJaX8m=VCE9g+F5cJcQu2DBmK98d62eSOitwjV=sSf2B0PHQ@mail.gmail.com>
	<20150224154939.GI67632@Sarmakand-4.local>
Message-ID: <CADGJaX955FnA4hMiM0a8ZyvSnfybG5w8Gt23WdGQ1Xp+xdr6+w@mail.gmail.com>

Hey,

2015-02-24 16:49 GMT+01:00 Hardy Ferentschik <hardy at hibernate.org>:

> > * There are two types of tests in core: a) unit tests for stuff in core
> > itself and b) the "backendtck" which are high-level (i.e.
> Session/EM-level)
> > tests and which are executed for all backends.
>
> Wouldn't it make sense to have these backendtck tests defined in a
> dedicated
> module? When you mentioned it, I was literally searching for the tests you
> were
> referring to.
>

Sorry, I guess I should have given you the package name.

I kind of like the fact that one can execute the tests in core right away,
i.e. without any copying, or custom runner etc. Would there be any strong
advantage to having them in a separate module? If not I'd prefer to keep
the number of modules low.

> To run a specific test
> > against a specific store in your IDE, simplest is to copy it into that
> > project and run it from there.
>
> I tried using a custom runner called ClasspathSuite. See also pull request
> https://github.com/hibernate/hibernate-ogm/pull/487.
> Works fine for me and seems better than copying things around.
>

That's a nice thing indeed. It's a bit simpler to adapt this file rather
than copying tests from core. I guess we cannot have this helper once in
core, or can we? Makes sense to have it in each backend module then I would
say.


>
> --Hardy
>

--Gunnar


>
> P.S. And what's the state of this TODO.txt in the core module? Shouldn't
> it be removed?
>

Hum, never seen that before. I guess Emmanuel needs to answer that one :)

From gunnar at hibernate.org  Wed Feb 25 03:23:15 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 25 Feb 2015 09:23:15 +0100
Subject: [hibernate-dev] [OGM] Moving to Java 7
In-Reply-To: <20150223113240.GB58413@Sarmakand-4.local>
References: <CADGJaX9aVme-oOfTHBVqeSrko_zijB9vPhTmtmMQi4WrUjpkkQ@mail.gmail.com>
	<20150223113240.GB58413@Sarmakand-4.local>
Message-ID: <CADGJaX90UkMoqhffv09Uq3CZfO=-TiRb9+MNM9Kru58T6LbfLw@mail.gmail.com>

Ok, I have filed https://hibernate.atlassian.net/browse/OGM-747 for that.

--Gunnar


2015-02-23 12:32 GMT+01:00 Hardy Ferentschik <hardy at hibernate.org>:

> sure +1
>
>
> On Mon, Feb 23, 2015 at 11:40:19AM +0100, Gunnar Morling wrote:
> > Hi,
> >
> > So far Hibernate OGM has been usable quite well when running on Java 6.
> But
> > as more and more of our dependencies require Java 7, the number of cases
> > where 6 is sufficient, decreases.
> >
> > With two out of four backends (Infinispan and Neo4j) as well as HSEARCH
> > requiring 7 by now, I think it's about time to move on and take advantage
> > of 7 ourselves as well.
> >
> > Are there any objections?
> >
> > Thanks,
> >
> > --Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Wed Feb 25 05:30:43 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 25 Feb 2015 11:30:43 +0100
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <CADGJaX955FnA4hMiM0a8ZyvSnfybG5w8Gt23WdGQ1Xp+xdr6+w@mail.gmail.com>
References: <20150220100711.GA23252@hibernate.org>
	<CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
	<CADGJaX8m=VCE9g+F5cJcQu2DBmK98d62eSOitwjV=sSf2B0PHQ@mail.gmail.com>
	<20150224154939.GI67632@Sarmakand-4.local>
	<CADGJaX955FnA4hMiM0a8ZyvSnfybG5w8Gt23WdGQ1Xp+xdr6+w@mail.gmail.com>
Message-ID: <20150225103043.GA73532@Sarmakand-4.local>

> > Wouldn't it make sense to have these backendtck tests defined in a
> > dedicated
> > module? When you mentioned it, I was literally searching for the tests you
> > were
> > referring to.
> >
> 
> Sorry, I guess I should have given you the package name.
> 
> I kind of like the fact that one can execute the tests in core right away,
> i.e. without any copying, or custom runner etc. Would there be any strong
> advantage to having them in a separate module? If not I'd prefer to keep
> the number of modules low.

More transparency. If the module existed I could already just by name infer 
what it is about. This might also be helpful for potential dialect contributors 
who look for high level tests. 

It is also in the spirit of one module one artifact. Unless I actually check the 
POM and find the second execution of the jar plugin, I don't know that two artifacts
are generated. 

A dedicated module means less surprises and less understanding needed to see how 
things get together.

Also, having a dedicated module allows for adding an additional README which for
example described the purpose of these tests, how they are executed and that they
are used by each dialect.  

--Hardy

From daltodavide at gmail.com  Wed Feb 25 05:53:41 2015
From: daltodavide at gmail.com (Davide D'Alto)
Date: Wed, 25 Feb 2015 10:53:41 +0000
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <20150225103043.GA73532@Sarmakand-4.local>
References: <20150220100711.GA23252@hibernate.org>
	<CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
	<CADGJaX8m=VCE9g+F5cJcQu2DBmK98d62eSOitwjV=sSf2B0PHQ@mail.gmail.com>
	<20150224154939.GI67632@Sarmakand-4.local>
	<CADGJaX955FnA4hMiM0a8ZyvSnfybG5w8Gt23WdGQ1Xp+xdr6+w@mail.gmail.com>
	<20150225103043.GA73532@Sarmakand-4.local>
Message-ID: <CANoTJYN-1yn49OvXz5z2yUtZDnQcQkbNBfLuvB0Tzdf-yvREZQ@mail.gmail.com>

I like the idea of a separate module for shared tests, It makes sense for
our usecase.
I've never been a big fun of the OGM black magic.

Are there any reasons not to do it except that it will add a new module?
I'm not really concerned about having modules in the project if their
purpose is clear.


On Wed, Feb 25, 2015 at 10:30 AM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> > > Wouldn't it make sense to have these backendtck tests defined in a
> > > dedicated
> > > module? When you mentioned it, I was literally searching for the tests
> you
> > > were
> > > referring to.
> > >
> >
> > Sorry, I guess I should have given you the package name.
> >
> > I kind of like the fact that one can execute the tests in core right
> away,
> > i.e. without any copying, or custom runner etc. Would there be any strong
> > advantage to having them in a separate module? If not I'd prefer to keep
> > the number of modules low.
>
> More transparency. If the module existed I could already just by name infer
> what it is about. This might also be helpful for potential dialect
> contributors
> who look for high level tests.
>
> It is also in the spirit of one module one artifact. Unless I actually
> check the
> POM and find the second execution of the jar plugin, I don't know that two
> artifacts
> are generated.
>
> A dedicated module means less surprises and less understanding needed to
> see how
> things get together.
>
> Also, having a dedicated module allows for adding an additional README
> which for
> example described the purpose of these tests, how they are executed and
> that they
> are used by each dialect.
>
> --Hardy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Feb 25 06:10:38 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 25 Feb 2015 11:10:38 +0000
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <CANoTJYN-1yn49OvXz5z2yUtZDnQcQkbNBfLuvB0Tzdf-yvREZQ@mail.gmail.com>
References: <20150220100711.GA23252@hibernate.org>
	<CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
	<CADGJaX8m=VCE9g+F5cJcQu2DBmK98d62eSOitwjV=sSf2B0PHQ@mail.gmail.com>
	<20150224154939.GI67632@Sarmakand-4.local>
	<CADGJaX955FnA4hMiM0a8ZyvSnfybG5w8Gt23WdGQ1Xp+xdr6+w@mail.gmail.com>
	<20150225103043.GA73532@Sarmakand-4.local>
	<CANoTJYN-1yn49OvXz5z2yUtZDnQcQkbNBfLuvB0Tzdf-yvREZQ@mail.gmail.com>
Message-ID: <CAFm4XO0YUFrj2ZoRFDOE20_dsR93NMeP+L90NPNwvYOVWCrZ_A@mail.gmail.com>

On 25 February 2015 at 10:53, Davide D'Alto <daltodavide at gmail.com> wrote:
> I like the idea of a separate module for shared tests, It makes sense for
> our usecase.
> I've never been a big fun of the OGM black magic.

I'm not a fan of the current state either, but there are many possible
improvements which don't need a separate module nor need to keep
copying classes around.

> Are there any reasons not to do it except that it will add a new module?
> I'm not really concerned about having modules in the project if their
> purpose is clear.

I like that a change in core is validated by tests in core, at least
so far as it doesn't concern specific integrations. That's a common
best practice for any codebase, and the least surprising layout of the
source code. I think "core" is fine, it's the integrating modules
which are evil.

We can talk about moving core tests to a different module, but I don't
see how that's going to improve things. After all, it's still a
different artifact.

For example, surefire now has some new options which it didn't have 3
years ago, and some of these now allow to "adjust" how the JUnit test
runners discover the tests. I'll play with that, although it only
skips the copy step: it won't improve on debugging needs.
For debugging, it would work fine OOB a long time back, but then you
guys added some conflicting resources across modules which break the
original idea ;-) I'll see if I can revert that without collaterals.

Sanne

>
>
> On Wed, Feb 25, 2015 at 10:30 AM, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
>
>> > > Wouldn't it make sense to have these backendtck tests defined in a
>> > > dedicated
>> > > module? When you mentioned it, I was literally searching for the tests
>> you
>> > > were
>> > > referring to.
>> > >
>> >
>> > Sorry, I guess I should have given you the package name.
>> >
>> > I kind of like the fact that one can execute the tests in core right
>> away,
>> > i.e. without any copying, or custom runner etc. Would there be any strong
>> > advantage to having them in a separate module? If not I'd prefer to keep
>> > the number of modules low.
>>
>> More transparency. If the module existed I could already just by name infer
>> what it is about. This might also be helpful for potential dialect
>> contributors
>> who look for high level tests.
>>
>> It is also in the spirit of one module one artifact. Unless I actually
>> check the
>> POM and find the second execution of the jar plugin, I don't know that two
>> artifacts
>> are generated.
>>
>> A dedicated module means less surprises and less understanding needed to
>> see how
>> things get together.
>>
>> Also, having a dedicated module allows for adding an additional README
>> which for
>> example described the purpose of these tests, how they are executed and
>> that they
>> are used by each dialect.
>>
>> --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 gunnar at hibernate.org  Wed Feb 25 06:12:26 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 25 Feb 2015 12:12:26 +0100
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <20150225103043.GA73532@Sarmakand-4.local>
References: <20150220100711.GA23252@hibernate.org>
	<CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
	<CADGJaX8m=VCE9g+F5cJcQu2DBmK98d62eSOitwjV=sSf2B0PHQ@mail.gmail.com>
	<20150224154939.GI67632@Sarmakand-4.local>
	<CADGJaX955FnA4hMiM0a8ZyvSnfybG5w8Gt23WdGQ1Xp+xdr6+w@mail.gmail.com>
	<20150225103043.GA73532@Sarmakand-4.local>
Message-ID: <CADGJaX-BCOYmA7WOqpgs3MKe10tRfvPBPE6T1PRszRuyWphs+w@mail.gmail.com>

2015-02-25 11:30 GMT+01:00 Hardy Ferentschik <hardy at hibernate.org>:

> > > Wouldn't it make sense to have these backendtck tests defined in a
> > > dedicated
> > > module? When you mentioned it, I was literally searching for the tests
> you
> > > were
> > > referring to.
> > >
> >
> > Sorry, I guess I should have given you the package name.
> >
> > I kind of like the fact that one can execute the tests in core right
> away,
> > i.e. without any copying, or custom runner etc. Would there be any strong
> > advantage to having them in a separate module? If not I'd prefer to keep
> > the number of modules low.
>
> More transparency. If the module existed I could already just by name infer
> what it is about. This might also be helpful for potential dialect
> contributors
> who look for high level tests.
>

Ok, so it seems to be a documentation issue mainly? Note that Emmanuel put
my previous note on the different kinds of tests to the contributor guide (
http://hibernate.org/ogm/contribute/#any-detail-on-how-the-project-is-structured).
I would expect contributors to find their ways from there.

It is also in the spirit of one module one artifact. Unless I actually
> check the
> POM and find the second execution of the jar plugin, I don't know that two
> artifacts
> are generated.


> A dedicated module means less surprises and less understanding needed to
> see how
> things get together.
>

Hm, but test JARs have been an exception to that "rule" in Maven for a long
time. So no-one should really be surprised by using that concept.


> Also, having a dedicated module allows for adding an additional README
> which for
> example described the purpose of these tests, how they are executed and
> that they
> are used by each dialect.
>

Would it help if we add a note to the main readme.md, or maybe
package-info.java in the TCK package? Personally I prefer to have all
build-related info in one readme rather than scattered over several places.

It's not that I'm not against that move per se, I only have doubts whether
there is much benefit to it.

My main concern still is whether that move would complicate running tests
in core itself? Today I can click and run the TCK tests in core in the IDE
without any further preparation. If that'd get more difficult, I'd vote
against that split.

--Hardy
>

From gunnar at hibernate.org  Wed Feb 25 06:46:13 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 25 Feb 2015 12:46:13 +0100
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <CADGJaX-BCOYmA7WOqpgs3MKe10tRfvPBPE6T1PRszRuyWphs+w@mail.gmail.com>
References: <20150220100711.GA23252@hibernate.org>
	<CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
	<CADGJaX8m=VCE9g+F5cJcQu2DBmK98d62eSOitwjV=sSf2B0PHQ@mail.gmail.com>
	<20150224154939.GI67632@Sarmakand-4.local>
	<CADGJaX955FnA4hMiM0a8ZyvSnfybG5w8Gt23WdGQ1Xp+xdr6+w@mail.gmail.com>
	<20150225103043.GA73532@Sarmakand-4.local>
	<CADGJaX-BCOYmA7WOqpgs3MKe10tRfvPBPE6T1PRszRuyWphs+w@mail.gmail.com>
Message-ID: <CADGJaX-f8CqhNML3bz7e-gB_7J18CCdAnRpA03iZ3WmMzs4ypw@mail.gmail.com>

> My main concern still is whether that move would complicate running tests
in core itself? Today I can click and run the TCK tests in core in the IDE
without any further preparation. If that'd get more difficult, I'd vote
against that split.

To give some background, there is a dialect in core itself, HashmapDialect,
which is used when running the TCK in core. It makes sure changes or new
features can be tested in core alone as far as possible. It would be good
to keep the usability of this as nice as it is today.




2015-02-25 12:12 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:

> 2015-02-25 11:30 GMT+01:00 Hardy Ferentschik <hardy at hibernate.org>:
>
>> > > Wouldn't it make sense to have these backendtck tests defined in a
>> > > dedicated
>> > > module? When you mentioned it, I was literally searching for the
>> tests you
>> > > were
>> > > referring to.
>> > >
>> >
>> > Sorry, I guess I should have given you the package name.
>> >
>> > I kind of like the fact that one can execute the tests in core right
>> away,
>> > i.e. without any copying, or custom runner etc. Would there be any
>> strong
>> > advantage to having them in a separate module? If not I'd prefer to keep
>> > the number of modules low.
>>
>> More transparency. If the module existed I could already just by name
>> infer
>> what it is about. This might also be helpful for potential dialect
>> contributors
>> who look for high level tests.
>>
>
> Ok, so it seems to be a documentation issue mainly? Note that Emmanuel put
> my previous note on the different kinds of tests to the contributor guide
> (
> http://hibernate.org/ogm/contribute/#any-detail-on-how-the-project-is-structured).
> I would expect contributors to find their ways from there.
>
> It is also in the spirit of one module one artifact. Unless I actually
>> check the
>> POM and find the second execution of the jar plugin, I don't know that
>> two artifacts
>> are generated.
>
>
>> A dedicated module means less surprises and less understanding needed to
>> see how
>> things get together.
>>
>
> Hm, but test JARs have been an exception to that "rule" in Maven for a
> long time. So no-one should really be surprised by using that concept.
>
>
>> Also, having a dedicated module allows for adding an additional README
>> which for
>> example described the purpose of these tests, how they are executed and
>> that they
>> are used by each dialect.
>>
>
> Would it help if we add a note to the main readme.md, or maybe
> package-info.java in the TCK package? Personally I prefer to have all
> build-related info in one readme rather than scattered over several places.
>
> It's not that I'm not against that move per se, I only have doubts whether
> there is much benefit to it.
>
> My main concern still is whether that move would complicate running tests
> in core itself? Today I can click and run the TCK tests in core in the IDE
> without any further preparation. If that'd get more difficult, I'd vote
> against that split.
>
> --Hardy
>>
>
>

From m.schipperheyn at gmail.com  Wed Feb 25 08:20:30 2015
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Wed, 25 Feb 2015 10:20:30 -0300
Subject: [hibernate-dev] Is HSEARCH-1786/HSEARCH-1814 on the radar
Message-ID: <CAGvEgx7TP55J0bXexEaOQLceF4=XxA2fRtjz88FYxtNcr5Gk8Q@mail.gmail.com>

Hi,

Just wondering if HSEARCH-1786/HSEARCH-1814 are on the radar? We have
stopped all of our upgrade efforts because of this. And if they are valid
bugs, it basically means that HSEARCH 5.0, and 5.01 are unreliable for
production use.`

I'm just wondering if it's considered a real bug, if so it's a blocker, or
perhaps a figment of imagination? I know I have made my share of erronous
bug reports...

Cheers,
Marc

From hardy at hibernate.org  Wed Feb 25 10:47:27 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 25 Feb 2015 16:47:27 +0100
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <CADGJaX-BCOYmA7WOqpgs3MKe10tRfvPBPE6T1PRszRuyWphs+w@mail.gmail.com>
References: <20150220100711.GA23252@hibernate.org>
	<CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
	<CADGJaX8m=VCE9g+F5cJcQu2DBmK98d62eSOitwjV=sSf2B0PHQ@mail.gmail.com>
	<20150224154939.GI67632@Sarmakand-4.local>
	<CADGJaX955FnA4hMiM0a8ZyvSnfybG5w8Gt23WdGQ1Xp+xdr6+w@mail.gmail.com>
	<20150225103043.GA73532@Sarmakand-4.local>
	<CADGJaX-BCOYmA7WOqpgs3MKe10tRfvPBPE6T1PRszRuyWphs+w@mail.gmail.com>
Message-ID: <20150225154727.GA78865@Sarmakand-4.local>

> > A dedicated module means less surprises and less understanding needed to
> > see how
> > things get together.
> >
> 
> Hm, but test JARs have been an exception to that "rule" in Maven for a long
> time. So no-one should really be surprised by using that concept.

Hmm, not sure. 

> > Also, having a dedicated module allows for adding an additional README
> > which for
> > example described the purpose of these tests, how they are executed and
> > that they
> > are used by each dialect.
> >
> 
> Would it help if we add a note to the main readme.md, or maybe
> package-info.java in the TCK package? Personally I prefer to have all
> build-related info in one readme rather than scattered over several places.

But that's partly my point. Your solutions require me to read something,
whereas a dedicated module is almost self explaining.

> It's not that I'm not against that move per se, I only have doubts whether
> there is much benefit to it.

IMO yes

> My main concern still is whether that move would complicate running tests
> in core itself? Today I can click and run the TCK tests in core in the IDE
> without any further preparation. If that'd get more difficult, I'd vote
> against that split.

Well, with the helper I am suggesting it is still a single click :-)

--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/20150225/448fc455/attachment.bin 

From hardy at hibernate.org  Wed Feb 25 10:52:12 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 25 Feb 2015 16:52:12 +0100
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <CADGJaX-f8CqhNML3bz7e-gB_7J18CCdAnRpA03iZ3WmMzs4ypw@mail.gmail.com>
References: <20150220100711.GA23252@hibernate.org>
	<CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
	<CADGJaX8m=VCE9g+F5cJcQu2DBmK98d62eSOitwjV=sSf2B0PHQ@mail.gmail.com>
	<20150224154939.GI67632@Sarmakand-4.local>
	<CADGJaX955FnA4hMiM0a8ZyvSnfybG5w8Gt23WdGQ1Xp+xdr6+w@mail.gmail.com>
	<20150225103043.GA73532@Sarmakand-4.local>
	<CADGJaX-BCOYmA7WOqpgs3MKe10tRfvPBPE6T1PRszRuyWphs+w@mail.gmail.com>
	<CADGJaX-f8CqhNML3bz7e-gB_7J18CCdAnRpA03iZ3WmMzs4ypw@mail.gmail.com>
Message-ID: <20150225155211.GB78865@Sarmakand-4.local>

On Wed, Feb 25, 2015 at 12:46:13PM +0100, Gunnar Morling wrote:
> To give some background, there is a dialect in core itself, HashmapDialect,
> which is used when running the TCK in core.

Something I did not know. I was about to ask how you can run these tests in
core anyways. I was wondering whether you run them plain ORM?
Probably worth mentioning somewhere.

> It makes sure changes or new
> features can be tested in core alone as far as possible. It would be good
> to keep the usability of this as nice as it is today.

I don't think extracting the tests into a module is impacting this much.

--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/20150225/49aab7d7/attachment.bin 

From gunnar at hibernate.org  Wed Feb 25 10:53:58 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 25 Feb 2015 16:53:58 +0100
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <20150225154727.GA78865@Sarmakand-4.local>
References: <20150220100711.GA23252@hibernate.org>
	<CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
	<CADGJaX8m=VCE9g+F5cJcQu2DBmK98d62eSOitwjV=sSf2B0PHQ@mail.gmail.com>
	<20150224154939.GI67632@Sarmakand-4.local>
	<CADGJaX955FnA4hMiM0a8ZyvSnfybG5w8Gt23WdGQ1Xp+xdr6+w@mail.gmail.com>
	<20150225103043.GA73532@Sarmakand-4.local>
	<CADGJaX-BCOYmA7WOqpgs3MKe10tRfvPBPE6T1PRszRuyWphs+w@mail.gmail.com>
	<20150225154727.GA78865@Sarmakand-4.local>
Message-ID: <CADGJaX9sNRE9s9Cw3hQNpRz-n9TydbYAQtZp0Myxef701+kZjw@mail.gmail.com>

2015-02-25 16:47 GMT+01:00 Hardy Ferentschik <hardy at hibernate.org>:

> > > A dedicated module means less surprises and less understanding needed
> to
> > > see how
> > > things get together.
> > >
> >
> > Hm, but test JARs have been an exception to that "rule" in Maven for a
> long
> > time. So no-one should really be surprised by using that concept.
>
> Hmm, not sure.
>
> > > Also, having a dedicated module allows for adding an additional README
> > > which for
> > > example described the purpose of these tests, how they are executed and
> > > that they
> > > are used by each dialect.
> > >
> >
> > Would it help if we add a note to the main readme.md, or maybe
> > package-info.java in the TCK package? Personally I prefer to have all
> > build-related info in one readme rather than scattered over several
> places.
>
> But that's partly my point. Your solutions require me to read something,
> whereas a dedicated module is almost self explaining.
>
> > It's not that I'm not against that move per se, I only have doubts
> whether
> > there is much benefit to it.
>
> IMO yes
>
> > My main concern still is whether that move would complicate running tests
> > in core itself? Today I can click and run the TCK tests in core in the
> IDE
> > without any further preparation. If that'd get more difficult, I'd vote
> > against that split.
>
> Well, with the helper I am suggesting it is still a single click :-)
>

So I can click a single test and run it in core without further ado? If so,
it's cool. Also for the actual backend modules.

But I understood I'd have to adapt that helper to tell which test to run?
That's what I'd like to avoid, at least in core.

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

From emmanuel at hibernate.org  Wed Feb 25 11:13:03 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 25 Feb 2015 17:13:03 +0100
Subject: [hibernate-dev] [OGM] Sprint organization
In-Reply-To: <20150225154727.GA78865@Sarmakand-4.local>
References: <20150220100711.GA23252@hibernate.org>
	<CADGJaX8x109C4-CzKFnXyCtOr5FCQY1fy=tOY=ZvdSP__w3kGg@mail.gmail.com>
	<CADGJaX8m=VCE9g+F5cJcQu2DBmK98d62eSOitwjV=sSf2B0PHQ@mail.gmail.com>
	<20150224154939.GI67632@Sarmakand-4.local>
	<CADGJaX955FnA4hMiM0a8ZyvSnfybG5w8Gt23WdGQ1Xp+xdr6+w@mail.gmail.com>
	<20150225103043.GA73532@Sarmakand-4.local>
	<CADGJaX-BCOYmA7WOqpgs3MKe10tRfvPBPE6T1PRszRuyWphs+w@mail.gmail.com>
	<20150225154727.GA78865@Sarmakand-4.local>
Message-ID: <20150225161303.GD4153@hibernate.org>

Running a test for any of the datastore (except HashMap) is a pain.
Hardy's approach does not solve the one test problem as it runs all of the TCK,
which can be done with mvn install.

The workarounds are:

- copy the tests
- use your IDE to set the different module classpath but that also means
  that when you change the code of the test, you need to run mvn install
  for that to be taken into account (at least in IDEA and on my machine.

At least when you improve core, you can run the tests normally.
If you externalize the tests, even that situation will be a pain.

No way.


On Wed 2015-02-25 16:47, Hardy Ferentschik wrote:
> > > A dedicated module means less surprises and less understanding needed to
> > > see how
> > > things get together.
> > >
> > 
> > Hm, but test JARs have been an exception to that "rule" in Maven for a long
> > time. So no-one should really be surprised by using that concept.
> 
> Hmm, not sure. 
> 
> > > Also, having a dedicated module allows for adding an additional README
> > > which for
> > > example described the purpose of these tests, how they are executed and
> > > that they
> > > are used by each dialect.
> > >
> > 
> > Would it help if we add a note to the main readme.md, or maybe
> > package-info.java in the TCK package? Personally I prefer to have all
> > build-related info in one readme rather than scattered over several places.
> 
> But that's partly my point. Your solutions require me to read something,
> whereas a dedicated module is almost self explaining.
> 
> > It's not that I'm not against that move per se, I only have doubts whether
> > there is much benefit to it.
> 
> IMO yes
> 
> > My main concern still is whether that move would complicate running tests
> > in core itself? Today I can click and run the TCK tests in core in the IDE
> > without any further preparation. If that'd get more difficult, I'd vote
> > against that split.
> 
> Well, with the helper I am suggesting it is still a single click :-)
> 
> --Hardy



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


From steve at hibernate.org  Wed Feb 25 14:32:53 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 25 Feb 2015 13:32:53 -0600
Subject: [hibernate-dev] Naming and "naming strategies"
In-Reply-To: <CAFdSV9uh=Hi6QutUAZiYMLgw7-Xv_PcEg91hbaPiHfW5cK57dQ@mail.gmail.com>
References: <CAFdSV9sRVd2sJU2rRt0UEWUfPnQEMdiYxjhrANniRpEF-jfDQg@mail.gmail.com>
	<E3BFFD6B-1BEE-45A7-9263-E76ED261A899@redhat.com>
	<CAFdSV9sADREy6ohG9av04CVQsK0SrskmAUq_i0gHUPCOBRu5yA@mail.gmail.com>
	<CAFdSV9sqsSL9tJc1GYin1uy9w30a=KjT6JMQKC85fViyZpx4DA@mail.gmail.com>
	<D911A508-D141-4E73-9FDF-3220B315F262@hibernate.org>
	<CAFdSV9u9_xL3-EOuwRRHRje0i0keAPV09rz1-sZSMRSiaX1UOg@mail.gmail.com>
	<57070315-9CB3-4CCF-84AB-5039172C7A18@hibernate.org>
	<CAFdSV9tfdBgnAdaPJq9vrGVtJmhHSQhPEO8WBT=0oE_JmYa1dw@mail.gmail.com>
	<81CDE27F-838F-4E5E-AC78-AFA1623036CB@hibernate.org>
	<CAFdSV9veYJjk25OeiLAYbhcVuwHuQnFw5jAGzbf6o5kTkzBp6g@mail.gmail.com>
	<20150223093308.GB706@hibernate.org>
	<CAFdSV9uh=Hi6QutUAZiYMLgw7-Xv_PcEg91hbaPiHfW5cK57dQ@mail.gmail.com>
Message-ID: <CAFdSV9v2xvZv9b4hpp2xyH_BM_s1FKvYOMYyXavTvbxj-KubrA@mail.gmail.com>

To clarify...

The same NamingStrategy is used no matter what by default.  The variance
comes from the fact that each binding method calls different methods :(
 Which of course makes retrofitting tough in these cases.  The main use
case I have seen where this happens is in many-to-one mappings.  HbmBinder
calls NamingStrategy#propertyToColumnName whereas AnnotationBinder calls
NamingStrategy#foreignKeyColumnName (well actually it calls
#propertyToColumnName first, but then calls #foreignKeyColumnName sometime
later to over-write the previous implicit name).

So, for example, a mapping like:

@ManyToOne
@JoinColumn
public Customer getCustomer();

<many-to-one name="customer" class="Customer"/>

When binding this via annotations, the foreignKeyColumnName(...) call
ultimately wins and we end up with customer_id as the column name.  When
binding from hbm, the propertyToColumnName(...) call wins and we end up
with "customer" as the name.  Hbm binding is wrong.  This handling should
have routed through the specialized method for "join column" handling (aka,
#foreignKeyColumnName) as soon as that method was added.  But that was not
done.   So at the moment I think we need to keep that behavior, and simply
document that NamingStrategy#foreignKeyColumnName is only ever used in
annotation binding and that for 5.0 and ImplicitNamingStrategy that
(mis)behavior is ported in order to maintain portability.

Along the road from 5.0 to 6.0 development, one of the items was to drop
hbm.xml support (in favor of a unified orm.xml XSD), so this is a
relatively short term deal.


On a related note, currently there is a single method for handling all
forms of @JoinColumn.  But there are quite a few ways in which @JoinColumn
is used, so the implementation of that often get complex.  After I get this
work pushed, I'd really like people to take a look at this bit and see if
it makes sense to split those out into different methods, e.g.:

determineElementCollectionJoinColumnName(...)
determineEntityReferenceJoinColumnName(...)
...


On Mon, Feb 23, 2015 at 12:43 PM, Steve Ebersole <steve at hibernate.org>
wrote:

> See below...
>
> On Mon, Feb 23, 2015 at 3:33 AM, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>
>> Which one do you intend being the default?
>> In 4.x AFAIR, it was
>>
>> * ImplicitNamingStrategyLegacyHbmImpl's behavior if you started ORM with
>> the classic APIs.
>> * ImplicitNamingStrategyLegacyJpaImpl's behavior if you started ORM via
>> the JPA APIS (or was it ImplicitNamingStrategyStandardImpl?)
>>
>
> Actually, no.  It was always org.hibernate.cfg.EJB3NamingStrategy no
> matter how you bootstrapped.  EJB3NamingStartegy is, unfortunately, not
> really any of these.  To be honest, I am not really sure why that one was
> ever named EJB3; it does not follow the spec in many many cases (even the
> 1.0 spec).  I guess we should make ImplicitNamingStrategyLegacyJpaImpl
> conform to EJB3NamingStartegy and have that be the default.
>
>
>> About names, I'm tempted to have:
>>
>> * ImplicitNamingStrategyJpaCompliantImpl
>> * ImplicitNamingStrategyLegacyJpaImpl
>> * ImplicitNamingStrategyLegacyHbmImpl
>> * ImplicitNamingStrategyComponentPathImpl
>
>
>> The idea is to make the names explicit with the intent. "Standard" does
>> not mean much per se.
>>
>
> Well you asked the question perfectly above :)  "Standard" was not used at
> all to indicate compliance with the spec/standard.  It was used because it
> is the standard/default impl. But still I prefer
> ImplicitNamingStrategyJpaCompliantImpl
>
>
>
>>
>> Emmanuel
>>
>> On Fri 2015-02-20 12:57, Steve Ebersole wrote:
>> > So at the moment I have the following ImplicitNamingStrategy impls:
>> >
>> > 1) ImplicitNamingStrategyStandardImpl - Which is compliant with the
>> rules
>> > set forth in the JPA standard
>> > 2) ImplicitNamingStrategyLegacyJpaImpl - Which implements the initial
>> > support done for JPA 1, before JPA 2 clarified some things.
>> > 3) ImplicitNamingStrategyLegacyHbmImpl - Support dating back to the
>> dawn of
>> > time...
>> > 4) ImplicitNamingStrategyComponentSafeImpl - Mainly a port
>> > of DefaultComponentSafeNamingStrategy, although leveraging the
>> > AttributePath stuff I discussed earlier
>> >
>> > Couple of thoughts...
>> >
>> > First, we might want to rename ImplicitNamingStrategyLegacyJpaImpl to
>> > ImplicitNamingStrategyStandardImpl, and
>> ImplicitNamingStrategyStandardImpl
>> > to ImplicitNamingStrategyJpaCompliantImpl.  WDYT?
>> >
>> > Second, I do not really like the phrase "component safe".  "Safe" from
>> > what?  The difference is that the whole component path is used in
>> > determining the name; so how about
>> ImplicitNamingStrategyComponentPathImpl?
>> >
>> > I do not plan on porting any of the other NamingStrategy impls.
>> >
>> >
>> > Also, here is the complete list of implicit naming hooks:
>> > 1) primary table
>> > 2) join table
>> > 3) collection table
>> > 4) discriminator column
>> > 5) tenant id column
>> > 6) id column (entity and idbag)
>> > 7) basic column
>> > 8) join column
>> > 9) pk join column
>> > 10 ) @Any discriminator column
>> > 11) @Any key column
>> > 12) map key column
>> > 13) list index column
>> > 14) foreign key name
>> > 15) unique key name
>> > 16) index name
>> >
>> >
>> > On Mon, Feb 2, 2015 at 3:13 PM, Emmanuel Bernard <
>> emmanuel at hibernate.org>
>> > wrote:
>> >
>> > > I?d say +1 for adding coverage of them in the implicit naming
>> strategy.
>> > >
>> > > On 02 Feb 2015, at 19:16, Steve Ebersole <steve at hibernate.org> wrote:
>> > >
>> > > They do not.  HBM, e.g., uses "idx" for map keys columns as well as
>> > > list/array index columns.  JPA says to use {attribute-name}_ORDER for
>> list
>> > > index column.  Unless I missed it (which is completely possible in
>> > > annotation binding) we always use the JPA-defined default in those
>> cases
>> > > rather than using any *implicit* naming hooks.
>> > >
>> > > So that is really the question.  Do we want expand the breadth of
>> what is
>> > > covered by implicit naming strategy in this new model?  I think its
>> > > reasonable.
>> > >
>> > > On Mon, Feb 2, 2015 at 11:28 AM, Emmanuel Bernard <
>> emmanuel at hibernate.org>
>> > > wrote:
>> > >
>> > >>
>> > >> On 02 Feb 2015, at 17:51, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> > >>
>> > >> On Mon, Feb 2, 2015 at 8:34 AM, Emmanuel Bernard <
>> emmanuel at hibernate.org>
>> > >>  wrote:
>> > >>
>> > >> I think you?re missing things like @MapKeyColumn, @OrderColumn
>> > >>>
>> > >>
>> > >> So that's a good discussion.  These are things that have previously
>> been
>> > >> hard-coded defaults (at least on hbm side) and therefore had no
>> specific
>> > >> naming strategy hooks.  I'm all for being specific, so if everyone
>> agrees
>> > >> it is a good idea to add methods for stuff like this, I am fine with
>> that.
>> > >>
>> > >>
>> > >> I know JPA has well defined values for these. I am not sure they
>> match
>> > >> 100% the HBM version.
>> > >>
>> > >
>> > >
>> > >
>>
>
>

From sanne at hibernate.org  Thu Feb 26 09:16:33 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 26 Feb 2015 14:16:33 +0000
Subject: [hibernate-dev] Branching strategy in OGM
Message-ID: <CAFm4XO0KUFsxH7bGi0qpCYs8W+KFrpOYxi3k2o2LUK0EVdorqA@mail.gmail.com>

Hey all,
it seems like the branch for maintenance work on OGM 4.1 is (still)
called "master", while a branch "4.2" was created for future work.

I'd really prefer it the other way around: create a branch "4.1" to
host all changes which are needed to be backported on 4.1.x , and call
"master" what will receive all of the latest improvements.

Let's see on IRC when it is a good time to rename the branches? It
better happens "atomically" or it's a mess..

Sanne

From sanne at hibernate.org  Thu Feb 26 09:45:01 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 26 Feb 2015 14:45:01 +0000
Subject: [hibernate-dev] Is HSEARCH-1786/HSEARCH-1814 on the radar
In-Reply-To: <CAGvEgx7TP55J0bXexEaOQLceF4=XxA2fRtjz88FYxtNcr5Gk8Q@mail.gmail.com>
References: <CAGvEgx7TP55J0bXexEaOQLceF4=XxA2fRtjz88FYxtNcr5Gk8Q@mail.gmail.com>
Message-ID: <CAFm4XO3Sp7hXHdDJRJDOANZTzvkiJUvUb4UO6tbMXW_cHuKVRw@mail.gmail.com>

Hi Marc,
those issues are certainly on the radar.

Sorry we didn't work on them yet, as we're doing a big sprint on OGM
currently. We'll be back on Search in a couple of weeks - I might try
to give it a look before that as it seems important but I can't
promise it.

I don't actually remember you sharing erroneous bug reports, but if
you say so ;-)
I'm certainly not ignoring you, pretty sure it's always useful feedback.

But I disagree on saying that current releases are not fit for
production. Sure it's an annoying issue but projecting on IDs isn't
the only feature people use.

If only you could have tested our beta releases ;-) But I understand,
the changes were quite large to scare off most timely migrations.

Cheers,
Sanne


On 25 February 2015 at 13:20, Marc Schipperheyn
<m.schipperheyn at gmail.com> wrote:
> Hi,
>
> Just wondering if HSEARCH-1786/HSEARCH-1814 are on the radar? We have
> stopped all of our upgrade efforts because of this. And if they are valid
> bugs, it basically means that HSEARCH 5.0, and 5.01 are unreliable for
> production use.`
>
> I'm just wondering if it's considered a real bug, if so it's a blocker, or
> perhaps a figment of imagination? I know I have made my share of erronous
> bug reports...
>
> Cheers,
> Marc
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Thu Feb 26 10:26:47 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 26 Feb 2015 16:26:47 +0100
Subject: [hibernate-dev] Branching strategy in OGM
In-Reply-To: <CAFm4XO0KUFsxH7bGi0qpCYs8W+KFrpOYxi3k2o2LUK0EVdorqA@mail.gmail.com>
References: <CAFm4XO0KUFsxH7bGi0qpCYs8W+KFrpOYxi3k2o2LUK0EVdorqA@mail.gmail.com>
Message-ID: <CADGJaX8i7jzyiz8YDqWWJjjKK+xx0PhtEDKhwVOAYMSgXQBmoA@mail.gmail.com>

We did it intentionally that way to avoid any kind of back/forward porting
and keep the history linear.

It's not that these branches are there for a long time, probably only until
tomorrow. 4.2 is meant to be rebased onto master and finally fast-forward
merged to master once 4.1.2 is out. Would be something different if there
was a long-lasting 4.1 branch which needs parallel maintenance, then I'd do
what you suggest.

--Gunnar



2015-02-26 15:16 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> Hey all,
> it seems like the branch for maintenance work on OGM 4.1 is (still)
> called "master", while a branch "4.2" was created for future work.
>
> I'd really prefer it the other way around: create a branch "4.1" to
> host all changes which are needed to be backported on 4.1.x , and call
> "master" what will receive all of the latest improvements.
>
> Let's see on IRC when it is a good time to rename the branches? It
> better happens "atomically" or it's a mess..
>
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Thu Feb 26 10:38:50 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 26 Feb 2015 15:38:50 +0000
Subject: [hibernate-dev] Branching strategy in OGM
In-Reply-To: <CADGJaX8i7jzyiz8YDqWWJjjKK+xx0PhtEDKhwVOAYMSgXQBmoA@mail.gmail.com>
References: <CAFm4XO0KUFsxH7bGi0qpCYs8W+KFrpOYxi3k2o2LUK0EVdorqA@mail.gmail.com>
	<CADGJaX8i7jzyiz8YDqWWJjjKK+xx0PhtEDKhwVOAYMSgXQBmoA@mail.gmail.com>
Message-ID: <CAFm4XO3ZEOZRziY0zL5knsxio+KGuXCqi-kkJSJZOKpHzoBuNQ@mail.gmail.com>

So you intend to do some evil history rewriting on branch 4.2? I don't
think that's expected to happen on the reference repository.

I haven't understood much of it so I'll send PRs to master and let you
merge them wherever you want. Pretty sure I don't want to touch branch
4.2 myself.

On 26 February 2015 at 15:26, Gunnar Morling <gunnar at hibernate.org> wrote:
> We did it intentionally that way to avoid any kind of back/forward porting
> and keep the history linear.
>
> It's not that these branches are there for a long time, probably only until
> tomorrow. 4.2 is meant to be rebased onto master and finally fast-forward
> merged to master once 4.1.2 is out. Would be something different if there
> was a long-lasting 4.1 branch which needs parallel maintenance, then I'd do
> what you suggest.
>
> --Gunnar
>
>
>
> 2015-02-26 15:16 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> Hey all,
>> it seems like the branch for maintenance work on OGM 4.1 is (still)
>> called "master", while a branch "4.2" was created for future work.
>>
>> I'd really prefer it the other way around: create a branch "4.1" to
>> host all changes which are needed to be backported on 4.1.x , and call
>> "master" what will receive all of the latest improvements.
>>
>> Let's see on IRC when it is a good time to rename the branches? It
>> better happens "atomically" or it's a mess..
>>
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From gunnar at hibernate.org  Thu Feb 26 10:44:02 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 26 Feb 2015 16:44:02 +0100
Subject: [hibernate-dev] Branching strategy in OGM
In-Reply-To: <CAFm4XO3ZEOZRziY0zL5knsxio+KGuXCqi-kkJSJZOKpHzoBuNQ@mail.gmail.com>
References: <CAFm4XO0KUFsxH7bGi0qpCYs8W+KFrpOYxi3k2o2LUK0EVdorqA@mail.gmail.com>
	<CADGJaX8i7jzyiz8YDqWWJjjKK+xx0PhtEDKhwVOAYMSgXQBmoA@mail.gmail.com>
	<CAFm4XO3ZEOZRziY0zL5knsxio+KGuXCqi-kkJSJZOKpHzoBuNQ@mail.gmail.com>
Message-ID: <CADGJaX_1Y2CVXFupLZH5zDbXB+B56fzXQ0puCrLrD4P3FGjBkw@mail.gmail.com>

2015-02-26 16:38 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> So you intend to do some evil history rewriting on branch 4.2? I don't
> think that's expected to happen on the reference repository.
>

I don't see a problem with rewriting in this case. It's not master and it's
not there for a long time. It's just a temp. working branch.

I haven't understood much of it so I'll send PRs to master and let you
> merge them wherever you want. Pretty sure I don't want to touch branch
> 4.2 myself.
>

Best is to send PRs to that branch you want them applied to: 4.1.2 ->
master, 4.2 -> 4.2. I'll rebase your OGM-747 branch and merge to 4.2.

On 26 February 2015 at 15:26, Gunnar Morling <gunnar at hibernate.org> wrote:
> > We did it intentionally that way to avoid any kind of back/forward
> porting
> > and keep the history linear.
> >
> > It's not that these branches are there for a long time, probably only
> until
> > tomorrow. 4.2 is meant to be rebased onto master and finally fast-forward
> > merged to master once 4.1.2 is out. Would be something different if there
> > was a long-lasting 4.1 branch which needs parallel maintenance, then I'd
> do
> > what you suggest.
> >
> > --Gunnar
> >
> >
> >
> > 2015-02-26 15:16 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> Hey all,
> >> it seems like the branch for maintenance work on OGM 4.1 is (still)
> >> called "master", while a branch "4.2" was created for future work.
> >>
> >> I'd really prefer it the other way around: create a branch "4.1" to
> >> host all changes which are needed to be backported on 4.1.x , and call
> >> "master" what will receive all of the latest improvements.
> >>
> >> Let's see on IRC when it is a good time to rename the branches? It
> >> better happens "atomically" or it's a mess..
> >>
> >> Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Thu Feb 26 12:47:29 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 26 Feb 2015 17:47:29 +0000
Subject: [hibernate-dev] Branching strategy in OGM
In-Reply-To: <CADGJaX_1Y2CVXFupLZH5zDbXB+B56fzXQ0puCrLrD4P3FGjBkw@mail.gmail.com>
References: <CAFm4XO0KUFsxH7bGi0qpCYs8W+KFrpOYxi3k2o2LUK0EVdorqA@mail.gmail.com>
	<CADGJaX8i7jzyiz8YDqWWJjjKK+xx0PhtEDKhwVOAYMSgXQBmoA@mail.gmail.com>
	<CAFm4XO3ZEOZRziY0zL5knsxio+KGuXCqi-kkJSJZOKpHzoBuNQ@mail.gmail.com>
	<CADGJaX_1Y2CVXFupLZH5zDbXB+B56fzXQ0puCrLrD4P3FGjBkw@mail.gmail.com>
Message-ID: <CAFm4XO1Yzy7a1hWqbD1D3xcMT6BZfsidXCtnirfHn3ZuEp9iKA@mail.gmail.com>

On 26 February 2015 at 15:44, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2015-02-26 16:38 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> So you intend to do some evil history rewriting on branch 4.2? I don't
>> think that's expected to happen on the reference repository.
>
>
> I don't see a problem with rewriting in this case. It's not master and it's
> not there for a long time. It's just a temp. working branch.
>
>> I haven't understood much of it so I'll send PRs to master and let you
>> merge them wherever you want. Pretty sure I don't want to touch branch
>> 4.2 myself.
>
>
> Best is to send PRs to that branch you want them applied to: 4.1.2 ->
> master, 4.2 -> 4.2. I'll rebase your OGM-747 branch and merge to 4.2.

That's not going to work. I just had a minor PR based on 4.2, but it
seems you rewrote 4.2 in the meantime, I had to nuke my branch and
rebuild it from ashes ;)
So you're the only one in control of this 4.2 branch I guess?

>
>> On 26 February 2015 at 15:26, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > We did it intentionally that way to avoid any kind of back/forward
>> > porting
>> > and keep the history linear.
>> >
>> > It's not that these branches are there for a long time, probably only
>> > until
>> > tomorrow. 4.2 is meant to be rebased onto master and finally
>> > fast-forward
>> > merged to master once 4.1.2 is out. Would be something different if
>> > there
>> > was a long-lasting 4.1 branch which needs parallel maintenance, then I'd
>> > do
>> > what you suggest.
>> >
>> > --Gunnar
>> >
>> >
>> >
>> > 2015-02-26 15:16 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>
>> >> Hey all,
>> >> it seems like the branch for maintenance work on OGM 4.1 is (still)
>> >> called "master", while a branch "4.2" was created for future work.
>> >>
>> >> I'd really prefer it the other way around: create a branch "4.1" to
>> >> host all changes which are needed to be backported on 4.1.x , and call
>> >> "master" what will receive all of the latest improvements.
>> >>
>> >> Let's see on IRC when it is a good time to rename the branches? It
>> >> better happens "atomically" or it's a mess..
>> >>
>> >> Sanne
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From gunnar at hibernate.org  Thu Feb 26 13:11:47 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 26 Feb 2015 19:11:47 +0100
Subject: [hibernate-dev] Branching strategy in OGM
In-Reply-To: <CAFm4XO1Yzy7a1hWqbD1D3xcMT6BZfsidXCtnirfHn3ZuEp9iKA@mail.gmail.com>
References: <CAFm4XO0KUFsxH7bGi0qpCYs8W+KFrpOYxi3k2o2LUK0EVdorqA@mail.gmail.com>
	<CADGJaX8i7jzyiz8YDqWWJjjKK+xx0PhtEDKhwVOAYMSgXQBmoA@mail.gmail.com>
	<CAFm4XO3ZEOZRziY0zL5knsxio+KGuXCqi-kkJSJZOKpHzoBuNQ@mail.gmail.com>
	<CADGJaX_1Y2CVXFupLZH5zDbXB+B56fzXQ0puCrLrD4P3FGjBkw@mail.gmail.com>
	<CAFm4XO1Yzy7a1hWqbD1D3xcMT6BZfsidXCtnirfHn3ZuEp9iKA@mail.gmail.com>
Message-ID: <CADGJaX8gK1yD6kqyTA=Rfz-c-OqJC-gFa=p9N6rqgcuAu4LjDg@mail.gmail.com>

2015-02-26 18:47 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> On 26 February 2015 at 15:44, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2015-02-26 16:38 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> So you intend to do some evil history rewriting on branch 4.2? I don't
> >> think that's expected to happen on the reference repository.
> >
> >
> > I don't see a problem with rewriting in this case. It's not master and
> it's
> > not there for a long time. It's just a temp. working branch.
> >
> >> I haven't understood much of it so I'll send PRs to master and let you
> >> merge them wherever you want. Pretty sure I don't want to touch branch
> >> 4.2 myself.
> >
> >
> > Best is to send PRs to that branch you want them applied to: 4.1.2 ->
> > master, 4.2 -> 4.2. I'll rebase your OGM-747 branch and merge to 4.2.
>
> That's not going to work. I just had a minor PR based on 4.2, but it
> seems you rewrote 4.2 in the meantime, I had to nuke my branch and
> rebuild it from ashes ;)
>

Ok, if you consider rebase --onto as rebuilding from ashes ;)

Note that this branch basically was meant for Davide and me. Aren't you
supposed to work on 4.1.2 anyways ;) ? I would say let's do the 4.1.2
release tomorrow and if we then come to decide we need another 4.1.x
release, let's do what you suggest if it really is such a big problem.

But we'll need two PRs for each 4.1.x change then. I didn't expect much
(integrated) traffic on 4.2 in this week so I liked the current approach to
keep the history nicer and avoiding merge/port PRs.

So you're the only one in control of this 4.2 branch I guess?
>

No, not necessarily. You can rebase it after something has been integrated
in 4.1.2 or we leave it as is and do just one final rebase after 4.1.2 has
been released. Just be sure to have the current 4.2 prior to sending a PR
against it.

>
> >
> >> On 26 February 2015 at 15:26, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >> > We did it intentionally that way to avoid any kind of back/forward
> >> > porting
> >> > and keep the history linear.
> >> >
> >> > It's not that these branches are there for a long time, probably only
> >> > until
> >> > tomorrow. 4.2 is meant to be rebased onto master and finally
> >> > fast-forward
> >> > merged to master once 4.1.2 is out. Would be something different if
> >> > there
> >> > was a long-lasting 4.1 branch which needs parallel maintenance, then
> I'd
> >> > do
> >> > what you suggest.
> >> >
> >> > --Gunnar
> >> >
> >> >
> >> >
> >> > 2015-02-26 15:16 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >> >>
> >> >> Hey all,
> >> >> it seems like the branch for maintenance work on OGM 4.1 is (still)
> >> >> called "master", while a branch "4.2" was created for future work.
> >> >>
> >> >> I'd really prefer it the other way around: create a branch "4.1" to
> >> >> host all changes which are needed to be backported on 4.1.x , and
> call
> >> >> "master" what will receive all of the latest improvements.
> >> >>
> >> >> Let's see on IRC when it is a good time to rename the branches? It
> >> >> better happens "atomically" or it's a mess..
> >> >>
> >> >> Sanne
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> >
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>

From sanne at hibernate.org  Thu Feb 26 13:27:10 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 26 Feb 2015 18:27:10 +0000
Subject: [hibernate-dev] Branching strategy in OGM
In-Reply-To: <CADGJaX8gK1yD6kqyTA=Rfz-c-OqJC-gFa=p9N6rqgcuAu4LjDg@mail.gmail.com>
References: <CAFm4XO0KUFsxH7bGi0qpCYs8W+KFrpOYxi3k2o2LUK0EVdorqA@mail.gmail.com>
	<CADGJaX8i7jzyiz8YDqWWJjjKK+xx0PhtEDKhwVOAYMSgXQBmoA@mail.gmail.com>
	<CAFm4XO3ZEOZRziY0zL5knsxio+KGuXCqi-kkJSJZOKpHzoBuNQ@mail.gmail.com>
	<CADGJaX_1Y2CVXFupLZH5zDbXB+B56fzXQ0puCrLrD4P3FGjBkw@mail.gmail.com>
	<CAFm4XO1Yzy7a1hWqbD1D3xcMT6BZfsidXCtnirfHn3ZuEp9iKA@mail.gmail.com>
	<CADGJaX8gK1yD6kqyTA=Rfz-c-OqJC-gFa=p9N6rqgcuAu4LjDg@mail.gmail.com>
Message-ID: <CAFm4XO3LiiBR4z8H1qh6Dk9aEmsKPgmBfNVV4pK-7f2Xs12p1A@mail.gmail.com>

On 26 February 2015 at 18:11, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2015-02-26 18:47 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> On 26 February 2015 at 15:44, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > 2015-02-26 16:38 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>
>> >> So you intend to do some evil history rewriting on branch 4.2? I don't
>> >> think that's expected to happen on the reference repository.
>> >
>> >
>> > I don't see a problem with rewriting in this case. It's not master and
>> > it's
>> > not there for a long time. It's just a temp. working branch.
>> >
>> >> I haven't understood much of it so I'll send PRs to master and let you
>> >> merge them wherever you want. Pretty sure I don't want to touch branch
>> >> 4.2 myself.
>> >
>> >
>> > Best is to send PRs to that branch you want them applied to: 4.1.2 ->
>> > master, 4.2 -> 4.2. I'll rebase your OGM-747 branch and merge to 4.2.
>>
>> That's not going to work. I just had a minor PR based on 4.2, but it
>> seems you rewrote 4.2 in the meantime, I had to nuke my branch and
>> rebuild it from ashes ;)
>
>
> Ok, if you consider rebase --onto as rebuilding from ashes ;)

It doesn't matter what exactly you do, what matters is that my clone
is inconsistent and I have no clue of what could have happened.


> Note that this branch basically was meant for Davide and me. Aren't you
> supposed to work on 4.1.2 anyways ;) ? I would say let's do the 4.1.2
> release tomorrow and if we then come to decide we need another 4.1.x
> release, let's do what you suggest if it really is such a big problem.

Thanks :)
But I didn't say it's a big problem. It's unexpected though, and I
think we had agreed that nobody would ever use push --force on the
reference repository, especially not as a standard development
procedure.

>
> But we'll need two PRs for each 4.1.x change then. I didn't expect much
> (integrated) traffic on 4.2 in this week so I liked the current approach to
> keep the history nicer and avoiding merge/port PRs.
>
>> So you're the only one in control of this 4.2 branch I guess?
>
>
> No, not necessarily. You can rebase it after something has been integrated
> in 4.1.2 or we leave it as is and do just one final rebase after 4.1.2 has
> been released. Just be sure to have the current 4.2 prior to sending a PR
> against it.
>>
>>
>> >
>> >> On 26 February 2015 at 15:26, Gunnar Morling <gunnar at hibernate.org>
>> >> wrote:
>> >> > We did it intentionally that way to avoid any kind of back/forward
>> >> > porting
>> >> > and keep the history linear.
>> >> >
>> >> > It's not that these branches are there for a long time, probably only
>> >> > until
>> >> > tomorrow. 4.2 is meant to be rebased onto master and finally
>> >> > fast-forward
>> >> > merged to master once 4.1.2 is out. Would be something different if
>> >> > there
>> >> > was a long-lasting 4.1 branch which needs parallel maintenance, then
>> >> > I'd
>> >> > do
>> >> > what you suggest.
>> >> >
>> >> > --Gunnar
>> >> >
>> >> >
>> >> >
>> >> > 2015-02-26 15:16 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >> >>
>> >> >> Hey all,
>> >> >> it seems like the branch for maintenance work on OGM 4.1 is (still)
>> >> >> called "master", while a branch "4.2" was created for future work.
>> >> >>
>> >> >> I'd really prefer it the other way around: create a branch "4.1" to
>> >> >> host all changes which are needed to be backported on 4.1.x , and
>> >> >> call
>> >> >> "master" what will receive all of the latest improvements.
>> >> >>
>> >> >> Let's see on IRC when it is a good time to rename the branches? It
>> >> >> better happens "atomically" or it's a mess..
>> >> >>
>> >> >> Sanne
>> >> >> _______________________________________________
>> >> >> hibernate-dev mailing list
>> >> >> hibernate-dev at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >
>> >> >
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>
>

From gunnar at hibernate.org  Thu Feb 26 13:44:22 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 26 Feb 2015 19:44:22 +0100
Subject: [hibernate-dev] Branching strategy in OGM
In-Reply-To: <CAFm4XO3LiiBR4z8H1qh6Dk9aEmsKPgmBfNVV4pK-7f2Xs12p1A@mail.gmail.com>
References: <CAFm4XO0KUFsxH7bGi0qpCYs8W+KFrpOYxi3k2o2LUK0EVdorqA@mail.gmail.com>
	<CADGJaX8i7jzyiz8YDqWWJjjKK+xx0PhtEDKhwVOAYMSgXQBmoA@mail.gmail.com>
	<CAFm4XO3ZEOZRziY0zL5knsxio+KGuXCqi-kkJSJZOKpHzoBuNQ@mail.gmail.com>
	<CADGJaX_1Y2CVXFupLZH5zDbXB+B56fzXQ0puCrLrD4P3FGjBkw@mail.gmail.com>
	<CAFm4XO1Yzy7a1hWqbD1D3xcMT6BZfsidXCtnirfHn3ZuEp9iKA@mail.gmail.com>
	<CADGJaX8gK1yD6kqyTA=Rfz-c-OqJC-gFa=p9N6rqgcuAu4LjDg@mail.gmail.com>
	<CAFm4XO3LiiBR4z8H1qh6Dk9aEmsKPgmBfNVV4pK-7f2Xs12p1A@mail.gmail.com>
Message-ID: <CADGJaX8m8vXPjAU11DaUQDhwJ=vNjNsf7snhdDDHX=9NMNAjeA@mail.gmail.com>

2015-02-26 19:27 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> On 26 February 2015 at 18:11, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2015-02-26 18:47 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> On 26 February 2015 at 15:44, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >> > 2015-02-26 16:38 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >> >>
> >> >> So you intend to do some evil history rewriting on branch 4.2? I
> don't
> >> >> think that's expected to happen on the reference repository.
> >> >
> >> >
> >> > I don't see a problem with rewriting in this case. It's not master and
> >> > it's
> >> > not there for a long time. It's just a temp. working branch.
> >> >
> >> >> I haven't understood much of it so I'll send PRs to master and let
> you
> >> >> merge them wherever you want. Pretty sure I don't want to touch
> branch
> >> >> 4.2 myself.
> >> >
> >> >
> >> > Best is to send PRs to that branch you want them applied to: 4.1.2 ->
> >> > master, 4.2 -> 4.2. I'll rebase your OGM-747 branch and merge to 4.2.
> >>
> >> That's not going to work. I just had a minor PR based on 4.2, but it
> >> seems you rewrote 4.2 in the meantime, I had to nuke my branch and
> >> rebuild it from ashes ;)
> >
> >
> > Ok, if you consider rebase --onto as rebuilding from ashes ;)
>
> It doesn't matter what exactly you do, what matters is that my clone
> is inconsistent and I have no clue of what could have happened.
>
>
> > Note that this branch basically was meant for Davide and me. Aren't you
> > supposed to work on 4.1.2 anyways ;) ? I would say let's do the 4.1.2
> > release tomorrow and if we then come to decide we need another 4.1.x
> > release, let's do what you suggest if it really is such a big problem.
>
> Thanks :)
> But I didn't say it's a big problem. It's unexpected though, and I
> think we had agreed that nobody would ever use push --force on the
> reference repository, especially not as a standard development
> procedure.
>

Sorry, I had discussed it with Davide whom I expected the only one to be
besides me to work on 4.2 at this point. Probably should have send a quick
mail to all.

What you say makes totally sense for master, I don't think the strict rule
needs to be applied for a short living working branch. I still think it's
good as it makes handling on 4.1.x easier for you guys (and those merging
all the PRs), but as said we can change it after 4.1.2 if you prefer.


> >
> > But we'll need two PRs for each 4.1.x change then. I didn't expect much
> > (integrated) traffic on 4.2 in this week so I liked the current approach
> to
> > keep the history nicer and avoiding merge/port PRs.
> >
> >> So you're the only one in control of this 4.2 branch I guess?
> >
> >
> > No, not necessarily. You can rebase it after something has been
> integrated
> > in 4.1.2 or we leave it as is and do just one final rebase after 4.1.2
> has
> > been released. Just be sure to have the current 4.2 prior to sending a PR
> > against it.
> >>
> >>
> >> >
> >> >> On 26 February 2015 at 15:26, Gunnar Morling <gunnar at hibernate.org>
> >> >> wrote:
> >> >> > We did it intentionally that way to avoid any kind of back/forward
> >> >> > porting
> >> >> > and keep the history linear.
> >> >> >
> >> >> > It's not that these branches are there for a long time, probably
> only
> >> >> > until
> >> >> > tomorrow. 4.2 is meant to be rebased onto master and finally
> >> >> > fast-forward
> >> >> > merged to master once 4.1.2 is out. Would be something different if
> >> >> > there
> >> >> > was a long-lasting 4.1 branch which needs parallel maintenance,
> then
> >> >> > I'd
> >> >> > do
> >> >> > what you suggest.
> >> >> >
> >> >> > --Gunnar
> >> >> >
> >> >> >
> >> >> >
> >> >> > 2015-02-26 15:16 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >> >> >>
> >> >> >> Hey all,
> >> >> >> it seems like the branch for maintenance work on OGM 4.1 is
> (still)
> >> >> >> called "master", while a branch "4.2" was created for future work.
> >> >> >>
> >> >> >> I'd really prefer it the other way around: create a branch "4.1"
> to
> >> >> >> host all changes which are needed to be backported on 4.1.x , and
> >> >> >> call
> >> >> >> "master" what will receive all of the latest improvements.
> >> >> >>
> >> >> >> Let's see on IRC when it is a good time to rename the branches? It
> >> >> >> better happens "atomically" or it's a mess..
> >> >> >>
> >> >> >> Sanne
> >> >> >> _______________________________________________
> >> >> >> hibernate-dev mailing list
> >> >> >> hibernate-dev at lists.jboss.org
> >> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> >
> >> >> >
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> >
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Thu Feb 26 14:31:12 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 26 Feb 2015 20:31:12 +0100
Subject: [hibernate-dev] Branching strategy in OGM
In-Reply-To: <CAFm4XO3LiiBR4z8H1qh6Dk9aEmsKPgmBfNVV4pK-7f2Xs12p1A@mail.gmail.com>
References: <CAFm4XO0KUFsxH7bGi0qpCYs8W+KFrpOYxi3k2o2LUK0EVdorqA@mail.gmail.com>
	<CADGJaX8i7jzyiz8YDqWWJjjKK+xx0PhtEDKhwVOAYMSgXQBmoA@mail.gmail.com>
	<CAFm4XO3ZEOZRziY0zL5knsxio+KGuXCqi-kkJSJZOKpHzoBuNQ@mail.gmail.com>
	<CADGJaX_1Y2CVXFupLZH5zDbXB+B56fzXQ0puCrLrD4P3FGjBkw@mail.gmail.com>
	<CAFm4XO1Yzy7a1hWqbD1D3xcMT6BZfsidXCtnirfHn3ZuEp9iKA@mail.gmail.com>
	<CADGJaX8gK1yD6kqyTA=Rfz-c-OqJC-gFa=p9N6rqgcuAu4LjDg@mail.gmail.com>
	<CAFm4XO3LiiBR4z8H1qh6Dk9aEmsKPgmBfNVV4pK-7f2Xs12p1A@mail.gmail.com>
Message-ID: <91B449A2-B3DB-48B7-A42F-099C71D933F8@hibernate.org>


> But I didn't say it's a big problem. It's unexpected though, and I
> think we had agreed that nobody would ever use push --force on the
> reference repository, especially not as a standard development
> procedure.

No-one should ever make a rule absolute *ever*?
See my point? :)

We are just minimizing the double PR overhead for this short and well defined period of time. No biggie as we know why and how we break the force rule.

Emmanuel

From gunnar at hibernate.org  Fri Feb 27 05:05:12 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 27 Feb 2015 11:05:12 +0100
Subject: [hibernate-dev] [OGM] Releases
Message-ID: <CADGJaX_jPLJoWFzrZuGPyu6w3sY1=OfmOEi_d0D2CtA+Wzo86w@mail.gmail.com>

Hi,

As the first week of our OGM sprint ends, it's about time to do a release.

For 4.1.2 we definitely have enough to warrant a release. Sanne, Hardy, do
you guys have any nearly completed changes you'd like to see in? If so,
please let me know. If I don't hear back, I'll kick off the release early
in the afternoon.

With the number of issues remaining, I think a subsequent 4.1.3 release
would be a good move.

For 4.2 it makes sense to wait a bit IMO, so we can get in Davide's changes
around embeddables and a first cut of the error handling SPI.

Any thoughts?

Thanks,

--Gunnar

From hardy at hibernate.org  Fri Feb 27 06:10:29 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 27 Feb 2015 12:10:29 +0100
Subject: [hibernate-dev] [OGM] Releases
In-Reply-To: <CADGJaX_jPLJoWFzrZuGPyu6w3sY1=OfmOEi_d0D2CtA+Wzo86w@mail.gmail.com>
References: <CADGJaX_jPLJoWFzrZuGPyu6w3sY1=OfmOEi_d0D2CtA+Wzo86w@mail.gmail.com>
Message-ID: <20150227111029.GH78865@Sarmakand-4.local>

> For 4.1.2 we definitely have enough to warrant a release. Sanne, Hardy, do
> you guys have any nearly completed changes you'd like to see in? If so,
> please let me know. 

Nothing from my side. Only getting started with the transaction thing.
Also not sure how fast thing will go with my now dug befogged brain :-)

--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/20150227/03d6afc1/attachment.bin 

From gunnar at hibernate.org  Fri Feb 27 10:32:03 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 27 Feb 2015 16:32:03 +0100
Subject: [hibernate-dev] [OGM] Releases
In-Reply-To: <20150227111029.GH78865@Sarmakand-4.local>
References: <CADGJaX_jPLJoWFzrZuGPyu6w3sY1=OfmOEi_d0D2CtA+Wzo86w@mail.gmail.com>
	<20150227111029.GH78865@Sarmakand-4.local>
Message-ID: <CADGJaX8RUyQtQFMMmc2C0Zsx8kYX0kvvCRPJ23VSHiN5Y_4KNw@mail.gmail.com>

Hibernate OGM 4.1.2.Final is up; I will do the "official" blogging/tweeting
etc. on Monday.

I've transitioned the unresolved 4.1.2 issues to a new version 4.1.3:
https://hibernate.atlassian.net/issues/?jql=project%20%3D%20OGM%20AND%20fixVersion%20%3D%204.1.3.Final%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC

--Gunnar


2015-02-27 12:10 GMT+01:00 Hardy Ferentschik <hardy at hibernate.org>:

> > For 4.1.2 we definitely have enough to warrant a release. Sanne, Hardy,
> do
> > you guys have any nearly completed changes you'd like to see in? If so,
> > please let me know.
>
> Nothing from my side. Only getting started with the transaction thing.
> Also not sure how fast thing will go with my now dug befogged brain :-)
>
> --Hardy
>

From emmanuel at hibernate.org  Fri Feb 27 10:45:00 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 27 Feb 2015 16:45:00 +0100
Subject: [hibernate-dev] [OGM] Releases
In-Reply-To: <CADGJaX8RUyQtQFMMmc2C0Zsx8kYX0kvvCRPJ23VSHiN5Y_4KNw@mail.gmail.com>
References: <CADGJaX_jPLJoWFzrZuGPyu6w3sY1=OfmOEi_d0D2CtA+Wzo86w@mail.gmail.com>
	<20150227111029.GH78865@Sarmakand-4.local>
	<CADGJaX8RUyQtQFMMmc2C0Zsx8kYX0kvvCRPJ23VSHiN5Y_4KNw@mail.gmail.com>
Message-ID: <45734EFC-84CE-46F8-A48F-EA5F2A20657B@hibernate.org>

Quite a good flow this week. Let?s keep the ball rolling :)

> On 27 Feb 2015, at 16:32, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Hibernate OGM 4.1.2.Final is up; I will do the "official" blogging/tweeting
> etc. on Monday.
> 
> I've transitioned the unresolved 4.1.2 issues to a new version 4.1.3:
> https://hibernate.atlassian.net/issues/?jql=project%20%3D%20OGM%20AND%20fixVersion%20%3D%204.1.3.Final%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
> 
> --Gunnar
> 
> 
> 2015-02-27 12:10 GMT+01:00 Hardy Ferentschik <hardy at hibernate.org>:
> 
>>> For 4.1.2 we definitely have enough to warrant a release. Sanne, Hardy,
>> do
>>> you guys have any nearly completed changes you'd like to see in? If so,
>>> please let me know.
>> 
>> Nothing from my side. Only getting started with the transaction thing.
>> Also not sure how fast thing will go with my now dug befogged brain :-)
>> 
>> --Hardy
>> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From mih_vlad at yahoo.com  Fri Feb 27 18:07:12 2015
From: mih_vlad at yahoo.com (Mihalcea Vlad)
Date: Fri, 27 Feb 2015 23:07:12 +0000 (UTC)
Subject: [hibernate-dev] JPA PessimisticLockScope.EXTENDED specs are not
 properly implemented
In-Reply-To: <423453802.1459584.1425077420270.JavaMail.yahoo@mail.yahoo.com>
References: <423453802.1459584.1425077420270.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <481928667.857.1425078432981.JavaMail.yahoo@mail.yahoo.com>





 Hi,
  According to JPA specification, when using PessimisticLockScope.EXTENDED:
In addition to the behavior for PessimisticLockScope.NORMAL, element collections and relationships owned by the entity that are contained in join tables will be locked if the javax.persistence.lock.scope property is specified with a value of PessimisticLockScope.EXTENDED. The state of entities referenced by such relationships will not be locked (unless those entities are explicitly locked). Locking such a relationship or element collection generally locks only the rows in the join table or collection table for that relationship or collection. This means that phantoms will be possible.
So if I define the following Parent/Child associations:@Entity
public class Post {

    @Id
    @GeneratedValue(strategy= GenerationType.IDENTITY)
    private Long id;

    private String name;

    @ElementCollection
    @JoinTable(name = "post_comments", joinColumns = @JoinColumn(name = "post_id"))
    @OrderColumn(name = "comment_index")
    private List<Comment> comments = new ArrayList<Comment>();

    @Version
    private int version;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public List<Comment> getComments() {
        return comments;
    }

    public final int getVersion() {
        return version;
    }

    public void addComment(Comment comment) {
        comments.add(comment);
    }
}

@Embeddable
public class Comment {

    private String review;

    public String getReview() {
        return review;
    }

    public void setReview(String review) {
        this.review = review;
    }
}
Because a Post has a collection of Comment components, an EXTENDED lock request should lock the joined table rows as well, without locking the actual Comment row-level locks:Post post = entityManager.find(Post.class, parentId);
entityManager.lock(post, LockModeType.PESSIMISTIC_WRITE, Collections.singletonMap("javax.persistence.lock.scope", (Object) PessimisticLockScope.EXTENDED));
                return null;
But the output SQL looks like this:Unable to find source-code formatter for language: shell. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xmlINFO  [main]: n.t.d.l.CommonsQueryLoggingListener - Name:, Time:0, Num:1, Query:{[select post0_.id as id1_16_0_, post0_.name as name2_16_0_, post0_.version as version3_16_0_ from Post post0_ where post0_.id=?][1]} 
INFO  [main]: n.t.d.l.CommonsQueryLoggingListener - Name:, Time:1, Num:1, Query:{[select id from Post where id =? and version =? for update][1,0]} 
So, only the root Entity was locked, when we should have locked the post_comments associated rows as well.
Code available on GitHub. You have to run the HibernateCascadeLockComponentTest test. 
This issue is also described on JIRA:
https://hibernate.atlassian.net/browse/HHH-9636

Vlad Mihalcea