[hibernate-dev] [HSearch] Faceting feedback

[Hardy Ferentschik]

Thanks for the feedback. Answers inline

On Tue, 01 Mar 2011 14:39:58 +0100, Emmanuel Bernard  
<emmanuel at hibernate.org> wrote:

> To avoid the problem of Constructor multiplications and still use  
> immutable objects use a builder to collect the information and create  
> the object out of it. The constructor can even be package private

I guess that the third alternative. If I remember right that is also a  
pattern
described in "Effective Java". I am mainly wondering what it really gives  
me
to make these objects immutable.

> My initial reaction was that facet would be an awesome declarative  
> feature like analyzers at least for simple use case (annotations +  
> programmatic mapping API). So +1 for the feature. It seems though that  
> some people would want a very dynamic way to configure their facet so  
> keeping a programmatic API seems to make sense as well. I am not a  
> expert in faceting so feel free to correct me. If we are not sure, let's  
> start with the pure declarative approach and expand to the programmatic  
> API later.

I think we will need both.

> In tests, we should try and use the Query DSL instead of raw lucene  
> queries: we try to convert people to this nicer approach and it shows us  
> how well or abd the rest of the API is when integrated.

Just haven't gotten into the habit yet. Personally I am still thinking in  
Lucene
queries.

> To be consistent, SimpleFacetRequest should be named  
> DiscreteFacetRequest to be symmetric with RangeFacetRequest.

DiscreteFacetRequest is a much better name. thanks

> Sanne was mentioning the idea of lazy results. Be careful if this  
> laziness means keeping some resources open, we usually don't do that  
> (except when using scroll).

Right. This whole idea needs to be thought through, but I think it is worth
perusing.

> It's a shame e can't add payload to lucene queries to integrate that  
> further.

It will be interesting to see how Lucene will add the basic faceting code  
to its
API. At least they started talking about it.

> FacetRequest request =
> carBuilder
>   .facet()
>     .named("prices")
>     .range() //or should it be range(Integer.class)
>     .onField("price")
>     .from(0).to(1000).excludeLimit()
>     .from(1000).to(1500).excludeLimit()
>     .above(1500)
>     .orderedBy(FIELD_VALUE);
>
> query.enableFacet(request);

Got you. This brings up another question. Should we only have this DSL  
based approach or should we
keep also have the current programmatic approach. If we keep it all we end  
could end up
with annotation, DSL and "standard programmatic" versions of the API

> I am getting a bit worried about these APIs that are used under certain  
> conditions only like getFacetResults(). I wonder if we could do  
> something nicer. I have no real solution, maybe via composition or via  
> the returned object of enableFacet?

Same here. This was another question I forgot to add to my original email.  
It would be nice to  find a solution
for this.

--Hardy