Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of yseeley@gmail.com designates
 209.85.219.48 as permitted sender)
MIME-Version: 1.0
Sender: yseeley@gmail.com
In-Reply-To: <1352878868.3213.113.camel@te-prime>
References: 
 <CAOdYfZVGuRV5ZKdqQyk-AWESqXut5G+KdaV-gRwMyd8FhcMj7g@mail.gmail.com>
	<CAB_8Yd-vdMxZecGXH54j1az16UtnHTg-sDVUU8ojN2Xtr8f0ww@mail.gmail.com>
	<CAF=Pa5_ODjv7mTsagJ392aJazFBEzFzMqX6vhHR4zUwXgfAr5w@mail.gmail.com>
	<CAB_8Yd82vkT7Jf3PUm_9AXhF+jBi5fiYr2yfVn5htPmT5c79fA@mail.gmail.com>
	<1352878868.3213.113.camel@te-prime>
Date: Fri, 16 Nov 2012 16:48:08 +0100
Message-ID: 
 <CAB_8Yd9TyvNMO6Wu1m52TLOe4Hq+WN9nzPe5hDmx87V05WMrQw@mail.gmail.com>
Subject: Re: Optimize facets when actually single valued?
From: Yonik Seeley <yonik@lucidworks.com>
To: dev@lucene.apache.org, te@statsbiblioteket.dk
Content-Type: text/plain; charset=ISO-8859-1

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