Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of dch@jsonified.com designates
 209.85.215.181 as permitted sender)
Date: Thu, 20 Feb 2014 10:37:01 +0100
From: Dave Cottlehuber <dch@jsonified.com>
To: user@couchdb.apache.org, CouchDB Developers
 <dev@couchdb.apache.org>
Message-ID: <etPan.5305ccbd.6b8b4567.7327@akai.jsonified.com>
In-Reply-To: <DUB406-EAS316DF75D3F8B4825BEAE1C2CA9A0@phx.gbl>
References: <DUB406-EAS316DF75D3F8B4825BEAE1C2CA9A0@phx.gbl>
Subject: Re: Duplicate fields in documents
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

> > On =46eb 19, 2014, at 6:07 AM, Dave Cottlehuber wrote:
> >
> > > TL;DR the appropriately named ECMA 404 JSON spec =5B1=5D is broken =
or more
> > politely, insufficiently specific.
> >
> On Wed, =46eb 19, 2014 at 8:30 PM, Jens Alfke wrote:
> >
> > This seems to fall into the category of =22things so obvious that the=
 people
> > who wrote the spec didn't realize they had to mention them.=22 I.e. =22=
You
> > can't have duplicate keys.=E2=80=9D

When I was in =46rance, I learned that anything not explicitly forbidden =
is
therefore permitted. And while in Germany, I learned that anything not
explicitly permitted is forbidden :-). Luckily in New Zealand, it only ma=
tters
if you get caught ;-).

On 20. =46ebruar 2014 at 06:14:29, Mikael S=C3=B6derstr=C3=B6m (vimpyboy=40=
msn.com) wrote:
>
> If there are duplicate keys, it should absolutely fail.

I think returning an error on receiving duplicate keys would be a sensibl=
e
change to CouchDB, albeit a relatively minor breaking one. See below.

> > > JSON is typically based on a dictionary or hash map, and there's no=

> > particular reason for that data structure to enforce uniqueness of ke=
ys.
> >
> > I disagree. Mathematically, a dictionary/map object is a function: it=
 maps
> > from a set of keys to a set of values, with each key mapping to exact=
ly one
> > value. (That's basically the definition of 'function'.) It's certainl=
y
> > possible to create implementations that map a key to =5Fmultiple=5F v=
alues, but
> > that's something different: it's a mapping from a key to a set. (=46o=
r
> > example, it's not from string-->int, it's now from string-->set.) The=

> > JSON spec does not include this kind of mapping -- an object value in=
 JSON
> > can be a number, but not a set of numbers.

I was referring to the fact that hash tables usually have some form of co=
llision
detection internally, when multiple keys map to the same hash bucket. The=
re are
perfect hash functions & algorithms that avoid collisions, but that=E2=80=
=99s getting
a bit off track. And it=E2=80=99s moot point, as we all agree that duplic=
ate keys are not
what=C2=A0most people expect, including Crockford.

> > IMHO the reasonable thing for a JSON parser to do if it encounters a
> > duplicate key is to fail with a clear error. =46ailing that, the only=
 other
> > reasonable option is to discard one or the other value (I don't have =
an
> > opinion which.) But keeping both is unreasonable.

If somebody wants to sort this out, I=E2=80=99d suggest implementing the =
fix (in C) in
Paul Davis=E2=80=99 jiffy library, which has been on the list of things t=
o import
for a while.

I added https://github.com/davisp/jiffy/issues/54 and updated
https://issues.apache.org/jira/browse/COUCHDB-1294

jiffy:decode(<< =22=7B=5C=22foo=5C=22:=5C=22bar=5C=22, =5C=22foo=5C=22:=5C=
=22bar=5C=22=7D=22 >>) should return an error,
something like invalid=5Fjson=5Fduplicate=5Fname=5Fin=5Fobject.

CC=E2=80=99d dev=40.

A+
--=C2=A0
Dave Cottlehuber
Sent from my PDP11