[
https://issues.apache.org/jira/browse/SOLR-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15096748#comment-15096748
]
Hoss Man commented on SOLR-2798:
--------------------------------
My off the cuff personal opinions w/o reviewing the code and all usages:
* the local param parsing should produce an instance of SolrParams
** given the way the "int" return value is used, i guess that would mean the
"target" param should be changed to take in a ModifiableSolrParams instance.
* the simplest way to go about this, would probably be:
*# refactor the guts of the current method to implement this new API (correctly)
*# add back a deprecated method with the old signature that delegates to the
new API and uses the result to populate it's Map<String,String> in a back
compat way
*# start converting all existing usages of the (now deprecated) old method API
to the one that uses ModifiableSolrParams
...the key question being: how hard will that last step be? hopefully not too
bad.
----
On a tangential note: Demian, i would like to sincerely thank you for sticking
with this issue -- both your previous offer to help, and your more recent
proposed solution -- even though you never got any responses.
> 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]
