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

On 29 Jan 2015, at 16:00, Gunnar Morling <gunnar(a)hibernate.org&gt; 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?

On 29 Jan 2015, at 16:03, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: On 29 January 2015 at 14:19, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; 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();