inconsistency in SolrParams.get()
---------------------------------

                 Key: LUCENE-2469
                 URL: https://issues.apache.org/jira/browse/LUCENE-2469
             Project: Lucene - Java
          Issue Type: Bug
          Components: Other
         Environment: all
            Reporter: Frank Wesemann


The returned value from solrParams.get( key ) depends on the implementing class 
such that:

{code}
modifiableParams = new ModifiableSolrParams( req.getParams() );
assert modifiableParams.get("key").equals( req.getParams().get("key") );
{code}
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.

This behaviour has also side effects on search components:
Most, if not all, standard search components check for something like

if (reg.getParams().getBool(myTriggerParameter, false) ) {

   ...do what I am supposed to do...

}

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, ... 

Nonetheless I think, the above mentioned equality check should hold true for 
any request and any SolrParams. 

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() etc. 
cases. 




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to