Works perfectly. Thanks Mike! Best, -d
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: http://www.nabble.com/difficulty- >> using-SolrHighlighter-with-programmatic-parameters- >> tf4759887.html#a13729108 >> Sent from the Solr - Dev mailing list archive at Nabble.com. >> > > > -- View this message in context: http://www.nabble.com/difficulty-using-SolrHighlighter-with-programmatic-parameters-tf4759887.html#a13740011 Sent from the Solr - Dev mailing list archive at Nabble.com.
