On 9/8/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
I was talking to a coworker yesterday who has recently started using hte
DisMax handler ... she was annoyed that the "fq" param could only be
specified once (which was changed as part of the SimpleFacet patch so
that's all good) but she was also annoyed that having an "fq" default in
the solrconfig was completely overridden by an "fq" in the URL --
What's the usecase here, and the downside to having to provide the
full fq list in the URL?
Is this simply to shorten the request URLs?
something that's still true with the recent changes. There's currently no
way to specify some params in the config that can be "added to" by the
params in the URL.
Of course once you make it so that something is always appended, that
will annoy someone else who wants to completely override it :-)
An alternative is to provide some sort of syntactic support for
specifying the append operation rather than the overwrite operation
w.r.t. defaults.
fq+=color:red
I'm not sure how hard it would be to support that exact syntax w/
SolrParams and HttpServletRequest though.
It could also be done more at the "application level", putting some
sort of indicator in the value that the param should be appended, not
overwritten.
fq=+color:red
Of course '+' is reserved by Lucene, and by url encoding, but you get the idea.
-Yonik
Generalized support for being able to say "The default value list for
param P is A B C, and at query time I want to add X and Y and eliminate B"
seems like a a really hard problem to solve, but i was thinking of a
simpler approach that might still achieve the more common case where we
want values specified in a config to allways be "appended" to multivalue
params using somehting like this psuedo-java...
public class MergedParams extends DefaultSolrParams {
public String[] getParams(String param) {
return params.getParams(param).addAll(defaults.getParams(param));
}
}
and request handlers could support this using something like...
<requestHandler name="dismax" class="solr.DisMaxRequestHandler" >
<lst name="appended">
<str name="fq">inStock:true</str>
</lst>
<lst name="default">
<str name="fq">color:red</str>
<str name="fq">price:[* TO 100]</str>
</lst>
</requestHandler>
...with the existing DefaultSolrParams wrapped in an MergedParams using
the "appended" section. Now a request for "/select/?qt=dismax&q=foo"
would get all three "fqs" applied, but a request for
"/select/?qt=dismax&q=foo&fq=color:blue" would only have two filters
applied (must be inStock, must be blue) ... this would be particularly
handy when trying to use "fq" to globally partition your index, as well as
provide "drill down" filtering options.
The same MergedParams could even support a <lst name="prepended"> set
of params which would work exactly the same for multivalue params (like
fq), but would allow the config to dictate the values of single value
params (like "rows", "facet") so thatthey can't be overidden at query
time.
What do you guys think?
-Hoss
