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

[Emmanuel Bernard]

> 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.