Re: [hibernate-dev] [HSearch] Faceting feedback
Thanks for the feedback. Answers inline
On Tue, 01 Mar 2011 14:39:58 +0100, Emmanuel Bernard
<emmanuel(a)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