[ https://issues.apache.org/jira/browse/SOLR-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14297777#comment-14297777 ]
yuanyun.cn edited comment on SOLR-7059 at 1/29/15 10:11 PM: ------------------------------------------------------------ The change works well, but it's kind of weird now: the value type of map in MapSolrParams is declared as String, but now the value can actually be string or string[]. protected final Map<String,String> map; The following code would be kind of weird and difficult to maintain: in get method: as the map is Map<String,String> , so map.get should return string - but not in this case, as the value can be string or string[].. Object o = map.get(name); ///// if (o instanceof String) return (String) o; if (o instanceof String[]) { } in toString: the val is declared as object - not as string(the entry is Entry<String,String>), because the value can be string or string[]. for (Map.Entry<String,String> entry : map.entrySet()) { String key = entry.getKey(); Object val = entry.getValue(); //// } This breaks java generic and compiler check, make it harder to maintain. We should open one new JIRA to refactor MapSolrParams: Maybe change Map<String,String> to Map<String,String[]> just as ModifiableSolrParams. This will require a lot of code change: but it's worth. Also in Lucene/Solr, we still use raw collectio - not parameterized, we should consider refactor it a bit to make the code cleaner. was (Author: yuanyun.cn): The change works well, but it's kind of weird now: the value type of map in MapSolrParams is declared as String, but now the value can actually be string or string[]. protected final Map<String,String> map; The following code would be kind of weird and difficult to maintain: in get method: as the map is Map<String,String> , so map.get should return string - but not in this case, as the value can be string or string[].. Object o = map.get(name); ///// if (o instanceof String) return (String) o; if (o instanceof String[]) { } in toString: the val is declared as object - not as string(the entry is Entry<String,String>), because the value can be string or string[]. for (Map.Entry<String,String> entry : map.entrySet()) { String key = entry.getKey(); Object val = entry.getValue(); //// } This breaks java generic and compiler check, make it harder to maintain. We should open one new JIRA to refactor MapSolrParams: Maybe change Map<String,String> to Map<String,String[]> just as ModifiableSolrParams. Also in Lucene/Solr, we still use raw collectio - not parameterized, we should consider refactor it a bit to make the code cleaner. > Using paramset with multi-valued keys leads to a 500 > ---------------------------------------------------- > > Key: SOLR-7059 > URL: https://issues.apache.org/jira/browse/SOLR-7059 > Project: Solr > Issue Type: Bug > Affects Versions: 5.0 > Reporter: Anshum Gupta > Assignee: Noble Paul > Fix For: 5.0, Trunk, 5.1 > > > Here's my use case: > I wanted to use param-sets to have {{facet.field=field1&facet.field=field2}} > For the same, here is what I updated: > {code} > curl http://localhost:8983/solr/bike/config/params -H > 'Content-type:application/json' -d > '{ > "set" : { > "facets" : { > "facet.field":["start_station_name","end_station_name"] > } > } > }' > {code} > When I tried to use the same, I got a 500. > After looking at the code, seems like, RequestParams uses MapSolrParams, > which banks on Map<String,String> map. > This would need to change to support the multi-values. > I also tried sending: > {code} > solr-5.0.0-SNAPSHOT > curl http://localhost:8983/solr/bike/config/params -H > 'Content-type:application/json' -d '{"update" : { "facets" : > {"facet.field":"start_station_name","facet.field":"end_station_name"}}}' > {code} > This overwrote the value of facet.field with the last seen/parsed value i.e. > there was only one value in the end. This is expected as that's noggit's > behavior i.e. doesn't complain and just overwrites the previous value with > the same key. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org