On Apr 3, 2012, at 12:37 PM, Benson Margulies wrote: > On Tue, Apr 3, 2012 at 12:27 PM, Grant Ingersoll <gsing...@apache.org> wrote: >> >> On Apr 3, 2012, at 9:43 AM, Benson Margulies wrote: >> >>> I've made a RequestHandler class that acts as follows: >>> >>> 1. At its initialization, it creates a StandardRequestHandler and hangs >>> onto it. >>> 2. When a query comes to it (I configure it to a custom qt value), it: >>> a. creates a new query based on the query that arrived >>> b. creates a LocalSolrQueryRequest for the current core and a param >>> set containing the derived query >>> c. runs this request through the SearchHandler >>> d. uses a searcher to retrieve all the docs >>> e. rescores/reorders them using our code >>> f. attaches the result of this process to the response. The >>> rescoring code creates a DocSlice containing the usual items, and that >>> becomes "response". >>> >> >> Couldn't you just implement a Function (that calls your code) and use sort >> by function and/or use that value as part of the broader match? Lot less >> moving parts, etc. > > I don't know. Feel free to point me at doc at any point, but here's > the questions that spring to mind: > > Starting with something in 'q' like: > > bt_rni_name:"Mortimer Q Snerd" bt_rni_Name_Language:eng > > code of mine eats those two fields (in some sense, pseudo-fields), and > spits out many other fields that we actually want to query on. > > Then, when the results come back, a whole slew of other fields are > used to calculate the 'real' score. > > Do Functions do that?
Not alone, but a QueryParser (eat the fields, spit out others) plus a Function (calculate the score) probably would and it would allow you to satisfy #2. Not sure about item #3 in your original, as I haven't looked at the new UI code.
