lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] Commented: (SOLR-112) Hierarchical Handler Config
Date Thu, 18 Jan 2007 08:59:30 GMT


Hoss Man commented on SOLR-112:

Damn Ryan ... you keep taking on cool features nad churning out patches too fast for me to
read them!

this sounds like a cool idea, the one big caveat is documenting exactly how the NamedList
"merge" method you wrote is expected to work ... ie:
  * what it does if both named lists have the same key?
  * does it do deep merging of nested named list/collections?
  * what does it do if one list has an element without a name (first and formost a 
    NamedLIst is an order list after all - the names are optional) far as unit tests go, the easiest way to test something like this is to start by writing
a unit test of just the NamedList mergin logic -- independent of anything else (this class
would be a good place to put a test of the SOLR-107 changes too by the way).  

next would be to test that the merge logic is getting used as you expect, with a test that
uses a config file with several handlers all inheriting various properties from one another,
and then a test that does queries against them -- the easiest way to do validate that the
init params were getting inherited correctly would probably be to use an "EchoConfigRequestHandler"
that looked something like this...

   public class EchoConfigRequestHandler impliments SolrRequestHandler {
     private NamedList initParams;
     public void init(NamedList nl) { initParams = nl);
     public void handleRequest(SOlrQueryRequest req, SolrQueryResponse rsp) {

the AbstractSolrTestClass makes it easy for you to use any solrconfig file you want by overriding
a method -- so you could even write one test case using one config file with lots of examples
of inherited init params and a test method for each asserting that the params are what is
expected, and then subclass it with another test class instance that's exactly the same except
for the using a differnet solrconfig file where all of hte params are duplicated out explicitly
-- testing your assumptions so to speak.

> Hierarchical Handler Config
> ---------------------------
>                 Key: SOLR-112
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: update
>    Affects Versions: 1.2
>            Reporter: Ryan McKinley
>            Priority: Minor
>             Fix For: 1.2
>         Attachments: SOLR-112.patch
> From J.J. Larrea on SOLR-104
> 2. What would make this even more powerful would be the ability to "subclass" (meaning
refine and/or extend) request handler configs: If the requestHandler element allowed an attribute
extends="<another-requesthandler-name>" and chained the SolrParams, then one could do
something like:
>   <requestHandler name="search/products/all" class="solr.DisMaxRequestHandler" >
>     <lst name="defaults">
>      <float name="tie">0.01</float>
>      <str name="qf">
>         text^0.5 features^1.0 name^1.2 sku^1.5 id^10.0 manu^1.1 cat^1.4
>      </str>
>      ... much more, per the "dismax" example in the sample solrconfig.xml ...
>   </requestHandler>
>   ... and replacing the "partitioned" example ...
>   <requestHandler name="search/products/instock" extends="search/products/all" >
>     <lst name="appends">
>       <str name="fq">inStock:true</str>
>     </lst>
>   </requestHandler>

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message