lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Klaas <>
Subject Re: difficulty using SolrHighlighter with programmatic parameters
Date Tue, 13 Nov 2007 19:25:10 GMT
Hi Doug,

I was thinking about this on the weekend.  There isn't actually a  
need for SolrParams to be mutable, nor does that seem particularly  
desirable.  However, SolrQueryRequest's SolrParams can be re-set.   
So, if you create a new SolrParams by "modifying" the original  
(essentially, with toMultiMap() and MultiMapSolrParams), then adding  
it to the request (see the U.setDefaults() line in  
RequestHandlerBase).  Incidentally, U.setDefaults should probably use  
req.getOrigParams rather than getParams(), so that it is idempotent  
with the same arguments.

Does that mostly cover the use cases you envision?


On 13-Nov-07, at 8:17 AM, Doug Daniels wrote:

> Hey Mike,
> Should I produce a patch that takes all the parameters explicitly?
> I also might be able to workaround this scenario w/o changing the
> SolrHighlighter if the SolrParams were mutable.  Is that feasible?
> Thanks,
> Doug
> Doug Daniels wrote:
>> I'm doing a lot of user- and social-network specific search, where  
>> the
>> query fields, selected field list, sorting, and highlighting are are
>> dependent on who is searching.  I'm trying to abstract that  
>> complexity
>> behind a simpler request interface than the usual dismax one,  
>> allowing me
>> to say something like user=123 rather than specifying each of the
>> parameters to craft the search.  This is important because I  
>> expect to
>> have multiple clients hitting solr, and would like to avoid crafting
>> complex, dynamic queries in multiple places.
>> I like the idea of using the standard fixtures in solrconfig.xml,  
>> but it
>> doesn't fit one requirement I need, which is to change the  
>> fragment size
>> for user-specific fields.  In my schema, these fields have dynamic  
>> names
>> containing the user ID, so I can't specify them ahead of time in the
>> solrconfig w/o using some sort of wildcard-ish scheme.  At that  
>> point, it
>> seems expedient to switch over to programmatic definition rather than
>> declarative in the XML.
>> I dropped a patch that just adds SolrParams in JIRA 406, but agree  
>> that
>> it's more clear to list out the elements we need from the request
>> individually, if a bit verbose.  I start getting a bad feeling when a
>> method takes 7 parameters.  That said, is there any why the
>> SolrHighlighter behaves like a Singleton right now?  Seems that  
>> this would
>> be easier if it took parameters in a constructor rather than to each
>> method.
>> Thanks,
>> -d
>> Mike Klaas wrote:
>>> On 6-Nov-07, at 11:13 AM, Doug Daniels wrote:
>>>> I could just add the SolrParams parameter to various methods and
>>>> leave the
>>>> IndexSearcher, IndexSchema, IndexReader, etc packaged inside the
>>>> SolrQueryRequest.  I don't suspect that these parameters will need
>>>> to be
>>>> modified by plugin request handlers.
>>>> Is there a convention for this elsewhere in the code?
>>> Well, I am wary of creating a disconnect where we are using _some_
>>> values from SolrQueryRequest and ignoring others.  It seems
>>> inconsistent.
>>> What exactly are you trying to accomplish?  Can you not set the
>>> parameters as fixtures in solrconfig.xml?
>>> cheers,
>>> -Mike
> -- 
> View this message in context: 
> using-SolrHighlighter-with-programmatic-parameters- 
> tf4759887.html#a13729108
> Sent from the Solr - Dev mailing list archive at

View raw message