[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[
https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16683188#comment-16683188
]
Noble Paul commented on SOLR-12959:
---
Perf runs runs using the various Map like containers
* NamedList
* HashMap
* LinkedHashMap
* FastOrderedMap : This is a new container backed by a NamedList but lookups
are done using a lazily created map. The map is constructed only if a
key based lookup is performed
{code}
TOTAL_KEYS : 1000
TOTAL_OBJS : 1
TOTAL_LOOKUPS : 100
---
ram usage KB FASTORDEREDMAP: 108969
time taken FOM: 222
---
LinkedHashMap ram usage KB: 471371
time taken LINKEDMAP: 210
---
HASHMAP ram usage KB: 393179
time taken HASHMAP: 207
---
ram usage KB NL: 109039
time taken NamedList: 3022
=
TOTAL_KEYS : 100
TOTAL_OBJS : 1
TOTAL_LOOKUPS : 100
---
ram usage KB NL: 9844
time taken NamedList: 493
---
LinkedHashMap ram usage KB: 49809
time taken LINKEDMAP: 187
---
HASHMAP ram usage KB: 41929
time taken HASHMAP: 185
---
ram usage KB FASTORDEREDMAP: 10368
time taken FOM: 205
{code}
> 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
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[ https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679138#comment-16679138 ] Noble Paul commented on SOLR-12959: --- bq.One way to help find it may be to temporarily override add() to assert the key doesn't already exist then see which tests fail. sounds good > 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
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[ https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16676096#comment-16676096 ] David Smiley commented on SOLR-12959: - I concur with Noble & Gus's opinion that handling duplicate keys where you want to convey a map is more likely indicative of a bug that ought to be loudly reported to the user than it is a feature. Well said guys. But perhaps a realistic example could present itself to the contrary. One way to help find it may be to temporarily override add() to assert the key doesn't already exist then see which tests fail. I guess my satisfaction point is merely this: in 8.0 SimpleOrderedMap is nowhere to be found. Either remove or rename it or do it some other way (e.g. boolean on NL). We can do better folks. > 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
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[ https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16676061#comment-16676061 ] Gus Heck commented on SOLR-12959: - [~noble.paul] I agree that it would be very nice to be able to use a standard collection class instead of NamedList from a programmer convenience standpoint. I've had this thought many times too, but expected such a road to be bumpy and controversial and so I didn't start down it :). It seems from the above so far that 2 things stand in the way (identified thus far) # [~ab] says the current classes were meant to save memory (something worth testing since java has evolved a great deal since they were created, named lists are mentioned in SOLR-17 so they clearly predate our bug tracking system) # The handling of duplicate keys is a feature. Personally, if I were the user I'd want the above example hos gave with accidentally duplicated names to throw an error, not give me back something that *I would* probably subsequently throw away when I stuffed the results into a map or tried to build a JavaScript object out of it... So it would be necessary to verify performance and find widespread agreement that that back compatibility break is feasible and worthwhile Also note that the code you quote is using SimpleOrderedMap to override and ignore the json.nl setting. > 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
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[ https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16676005#comment-16676005 ] Gus Heck commented on SOLR-12959: - Ah, just noticed the set of constants in JsonTextWriter... those plus an USER_SPECIFIED (the default) could be used for the enum, and the value in the named list overrides the value in json.nl creating the same effect and giving us options of using any of those formats where we want (without creating subclasses) > 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
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[
https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16676003#comment-16676003
]
Noble Paul commented on SOLR-12959:
---
* In code {{SimpleOrderedMap}} is exactly same as {{NamedList}}
* In javabin or XML or any other format , {{SimpleOrderedMap}} is exactly the
same
* In {{JSON}} response, the default behavior for both {{NamedList}} and
{{SimpleOrderedMap}} are serialized exactly same way
* When we choose the {{namedListStyle}} to be something else ,
{{SimpleOrderedMap}} is serialized as {{JSON_NL_MAP}} .
The following is the code for serializing {{NaMedList}} / {{SimpleOrderedMap}}
{code:java}
default void writeNamedList(String name, NamedList val) throws IOException {
String namedListStyle = getNamedListStyle();
if (val instanceof SimpleOrderedMap) {
writeNamedListAsMapWithDups(name, val);
} else if (namedListStyle == JSON_NL_FLAT) {
writeNamedListAsFlat(name, val);
} else if (namedListStyle == JSON_NL_MAP) {
writeNamedListAsMapWithDups(name, val);
} else if (namedListStyle == JSON_NL_ARROFARR) {
writeNamedListAsArrArr(name, val);
} else if (namedListStyle == JSON_NL_ARROFMAP) {
writeNamedListAsArrMap(name, val);
} else if (namedListStyle == JSON_NL_ARROFNTV) {
throw new UnsupportedOperationException(namedListStyle
+ " namedListStyle must only be used with
ArrayOfNameTypeValueJSONWriter");
}
}
{code}
So , again, what's the feature that we want to preserve here? If we
replace{{SimpleOrderedMap}} with a {{LinkedHashMap}} , we get exactly the
same behavior as we get today.
> 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
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[
https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675999#comment-16675999
]
Gus Heck commented on SOLR-12959:
-
This is interesting and enlightening :) Some thoughts:
1) I don't get the phrase "order is _secondary_ in importance." When I read
that in the javadoc I'm not sure (based on that phrase) if order is required or
if it can be sacrificed in some refactoring later. Looking around will answer
the question, but the phrase muddies the water that would otherwise be clear
(imho). Either order is required or it's not...
2) It sounds like the subclass is a solely rendering hint and intended to be
otherwise identical. I think if we leave things as is, the javadoc should say
THAT explicitly (assuming I got it right).
3) It sounds like this *could* be a boolean flag on NamedList instead of a
subclass? or if we want to leave open other implementations an enum? Maybe
NamedList.Render with values ARRAY_1D and ARRAY_TUPLES (and perhaps some point
ARRAY_2D or something else...) I'd also advocate staying away from the word
"map" since the allowance of duplicate keys is extremely surprising for
anything called a map
{code:java}
"features":[
"adapter",2,
"car",2,
"power",2,
"white",2]
{code}
{code:java}
"features":
[
{"adapter":2},
{"car":2},
{"power":2},
{"white":2}]
{code}
I seearched for cases where we check "instanceof SimpleOrderedMap" and they all
occur where we know we have a NamedList, so a boolean or enum attribute should
work.
4) Finally, a question: besides representing parameters from the GET request
line, when do we handle/expect/use duplicate keys? Examples are not popping to
mind...
> 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
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[ https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675885#comment-16675885 ] Noble Paul commented on SOLR-12959: --- The order is never changed. It's always in the same order as NamedList. When you read it at the other end, if you use any of the ordered maps it's good enough > 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
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[
https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675876#comment-16675876
]
Hoss Man commented on SOLR-12959:
-
{quote}How many people use the other formats of JSON representation other than
the simple object representation?
{quote}
anybody who cares about the order of facet counts is going to care if you force
simple maps
> 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
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[
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'
2
2
{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
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[ https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675872#comment-16675872 ] Noble Paul commented on SOLR-12959: --- Let's get this clear , Only JSON makes a distinction between these two. Javabin writes the response in exactly the same format irrespective of the output. How many people use the other formats of JSON representation other than the simple object representation? I would say we should even get rid of these complex representations of JSON > 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
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[ https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675863#comment-16675863 ] David Smiley commented on SOLR-12959: - Neither echoParams (a SolrParams) nor the stored fields (a SolrDocument) are held as NamedLists and thus don't apply in your example. Nonetheless I get your drift. 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? Keys cannot repeat in a LinkedHashMap but the demands of the two seem to me to compete with each other: ease of access by key & repeated keys are kinda incompatible – better off using a list of values. I should spot-check some SimpleOrderedMap usages in Solr to see how easily they might be redone as LinkedHashMap. As an aside, we're missing a "maparr" json.nl value that could represent values inside arrays. But I suppose that could not be done in a streaming manner. > 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
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[
https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675815#comment-16675815
]
Hoss Man commented on SOLR-12959:
-
{quote}I imagine the reach will be broad – yet I hope no big deal
(inconsequential). Users at least have "json.nl" at their disposal.
{quote}
Again {{json.nl}} is only useful *because* we have both of these impls ... to
eliminate one impl and say "use json.nl to control the output" would make our
result structures either 2x complex to consume *OR* (in the flip chose) useless
for preserving order in most JSON client libraries.
> 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
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[
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 JIR
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[ https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675770#comment-16675770 ] David Smiley commented on SOLR-12959: - bq. Right, but there's also the default behavior that would be different with this change. Sure; 8.0 is fine. I think the first step is only to make the output agnostic of the NamedList subclass impl and then see what tests break and then better understand the scope of the change (reporting back here first for consideration before proceeding with removal). SimpleOrderedMap is used all over the place so I imagine the reach will be broad -- yet I hope no big deal (inconsequential). Users at least have "json.nl" at their disposal. > 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
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[ https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675739#comment-16675739 ] Andrzej Bialecki commented on SOLR-12959: -- bq. The json.nl influences how named lists are output Right, but there's also the default behavior that would be different with this change. bq. I've always wondered why they didn't just implement Map AFAIK originally they were meant as a memory optimization as compared to Java collections, and strictly speaking they should implement a MultiMap but that was rejected because it's not a core Java API. Duplicate keys are allowed in order to represent more conveniently multi-valued mappings, without actually introducing a proper MultiMap and without requiring users to deal with value arrays (or lists) > 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
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[ https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675672#comment-16675672 ] Gus Heck commented on SOLR-12959: - I've always wondered... are these two classes used merely for historical reasons, perhaps because LinkedHashMap maybe wasn't appreciated/known at the very start of things? Or is it that we replaced the collections classes to get big performance gains from these custom structures and serializations? I've always wondered why they didn't just implement Map, and why duplicate keys would be allowed (apparently according to the javadocs)... > 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
[jira] [Commented] (SOLR-12959) Deprecate solrj SimpleOrderedMap
[
https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675653#comment-16675653
]
David Smiley commented on SOLR-12959:
-
I mistook the class level javadocs to be obsolete, and I've not understood it
well (embarrassing perhaps). Even if it's docs are correct, I still find the
class odd. One thing -- I thought "json.nl" is what toggles these two
representations:
{noformat}
{"foo":10,"bar":20}
vs
["foo",10,"bar",20]
{noformat}
Yet the docs seem to suggest it's SimpleOrderedMap vs (plain) NamedList that
will as well? IMO: Yuck. that latter format is unfortunate as it doesn't
semantically represent the structure; it should merely be an _option_ that the
user can toggle with json.nl if they so choose. Perhaps we should shy away
from even having repeated keys in the first place, favoring array values
instead.
Second is the name... as a subclass of NamedList I think it could certainly be
better. "Simple"ness isn't interesting (is there a complex variant?).
OrderedMap... maybe not a great name given "Map" has loaded assumptions in the
JDK (i.e. no repeated key). If we need a subclass of NamedList then it
probably ought to have "NamedList" as part of its name.
I think we can _do something_ to improve things here. Feel free to recommend
something Hoss or AB.
> 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
