On Thu, 10 Mar 2011 13:27:30 +0100, Sanne Grinovero <sanne.grinov...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
