[hibernate-dev] [HSearch] Facet drilldown

Hardy Ferentschik hibernate at ferentschik.de
Mon Mar 14 11:33:29 EDT 2011


On Mon, 14 Mar 2011 15:29:03 +0100, Emmanuel Bernard  
<emmanuel at 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



More information about the hibernate-dev mailing list