On Mon, 14 Mar 2011 15:29:03 +0100, Emmanuel Bernard
<emman...@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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
