[ https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675811#comment-16675811 ]
Hoss Man commented on SOLR-12959: --------------------------------- {quote} I thought "json.nl" is what toggles these two representations: {quote} As documented in the ref guide: {{json.nl}} is how users indicate how they would like solr to deal with NamedLists *"where order is more important than access by name. "* ... SimpleOrderedMap instances are returned by Solr in use cases where order is *NOT* more important then access by name. These are not competing/duplicated classes ... it is not a "mistake" that we have & use both in diff places in the code (although it has been argued in the past that it's a mistake we have/use _either_ instead of requiring more type safe objects). NamedList exists as a way to store & return an *ordered* list of items which can have names (where the names are not required to be unique). SimpleOrdereMap was added as a subclass later as a way to indicate in building up response structures that while there is an order to the elements, that order is _secondary_ in importance to the key=>value mapping. (In situations where there is no ordering, then absolutely Map should be used.) This allows us to have general purpose response *structures* that can be agnostic to when/where the resulting serialization – and the choosen serialization impl can preserve order whenever possible/convinient based on the format (ie: xml/javabin regarldess of NamedList impl), but when dealing with some serialization formats / client libraries (ie: json/javascript) where it would be simplier/desirable in many cases to ignore the inherient ordering of the pairs (ie: stored fields in a document) we can do so while still having an option ("json.nl") for controlling/allowing a more verbose syntax when it's fundemental to the nature of hte data (ie: facet terms+>value mappings) This difference is fundemental to *why* and how clients consuming JSON can see get simple "Map" style representation (where most JSON parsing libraries will throw away the ordering) of the overall response, or of individual documents, or the echParam output, – while still being able to retrieve a strictly ordered set of results for things like facet terms (where the representation can be varried by modifiing {{json.nl}} *w/o affecting other ordered lists lists like documents, echoParams, etc...* ---- Compare/contrast... {noformat} $ curl "http://localhost:8983/solr/techproducts/select?q=ipod&fl=id,name&facet=true&facet.field=features&facet.limit=4" { "responseHeader":{ "status":0, "QTime":2, "params":{ "q":"ipod", "facet.limit":"4", "facet.field":"features", "fl":"id,name", "facet":"true"}}, "response":{"numFound":3,"start":0,"docs":[ { "id":"IW-02", "name":"iPod & iPod Mini USB 2.0 Cable"}, { "id":"F8V7067-APL-KIT", "name":"Belkin Mobile Power Cord for iPod w/ Dock"}, { "id":"MA147LL/A", "name":"Apple 60 GB iPod with Video Playback Black"}] }, "facet_counts":{ "facet_queries":{}, "facet_fields":{ "features":[ "adapter",2, "car",2, "power",2, "white",2]}, "facet_ranges":{}, "facet_intervals":{}, "facet_heatmaps":{}}} {noformat} {noformat} $ curl "http://localhost:8983/solr/techproducts/select?q=ipod&fl=id,name&facet=true&facet.field=features&facet.limit=4&json.nl=arrmap" { "responseHeader":{ "status":0, "QTime":1, "params":{ "q":"ipod", "facet.limit":"4", "facet.field":"features", "json.nl":"arrmap", "fl":"id,name", "facet":"true"}}, "response":{"numFound":3,"start":0,"docs":[ { "id":"IW-02", "name":"iPod & iPod Mini USB 2.0 Cable"}, { "id":"F8V7067-APL-KIT", "name":"Belkin Mobile Power Cord for iPod w/ Dock"}, { "id":"MA147LL/A", "name":"Apple 60 GB iPod with Video Playback Black"}] }, "facet_counts":{ "facet_queries":{}, "facet_fields":{ "features": [ {"adapter":2}, {"car":2}, {"power":2}, {"white":2}]}, "facet_ranges":{}, "facet_intervals":{}, "facet_heatmaps":{}}} {noformat} > Deprecate solrj SimpleOrderedMap > -------------------------------- > > Key: SOLR-12959 > URL: https://issues.apache.org/jira/browse/SOLR-12959 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ > Reporter: Noble Paul > Priority: Minor > > There is no difference between a NamedList and a SumpleOrderedMap. It > doesn't help to have both of them when they are doing exactly free same things -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org