lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Grotzke <>
Subject Re: Dynamically calculated range facet
Date Wed, 27 Jun 2007 16:15:03 GMT
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,

> 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

View raw message