[
https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675873#comment-16675873
]
Hoss Man commented on SOLR-12959:
---------------------------------
{quote}Neither echoParams (a SolrParams) nor the stored fields (a SolrDocument)
are held as NamedLists and thus don't apply in your example.
{quote}
To be clear: echoParams _absolutely_ applies in my example ... it's *BECAUSE*
the params are put in the response as a SimpleOrderedMap (which, as a reminder,
is a _subclass_ of NamedList) that they are *always* returned to the json
client as "simple (ordered) map" regardless of the value of {{json.nl}}
(but yes, SolrDocuments are an analogous structure in the response, not
actually implemented as SimpleOrderedMaps ... sorry if that was missleading)
{quote}I wonder... in places where we are using SimpleOrderedMap in a response,
and thus the "access by key" is most significant... (i.e. it's map-ness is most
significant)... maybe we should just switch over to say LinkedHashMap? [...]
the demands of the two seem to me to compete with each other: ease of access by
key & repeated keys are kinda incompatible ...
{quote}
Not really ... the _allowance_ of duplicated keys goes back to the fact that
NamedLists (which reminder: SimpleOrderedMap is a subclass of) are
fundementally "lists of things which may have names" – and the names frequently
comes from users, and we allow them to duplicated because that's what the user
asked for, and (it was decided long ago that) when it is in fact very easy to
give the user what they asked for, that's better then silently/accidentally
throwing away data by *only* using a (Linked)Map, or throwing an explicit
error.
For example: a user who accidently uses the same key to in two diff
{{facet.field}} params...
{noformat}
$ curl
'http://localhost:8983/solr/techproducts/select?q=ipod&rows=0&facet=true&facet.field=%7B!key=xxx%7Dfeatures&facet.field=%7B!key=xxx%7Dmanu_id_s&facet.limit=1&omitHeader=true&wt=xml'
<?xml version="1.0" encoding="UTF-8"?>
<response>
<result name="response" numFound="3" start="0">
</result>
<lst name="facet_counts">
<lst name="facet_queries"/>
<lst name="facet_fields">
<lst name="xxx">
<int name="adapter">2</int>
</lst>
<lst name="xxx">
<int name="belkin">2</int>
</lst>
</lst>
<lst name="facet_ranges"/>
<lst name="facet_intervals"/>
<lst name="facet_heatmaps"/>
</lst>
</response>
{noformat}
Should the faceting code hard fail on this (or silently drop one of them)
because it *MIGHT* cause a problem/confusion in serialization to JSON ... even
though the user may be using a format like XML where they don't actaully care
about the "key" and plan on consuming them in order?
> 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
