lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thorsten.scherler....@juntadeandalucia.es>
Subject variable substitution in lucene query params (was Re: filter input from multiple fields)
Date Tue, 26 Dec 2006 09:00:03 GMT
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


Mime
View raw message