You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Doug Daniels <dd...@rooftophq.com> on 2007/11/06 18:58:14 UTC
difficulty using SolrHighlighter with programmatic parameters
I'm working on creating a custom RequestHandler plugin right now, and am
having some trouble getting it working with the SolrHighlighter.
Particularly, I'd like to specify whether to highlight, which fields to
highlight, etc in the code rather than through the request parameters. I
can't find a way to do that right now, as the doHighlighting method pulls
SolrParams directly from the request, and SolrParams don't seem to support
modification.
I think it would work for me if doHighlighting took a SolrParams parameter,
rather than pulling it out of the request. Any objections to that?
Thanks,
Doug
--
View this message in context: http://www.nabble.com/difficulty-using-SolrHighlighter-with-programmatic-parameters-tf4759887.html#a13612249
Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: difficulty using SolrHighlighter with programmatic parameters
Posted by Doug Daniels <dd...@rooftophq.com>.
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.
Re: difficulty using SolrHighlighter with programmatic parameters
Posted by Mike Klaas <mi...@gmail.com>.
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.
>
Re: difficulty using SolrHighlighter with programmatic parameters
Posted by Doug Daniels <dd...@rooftophq.com>.
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.
Re: difficulty using SolrHighlighter with programmatic parameters
Posted by Doug Daniels <dd...@rooftophq.com>.
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#a13636341
Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: difficulty using SolrHighlighter with programmatic parameters
Posted by Mike Klaas <mi...@gmail.com>.
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
> Thanks,
> -Doug
>
>
> Mike Klaas wrote:
>>
>> On 6-Nov-07, at 9:58 AM, Doug Daniels wrote:
>>
>>>
>>> I'm working on creating a custom RequestHandler plugin right now,
>>> and am
>>> having some trouble getting it working with the SolrHighlighter.
>>> Particularly, I'd like to specify whether to highlight, which
>>> fields to
>>> highlight, etc in the code rather than through the request
>>> parameters. I
>>> can't find a way to do that right now, as the doHighlighting method
>>> pulls
>>> SolrParams directly from the request, and SolrParams don't seem to
>>> support
>>> modification.
>>>
>>> I think it would work for me if doHighlighting took a SolrParams
>>> parameter,
>>> rather than pulling it out of the request. Any objections to that?
>>
>> I think that would work, but there should be a version with the
>> existing interface preserved. Several of the existing methods will
>> have to be refactored to accept param + other stuff that
>> SolrQueryRequest provides (like IndexSearcher, IndexReader, etc).
>>
>> -Mike
>>
>>
>
> --
> View this message in context: http://www.nabble.com/difficulty-
> using-SolrHighlighter-with-programmatic-parameters-
> tf4759887.html#a13613688
> Sent from the Solr - Dev mailing list archive at Nabble.com.
>
Re: difficulty using SolrHighlighter with programmatic parameters
Posted by Doug Daniels <dd...@rooftophq.com>.
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?
Thanks,
-Doug
Mike Klaas wrote:
>
> On 6-Nov-07, at 9:58 AM, Doug Daniels wrote:
>
>>
>> I'm working on creating a custom RequestHandler plugin right now,
>> and am
>> having some trouble getting it working with the SolrHighlighter.
>> Particularly, I'd like to specify whether to highlight, which
>> fields to
>> highlight, etc in the code rather than through the request
>> parameters. I
>> can't find a way to do that right now, as the doHighlighting method
>> pulls
>> SolrParams directly from the request, and SolrParams don't seem to
>> support
>> modification.
>>
>> I think it would work for me if doHighlighting took a SolrParams
>> parameter,
>> rather than pulling it out of the request. Any objections to that?
>
> I think that would work, but there should be a version with the
> existing interface preserved. Several of the existing methods will
> have to be refactored to accept param + other stuff that
> SolrQueryRequest provides (like IndexSearcher, IndexReader, etc).
>
> -Mike
>
>
--
View this message in context: http://www.nabble.com/difficulty-using-SolrHighlighter-with-programmatic-parameters-tf4759887.html#a13613688
Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: difficulty using SolrHighlighter with programmatic parameters
Posted by Mike Klaas <mi...@gmail.com>.
On 6-Nov-07, at 9:58 AM, Doug Daniels wrote:
>
> I'm working on creating a custom RequestHandler plugin right now,
> and am
> having some trouble getting it working with the SolrHighlighter.
> Particularly, I'd like to specify whether to highlight, which
> fields to
> highlight, etc in the code rather than through the request
> parameters. I
> can't find a way to do that right now, as the doHighlighting method
> pulls
> SolrParams directly from the request, and SolrParams don't seem to
> support
> modification.
>
> I think it would work for me if doHighlighting took a SolrParams
> parameter,
> rather than pulling it out of the request. Any objections to that?
I think that would work, but there should be a version with the
existing interface preserved. Several of the existing methods will
have to be refactored to accept param + other stuff that
SolrQueryRequest provides (like IndexSearcher, IndexReader, etc).
-Mike