[
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
