I very much support a plugin architecture for ResponseHandlers.
One aspect could be a "Responselet" which adds something to the response, as
detailed in Ryan's example below. Quite valuable in itself.
But another aspect could be a "Querylet" which adds something to the query
before execution. For example, if we were to bust up the venerable old (!)
DisMaxRequestHandler into constituent parts:
a) Escaped dismax query spanning multiple field^boost combinations, with
configurable minShouldMatch
b) Escaped adjacency (phrase) query contributing to document boost
c) Supplemental term-based boosting queries
d) Supplemental function-based boosting queries
e) Filter queries (also in StandardRH, but in both cases not part of main
query construction)
I don't see any reason (c) and (d) and perhaps (b) can't be used for
Standard-style queries. Unless I'm mistaken, that could be accomplished with
some refactoring and inheritance (getMainQuery(...), getBoostingQueries(...)),
but a plugin architecture would be rather more flexible.
Perhaps response and query plugins should be treated as independent cases, with
the latter deferred to a different discussion, but it would be awfully nice if
DisMaxRH differed from StandardRH only as a construction in solrconfig.xml!
<BlueSky>
Quickly thinking aloud...
If a plugin declared whether it needed to be run pre-query or post-query (or
non-query), and for post-query whether it needs DocListAndSet or just DocList,
perhaps the structure could be something like:
For each pre- or non-query plugin
plugin(SolrParams, Response, MainQuery, FilterQuery)
-> (SolrParams, Response, MainQuery, FilterQuery)
Execute Query
For each post-query plugin
plugin(SolrParams, Response, DocList/Set)
-> (SolrParams, Response, DocList/Set, ...)
Which suggests to me that instead of formal params, the plugins could
communicate through a self-extensible Map-derived namespace, with predefined
names for rendezvous but allowing two or more plugins to pass information to
each other with locally define parameter names.
The namespace could be lazy with generators, e.g. the first request for
"DocSet" would execute the query and add DocList and DocSet entries to it.
Hmm, perhaps it ALL could be implemented as lazy generators...
</BlueSky>
Anyway, it's a thought which would obviously need to be worked out much more
thoroughly.
- J.J.
At 11:04 AM -0700 6/10/07, Ryan McKinley wrote:
> // choose one query method
> docs = Query( req, debug )
> - standard
> - dismax
> - mlt (as input)
> - ...
>
> // zero or more...
> info[] = Info( req, docs, debug )
> + facet
> + mlt (on each result)
> + ...
...
