Hmmm, interesting. Without thinking about it much, I like the idea of having the ability to know when something unexpected happens, I wonder how many developer-hours have been wasted tracking down rq=blah rather than fq=blah...
Now if you would do a check that would catch it when I put in df rathern than qf for edismax.... Erick On Mon, Mar 10, 2014 at 2:10 PM, Shawn Heisey <s...@elyograg.org> wrote: > On 3/10/2014 7:20 AM, Erick Erickson wrote: >> Hmmm, scanning just Noble's comment it's even worse since we have custom >> components that may define their own params that other components know >> nothing about (and can't). >> >> But I'm glancing at this out of context so may be off in the weeds. > > Noble's comment is in response to something I said that came out of left > field. It probably shouldn't have been mentioned there, especially on a > closed issue. > > Specifically, I have been assuming for a while now (because of some past > precedents) that Solr will be moving towards hard failures with any > unknown parameter. > > It sounds like that's not going to actually happen, at least not anytime > soon. In order to even be possible in the context of custom components, > the check would have to happen after all components have consumed their > options, and the custom code would need to *remove* options from the > NamedList rather than just read them. > > ----- > > It does bring up an improvement idea though - a requestHandler > configuration option for the handling of unknown parameters. I > personally would like to know when our code is using unknown parameters > so that the code can be updated. > > There would be three possible settings. Setting #1 is just as it is now > - unknown parameters are completely ignored. Setting #2 would log a > warning and process the request. Setting #3 would fail the request with > some 4xx HTTP error. > > I'm sure there would be a lot of debate about this new option, > especially on the subject of when/if we need to change the default from > setting #1. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
