On Sat, 2006-12-23 at 18:41 -0800, Chris Hostetter wrote:
> : I did a small hack and it works like a charm without the above mentioned
> : handler. I only activated variable substitution for the FQ for testing
> : if you think that is a nice feature I can activate it for the rest.
>
> As i said in my other reply ... i think you should reconsider the approach
> you are taking towards your end goal --
Yes, I will. Thanks for the headsup.
> but in general, this of allowing
> variable substitution in the lucene query params seems pretty slick to me
> ... a more general solution might be to modify the SolrQueryParser
> directly to have a new "void setParamVariables(SolrParams p)" method. if
> it's called (with non null input), then any string that SolrQueryParser
> instance is asked to parse would first be preprocessed looking for the ${}
> pattern and pulling the values out of the SOlrParams instance.
>
When does the setParamVariables(SolrParams p) get called? What should
happen in this method?
> request handlers could then either pass their main params (if they wanted
> to allow kitchen sink param substitution) or if they want to be more
> robust (ie: Standard and DisMax), they could do what you describe: have a
> configured list of param
> names that would be used to construct a new instance of SOlrParams
> explicitly for the SolrQueryParser -- but i would think that would be be a
> good use for a new seperate init param in the solrconfig, it's not hte
> kind of thing you'd ever want to let the client specify.
>
not sure whether I understand.
You mean
<requestHandler name="standard" class="solr.StandardRequestHandler">
<!-- default values for the SolrQueryParser -->
<lst name="substitution">
<str name="startDate">*</str>
<str name="endDate">*</str>
</lst>
<!-- default values for query parameters -->
<lst name="defaults">
<str name="echoParams">explicit</str>
<str name="fq">bojaDate:[${startDate} TO ${endDate}]</str>
</lst>
</requestHandler>
...
public class StandardRequestHandler implements SolrRequestHandler,
SolrInfoMBean {
...
public void init(NamedList args) {
...
o = args.get("substitution");
if (o != null && o instanceof NamedList) {
substitution = SolrParams.toSolrParams((NamedList)o);
}
...
}
}
> The reason this really seems cool to me is because it the format/params
> passing could work in either order: the format could be specificed in the
> config with params coming from the client, or the config could list a big
> long list of "constant" params that the client could then use however they
> want by specifying a format that used them.
Yeah, I will open an issue.
Cheers for the feedback.
salu2
