lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yonik Seeley <yo...@lucidworks.com>
Subject Re: Optimize facets when actually single valued?
Date Fri, 16 Nov 2012 15:48:08 GMT
On Wed, Nov 14, 2012 at 8:41 AM, Toke Eskildsen <te@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message