lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Daniels <>
Subject Re: difficulty using SolrHighlighter with programmatic parameters
Date Wed, 14 Nov 2007 04:58:52 GMT

Works perfectly.  Thanks Mike!


Mike Klaas wrote:
> 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?
> regards,
> -Mike
> 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 this message in context:
Sent from the Solr - Dev mailing list archive at

View raw message