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

Sanne Grinovero sanne at hibernate.org
Thu Jan 29 10:03:16 EST 2015


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();


--Sanne


More information about the hibernate-dev mailing list