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.
