On Tue, 2007-06-26 at 23:22 -0700, Chris Hostetter wrote: > : So if it would be possible to go over each item in the search result > : I could check the price field and define my ranges for the specific > : query on solr side and return the price ranges as a facet. > > : Otherwise, what would be a good starting point to plug in such > : functionality into solr? > > if you relaly want to do statistical distributions, one way to avoid doing > all of this work on the client side (and needing to pull back all of hte > prices from all of hte matches) would be to write a custom request handler > that subclasses whichever on you currently use and does this computation > on the server side -- where it has lower level access to the data and > doesn't need to stream it over the wire. FieldCache in particular would > come in handy. Now we want to have fun with statistics and calculation, and I just set up a new project with a dependency on apache-solr-1.2.0. I started a RangeRequestHandler extending StandardRequestHandler, but I don't really see where to plug in. Most probably it's the handleRequestBody, but there's a lot of stuff in StandardRequestHandler.handleRequestBody that I do not want to repeat...
To ask a question: how could I get each document of the result to check the price and do some calculation at the end? Logging that to stdout would be fine at first, afterwards I would like to add a new facet to the result with some info. Thanx in advance, cheers, Martin > > it occurs to me that even though there may not be a way to dynamicly > create facet ranges that can apply usefully on any numeric field, we could > add generic support to the request handlers for optionally fetching some > basic statistics about a DocSet for clients that want them (either for > building ranges, or for any other purpose) > > min, max, mean, median, mode, midrange ... those should all be easy to > compute using the ValueSource from the field type (it would be nice if > FieldType's had some way of indicating which DocValues function can best > manage the field type, but we can always assume float or have an option > for dictating it ... people might want a float mean for an int field > anyway) > > i suppose even stddev could be computed fairly easily ... there's a > formula for that that works well in a single pass over a bunch of values > right? > > > > > -Hoss > -- Martin Grotzke http://www.javakaffee.de/blog/
signature.asc
Description: This is a digitally signed message part
