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