You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Frank Wesemann (JIRA)" <ji...@apache.org> on 2010/05/19 16:46:57 UTC

[jira] Commented: (LUCENE-2469) inconsistency in SolrParams.get()

    [ https://issues.apache.org/jira/browse/LUCENE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869152#action_12869152 ] 

Frank Wesemann commented on LUCENE-2469:
----------------------------------------

Chris Hostetter already comment on the mailing list:
{quote}
: 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.


-Hoss

{quote}

> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org