Thanks, great feedback as always. > 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.
Right. I am most interested in getting the API right atm. Do you think that filtering has a worse performance than executing a new query? Obviously we can wrap the FacetFilters in CachingWrapperFilter. One thing I am still not sure about is my use of NumericRangeFilter for the numeric range facets. This requires that the faceted field is actually a @NumericField. Given the performance benefits of a numeric field, it just makes sense to use in your mapping, but should we cater for other cases as well? > 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? You are right. FacetResult does not contain much information. Once could even think about pushing the field name into Facet (even though it would be duplicated then in each Facet). What you are loosing by query.getFacets( facetName ) is the ability to iterate over the enabled facets. At the very least you have to take care yourself of which facet names are set. In intermediate step would be to get rid of FacetResult, but keep returning a Map. So instead of Map<String, FacetResult> we have a Map<String, List<Facet>>. Or we go query.getFacets( facetName ), but also add a query.getEnabledFacetNames() --Hardy _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
