Re: [hibernate-dev] HSEARCH-706 - work in progress comments
On Thu, 10 Mar 2011 13:27:30 +0100, Sanne Grinovero
<sanne.grinovero(a)gmail.com> wrote:
It seems you're making a choice of the FieldCache type by looking
at
the classtype of the parameters of the FacetRequest.
(which then invokes
org.hibernate.search.query.fieldcache.FieldCacheLoadingType.getLoadingStrategy(String,
Class<?>))
Shouldn't it use the fieldName instead, to figure out the fieldbridges
and options from the DocumentBuilder ?
Yes, I think I will need some information about the field bridges. Not
sure to which extend.
Faceting really only makes sense where I have fields with discrete
comparable values. Really
we are talking strings, numbers and dates.
I have seen your code in DocumentBuilderIndexedEntity and will have a
closer look, but first
I want to finish something else.
I'm actually using the
FieldCache.DEFAULT.getFloats/Ints/Doubles
only in case it's indexed using the respective NumericField, all other
cases are considered indexed as Strings, eventually converted back
using the TwoWayStringBridge we enabled by default, or as overridden
by use annotations.
The reason I am using int/float/double arrays is also because of the
required comparison
for range queries. Say I have a price expressed as an int and want a range
facet
for 10 - 1000. I need to numerically compare the field values against this
range and not
as string.
I'd say that whatever TwoWayFieldBridge was configured, should be
more
reliable/flexible than to rely on Lucene's default int parser, but I'm
not having strong opinions. Maybe we should have some more tests on
special cases to make the implications clear.
Yes, we need more tests here. I'll be back on this one