Re: [hibernate-dev] [HSEARCH] Full-text query returning projection of one element

2015-02-02 Thread Emmanuel Bernard
+1 for 6 > On 29 Jan 2015, at 09:49, Gunnar Morling 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 ) >.

Re: [hibernate-dev] [HSEARCH] Faster way to get a query builder

2015-02-02 Thread Emmanuel Bernard
> On 29 Jan 2015, at 16:00, Gunnar Morling 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

Re: [hibernate-dev] [HSEARCH] Faster way to get a query builder

2015-02-02 Thread Emmanuel Bernard
> On 29 Jan 2015, at 16:03, Sanne Grinovero wrote: > > On 29 January 2015 at 14:19, Emmanuel Bernard wrote: >> https://gist.github.com/emmanuelbernard/3ca431a8fa58b69cf6c3 >> >> >> //curent >> QueryBuilder b = ftem.getSearchFactor

Re: [hibernate-dev] Naming and "naming strategies"

2015-02-02 Thread Emmanuel Bernard
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? E

Re: [hibernate-dev] Naming and "naming strategies"

2015-02-02 Thread Steve Ebersole
On Mon, Feb 2, 2015 at 8:34 AM, Emmanuel Bernard 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 a

Re: [hibernate-dev] Naming and "naming strategies"

2015-02-02 Thread Emmanuel Bernard
> On 02 Feb 2015, at 17:51, Steve Ebersole wrote: > > On Mon, Feb 2, 2015 at 8:34 AM, Emmanuel Bernard > wrote: > > I think you’re missing things like @MapKeyColumn, @OrderColumn > > So that's a good discussion. These are things that have previously been > ha

[hibernate-dev] [HSEARCH] Free form speed meeting

2015-02-02 Thread Emmanuel Bernard
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/h

Re: [hibernate-dev] Naming and "naming strategies"

2015-02-02 Thread Steve Ebersole
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 usin

Re: [hibernate-dev] Naming and "naming strategies"

2015-02-02 Thread Hardy Ferentschik
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

Re: [hibernate-dev] Naming and "naming strategies"

2015-02-02 Thread Emmanuel Bernard
I’d say +1 for adding coverage of them in the implicit naming strategy. > On 02 Feb 2015, at 19:16, Steve Ebersole 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