On Wed, Nov 14, 2012 at 8:41 AM, Toke Eskildsen <t...@statsbiblioteket.dk>
wrote:
> Dynamically changing response formats sounds horrible.
It depends if you consider it a change of format. A single value
would always be presented as a single value, while multiple values
would always be represented as an array. It's on a per-document
basis, and is not determined by whether the field as a whole is
"multiValued".
To users of JSON, I think it's pretty natural:
[
{ "id":"doc1", "author" : "David" },
{ "id":"doc2", "author" : ["Mike","Erik"] }
]
One could think of it in reverse too (that the current way of doing
things is actually more prone to changing formats just because you
changed a type).
Say you indexed an author field as multiValued=false, but then
realized you needed to sometimes add multiple values... now everything
that had been coming back as "author":"David" starts coming back as
"author":["David"]
Ryan wrote:
> If the only motivation for adding 'multiValued=flexible' is the response
> format, what about just changing the response format version number
That's a good point. It doesn't seem particularly valuable to
enable/disable this on a per-field basis, and one could see wanting to
concurrently support different clients that want their results
different ways. That really argues for a request parameter (or
version) to control how multiValued fields are handled.
-Yonik
http://lucidworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
