[
https://issues.apache.org/jira/browse/SOLR-9442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15684162#comment-15684162
]
Hoss Man commented on SOLR-9442:
--------------------------------
ok, well ... my main point is pretty clearly illustrated by what you said
here...
{quote}
Both "arrnvp" result
...
and "arrntv" result
...
contain information equivalent to
{noformat}
<lst name="someField">
<int name=“foo”>42</int>
</lst>
{noformat}
xml format.
In the "know beforehand what to expect" use case, let's say the expectation is
"int" type and hence the client does
{code}
myName = asString(someField, "name")
myInt = asInt(someField, "int")
{code}
for the "arrnvp" format.
For the "arrntv" format
{code}
# option 1
myName = asString(someField, "name")
myInt = asInt(someField, "value")
{code}
{quote}
...if you are 100% confident in what the datatypes are, then both formats are
equally useful to you -- the amount of code you have to write is exactly the
same. but the arrntv alternative i suggested is also useful even if you don't
know the types -- to me arntv is strictly an improvement.
If you want to split arrntv out in SOLR-9787 that's fine, but i still
ultimately question the value of this arrnvp for end users if we _also_ have
arrntv? -- if SOLR-9787 gets committed to branch_6x before arrnvp is ever
included in an official release, what's the point of leaving arrnvp in Solr?
why not remove it as part of SOLR-9787?
----
As for the null handling, your explanation of how arrnvp currently works when
the value is null demonstrats what seems like a big gotcha in the current code
-- namely that if the the client is expecting an {{String}} but the actual
value is {{null}} (something that seems plausable and should be accounted for
in the list of semi-typical cases), then a lookup for the key {{"str"}} in the
JSONObject (ie: {{myValue = asString(someField, "str")}} in your psuedocode) is
going to "fail", because there won't be a key named {{"str"}} instead there is
a key named {{"null"}} ... maybe for some clients that "failure" will be fine,
because the failed lookup will result in returning {{null}} in the client
language, which might be what the client expects, but in other cases/languages
it might throw an exception of cause other problems.
with the arrntv variant, even if you ignore the type, the {{"value"}} key would
still returning {{null}} and the client shouldn't suffer any sort of
catastrophic/unexpected error.
...which again leaves me questioning: isn't the discussed arrntv idea strictly
better then the rrnvp format currently committed? if SOLR-9787 gets committed
to branch_6x before arrnvp is ever included in an official release, what's the
point of leaving arrnvp in Solr? why not remove it as part of SOLR-9787?
> Add json.nl=arrnvp (array of NamedValuePair) style in JSONResponseWriter
> ------------------------------------------------------------------------
>
> Key: SOLR-9442
> URL: https://issues.apache.org/jira/browse/SOLR-9442
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Response Writers
> Reporter: Jonny Marks
> Assignee: Christine Poerschke
> Priority: Minor
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9442-arrntv.patch, SOLR-9442.patch,
> SOLR-9442.patch, SOLR-9442.patch
>
>
> The JSONResponseWriter class currently supports several styles of NamedList
> output format, documented on the wiki at http://wiki.apache.org/solr/SolJSON
> and in the code at
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/response/JSONResponseWriter.java#L71-L76.
> For example the 'arrmap' style:
> {code}NamedList("a"=1,"b"=2,null=3) => [{"a":1},{"b":2},3]
> NamedList("a"=1,"bar”=“foo",null=3.4f) => [{"a":1},{"bar”:”foo"},{3.4}]{code}
> This patch creates a new style ‘arrnvp’ which is an array of named value
> pairs. For example:
> {code}NamedList("a"=1,"b"=2,null=3) =>
> [{"name":"a","int":1},{"name":"b","int":2},{"int":3}]
> NamedList("a"=1,"bar”=“foo",null=3.4f) =>
> [{"name":"a","int":1},{"name":"b","str":"foo"},{"float":3.4}]{code}
> This style maintains the type information of the values, similar to the xml
> format:
> {code:xml}<lst name=“someField”>
> <int name=“a”>1</int>
> <str name=“bar”>foo</str>
> <float>3.4</float>
> </lst>{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
