apache / apache/lucene

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

Open
#3,543 2 comments 0 reactions 0 assignees View on GitHub
legacy-jira-priority:Major module:core/other type:bug
Dominant language
Java
Stars
3.6k
Forks
1.4k
Avg merge
2d 11h
Merged PRs (30d)
88

Description

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

```Java
modifiableParams = new ModifiableSolrParams( req.getParams() );
assert modifiableParams.get("key").equals( req.getParams().get("key") );
```

fails for requests built from a SimpleRequestParser or StandardRequestParser where the parameter "key" was given, but empty ( e.g. localhost:8393/select/?key=¶1=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.

---
Migrated from [LUCENE-2469](https://issues.apache.org/jira/browse/LUCENE-2469) by Frank Wesemann, updated Jun 11 2010
Environment:
```
all
```

Contributor guide

Open the contributing guide

Research direction

Compare ServletSolrParams with the other SolrParams implementations, using the SimpleRequestParser and StandardRequestParser empty-parameter examples as the starting point. Trace get(), getBool(), and getInt() behavior for an empty value and determine a consistent result that preserves the reported equality and search-component behavior; done means the behavior is covered for all affected implementations.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend, search
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.