[hibernate-dev] HSEARCH-706 - work in progress comments

[Hardy Ferentschik]

On Thu, 10 Mar 2011 13:27:30 +0100, Sanne Grinovero  
<sanne.grinovero at 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