Re: [hibernate-dev] [Search] Deprecating the @Key annotation

Hi, > It would be nice to simply remove the references to @Key in the > documentation, and avoid trying to explain when to choose between the > two alternatives. > > This would imply to deprecate the annotation.. any objection? +1 for not mentioning it in the docs. Not sure whether this implies

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

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 p

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

I hadn't noticed that HQL projections would do that. It seems useful indeed, but also quite irregular.. I'm not too convinced, I guess I'd be happier if we could express the difference on the method signature's return type. I tend to agree that we should conform to the list() contract, but this is

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

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

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

2015-01-29 13:31 GMT+01:00 Sanne Grinovero : > I hadn't noticed that HQL projections would do that. > It seems useful indeed, but also quite irregular.. I'm not too > convinced, I guess I'd be happier if we could express the difference > on the method signature's return type. > > I tend to agree t

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

On 29 January 2015 at 14:39, Gunnar Morling wrote: > 2015-01-29 13:31 GMT+01:00 Sanne Grinovero : >> >> I hadn't noticed that HQL projections would do that. >> It seems useful indeed, but also quite irregular.. I'm not too >> convinced, I guess I'd be happier if we could express the difference >>

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

How would the last one be done? You would define overridesForField on QueryBuilder and prohibit its usage after anything else on the builder has been invoked? Or, you could have two different methods: QueryBuilder getQueryBuilder(Class entityType); QueryBuilderContext buildQueryBuilder(Cl

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

On 29 January 2015 at 14:19, Emmanuel Bernard wrote: > https://gist.github.com/emmanuelbernard/3ca431a8fa58b69cf6c3 > > > //curent > QueryBuilder b = ftem.getSearchFactory().buildQueryBuilder().forEntity( > Hike.class ).get(); > > //

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

On 29 January 2015 at 15: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? > > Or, you could have two different methods: > > QueryBuilder getQueryBuilder

Re: [hibernate-dev] [Search] Deprecating the @Key annotation

2015-01-29 9:42 GMT+01:00 Hardy Ferentschik : > Hi, > > > It would be nice to simply remove the references to @Key in the > > documentation, and avoid trying to explain when to choose between the > > two alternatives. > > > > This would imply to deprecate the annotation.. any objection? > > +1 for

[hibernate-dev] Some migration pains HSearch 5

So, I've started migrating our production environment to HSearch 5 at long last. Some of the initial pains that may warrant some documentation love: * @IndexedEmbedded basically inverts the default because before HSearch 5, the default was essentially: @IndexedEmbedded(includeEmbeddedObjectId=tru

[hibernate-dev] Hibernate ORM 4.2.18.Final released

I am having problems creating a weblog entry on in.relation.to. I will send another announcement with details when that is resolved. Gail Badner Red Hat, Hibernate ORM ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/

Re: [hibernate-dev] Some migration pains HSearch 5

Thanks a lot Marc, that's very useful. Some comments inline: On 29 January 2015 at 19:27, Marc Schipperheyn wrote: > So, I've started migrating our production environment to HSearch 5 at long > last. > > Some of the initial pains that may warrant some documentation love: > > * @IndexedEmbedded ba