[
https://issues.apache.org/jira/browse/SOLR-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15096728#comment-15096728
]
Demian Katz commented on SOLR-2798:
-----------------------------------
Did a bit of digging on my own. Looks like the problem lies here:
https://github.com/apache/lucene-solr/blob/74e96fa51cfed251fa516d496e126212413cbafc/solr/core/src/java/org/apache/solr/search/QueryParsing.java#L94
The parseLocalParams() function takes a target parameter which is a Map<String,
String>. Do we perhaps need to change this to a Map<String, String[]> and then
adjust all calling code to deal with the String array in the map? This seems to
have fairly broad-reaching consequences (such as impacting the MapSolrParams
class). As a newcomer to the code base, I'm hesitant to attempt any such
refactoring... but if anyone has suggestions for a general course of action,
I'm willing to put some time into attempting something.
> Local Param parsing does not support multivalued params
> -------------------------------------------------------
>
> Key: SOLR-2798
> URL: https://issues.apache.org/jira/browse/SOLR-2798
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Assignee: Anshum Gupta
>
> As noted by Demian on the solr-user mailing list, Local Param parsing seems
> to use a "last one wins" approach when parsing multivalued params.
> In this example, the value of "111" is completely ignored:
> {code}
> http://localhost:8983/solr/select?debug=query&q={!dismax%20bq=111%20bq=222}foo
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]