Re: [hibernate-dev] [HSearch] Facet drilldown
On Mon, 14 Mar 2011 15:29:03 +0100, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
While implementing it I've found several proposals for
enhancement:
- should we rename in thw facet DSL createFacet to
createFacetRequest(), as it's the object returned
+1
- jpa.FullTextQuery does not have the facet methods
+1 Aleady
fixed on my feature, however, via delegation
- move Facet methods hosted on FTQuery to a FacetManager interface
and
do ftQuery.getFacetManager().enableFacet("cdscds");
no sure about this
one. What other benefits does this approach have except
the reuse for the JPA query?
- make FacetRequest / FacetResults interfaces?
After
discussion this morning I actually got rid of FacetResult, since in
the end one is only interested in
the actual Facets.
- Facet should implement equals / hashCode or else we cannot
remember
the facet selected
+1
- //TODO should the index be included in object Facet? Not sure but
worth thinking about => probably not if Facet objects change indexes
from one query to the other
Not sure what you mean.
- should we rename Facet to FacetElement? We seem to talk about
Facets
as the global concept whereas Facet the object represent one of the
results of the Facet.
For me the global concept is "Faceting" and a Facet
is indeed a single
result.
But I see where you are coming from. We call it FacetRequest and
enableFacet()
Maybe we should rename these though. FacetingRequest? It's just so much
harder to pronounce ;-)
I've worked on an alternative API that internalize the management
of
this facet element selection so that the whole filter tree can be
managed by Hibernate Search itself and exposed to the user as a service
https://gist.github.com/869145
Adding some comments there.
--Hardy