Hi Hardy, the filtering idea is looking great. I'm wondering how this affects performance, but I guess we can focus on API and feature for now.
I'm a bit concerned on the result type of a faceting query, it seems that even your own tests need a three-liner helper method to get to the value you actually need. What about trying to improve that, like from the current form: List<Facet> facetList = query.getFacetResults().get( facetName ).getFacets(); shorter: List<Facet> facetList = query.getFacets( facetName ); WDYT? This way nor getFieldName() nor getName() from FacetResult would be available, but you're never ever invoking them from any test, so I'm wondering if they are actually useful: I'd expect the user of getFacets to know which field he is querying. In FacetBuildingContext, FacetFilter, FacetRequest, Facet you're using a StringBuffer instead of a StringBuilder, using some "vintage" toString generator ? https://github.com/hferentschik/hibernate-search/pull/1 Cheers, Sanne 2011/3/11 Hardy Ferentschik <hibern...@ferentschik.de>: > Hi, > > sorry for the following lengthy code example, but it is hard to > demonstrate this much shorter. > The example shows how you can enable multiple facets and then continuously > restrict the query result > by chaining facets into a FacetFilter (which delegates to a ChainedFilter > underneath). WDYT? > If you want to see all the code or even get the feature branch - > https://github.com/hferentschik/hibernate-search/blob/HSEARCH-706 > > > public void testMultipleFacetDrillDown() throws Exception { > final String ccsFacetName = "ccs"; > final String ccsFacetFieldName = "cubicCapacity"; > FacetRequest ccsFacetRequest = queryBuilder( Car.class > ).facet() > .name( ccsFacetName ) > .onField( ccsFacetFieldName ) > .discrete() > .createFacet(); > > final String colorFacetName = "color"; > final String colorFacetFieldName = "color"; > FacetRequest colorFacetRequest = queryBuilder( Car.class > ).facet() > .name( colorFacetName ) > .onField( colorFacetFieldName ) > .discrete() > .createFacet(); > > FullTextQuery query = createMatchAllQuery( Car.class ); > query.enableFacet( colorFacetRequest ); > query.enableFacet( ccsFacetRequest ); > assertEquals( "Wrong number of query matches", 50, > query.getResultSize() > ); > > List<Facet> colorFacetList = getFacetListForFacet( query, > colorFacetName > ); > assertFacetCounts( colorFacetList, new int[] { 12, 12, 12, 12, > 2 } ); > > List<Facet> ccsFacetList = getFacetListForFacet( query, > ccsFacetName ); > assertFacetCounts( ccsFacetList, new int[] { 17, 16, 16, 1 } ); > > FacetFilter facetFilter = new FacetFilter(); > query.setFilter( facetFilter ); > > facetFilter.addFacet( colorFacetList.get( 0 ) ); > colorFacetList = getFacetListForFacet( query, colorFacetName ); > assertFacetCounts( colorFacetList, new int[] { 12, 0, 0, 0, 0 > } ); > > ccsFacetList = getFacetListForFacet( query, ccsFacetName ); > assertFacetCounts( ccsFacetList, new int[] { 4, 4, 4, 0 } ); > > facetFilter.addFacet( ccsFacetList.get( 0 ) ); > // needs to set the filter explicitly atm, because I need the > query > state to reset > query.setFilter( facetFilter ); > colorFacetList = getFacetListForFacet( query, colorFacetName ); > assertFacetCounts( colorFacetList, new int[] { 4, 0, 0, 0, 0 } > ); > > ccsFacetList = getFacetListForFacet( query, ccsFacetName ); > assertFacetCounts( ccsFacetList, new int[] { 4, 0, 0, 0 } ); > } > > I like the idea of using Lucene Filters to implement the drilldown for. It > seems the most natural and the original query stays > untouched. > > --Hardy > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
