lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: inconsistency in SolrParams.get()
Date Wed, 12 May 2010 19:29:39 GMT

: this test fails for requests built from a SimpleRequestParser or
: StandardRequestParser where the parameter "key" was given, but empty ( e.g.
: localhost:8393/select/?key=&para1=val1&parm2=val2 ).
: The reason is that oas.request.ServletSolrParams returns null for values with
: length() == 0,
: but all other SolrParams implementations return the empty String.

Hmmm, can you please open a bug for this?

: In case of ServletSolrParams getBool() returns the desired and expected
: "false",
: all other Implementations throw a "bad request" Exception.
: One may argue that suppling a parameter with an empty value indeed is a
: malformed request,

that would be my off the cuff opinion -- It seems like ServletSolrParams 
is the one with the bug since it isn't correctly retunring the empty 
string that was specified by the user (in the case of booleans this may be 
handy, but for other params the ineability to specify an empty string to 
override the default value could be problematic (ie: if you want 
highlighter fragments but you want blank pre/post markup)

: Because I cannot oversee the implications, I currently don't have a better
: suggestion to achieve this, than
: to make ServleSolrParams also return the empty String, which is in my opinion
: counter-intuitive and does not the right thing for the getBool(), getInt()

there may be ways to address these in particular: treating the empty 
string as equivilent to null in the type specific parsing code, but i also 
haven't through it through all the way.

: is ModifiableSolrParams.set(key, null) removes key from the params really the
: desired and expected behaviour?

I believe so -- null is used to indicate that no value exists.


View raw message