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

[Sanne Grinovero]

2011/3/10 Hardy Ferentschik <hibernate at ferentschik.de>:
> 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.

sure, just make sure you wrap your collector around the
TwoWayTransformingFieldCacheCollector
and you'll get the objects instead of the strings, so your Collector
implementation doesn't even have to change.


>> 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
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>