[
https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16676078#comment-16676078
]
Noble Paul commented on SOLR-12959:
-----------------------------------
bq.[~ab] says the current classes were meant to save memory (something worth
testing since java has evolved a great deal since they were created
Yes. you are right. Let's try to understand the requirement
>From the serializatiopn point of view, it's just a {{Map}} and nothing else
We can have an interface called {{SolrMap}} which is always be serialized into
a {{Map}} like structure. We can have memory efficient/inefficient
implemenatations of the same class.
The problem today is we have tied the wire format () with a Solid java class
which actually means nothing to the users (or even developers)
bq.The handling of duplicate keys is a feature..
it's not a feature. It's a price we pay for the memory efficiency of using a
{{NamedList}} like class.
bq.So it would be necessary to verify performance and find widespread agreement
that that back compatibility break is feasible and worthwhile
The performance impact is is well known . We should keep sensible interfaces
and multiple implementations depending on how much price we want to pay.
JSON only understands a {{Map}} like Object. it does not matter for other
serialization formats anyway
> 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: [email protected]
For additional commands, e-mail: [email protected]
