incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nitin Borwankar <ni...@borwankar.com>
Subject Re: invalid json allowed into couch
Date Sun, 20 Sep 2009 00:05:09 GMT
Is this "feature" guaranteed to remain going forward?
My project has a lot of data that could use the repeated fields feature
(multiple authors of a bibliographic item, multiple keywords...)
but this is like pouring concrete - we can't uproot all of the data if a
decision is made later to be strictly JS compliant.
We are currently not using this capability, but it certainly looks
attractive and am curious about its longevity.

Damien or any other committers - any comments ?

Nitin


37% of all statistics are made up on the spot
-------------------------------------------------------------------------------------
Nitin Borwankar
nborwankar@gmail.com


On Sat, Sep 19, 2009 at 4:27 PM, Paul Davis <paul.joseph.davis@gmail.com>wrote:

> Technically, this isn't invalid JSON.
>
> Depending on how you interpret the spec, it says that properties only
> "MAY" be enforced as unique. Some people read the line about "being a
> subset of JavaScript" which does enforce uniqueness to override this
> sentence.
>
> Either way, the JSON serializer that CouchDB uses doesn't enforce
> uniqueness so it'll happily accept and repeat back objects with
> repeated property names. You can check with cURL that your doc
> actually kept both of those properties.
>
> As to having a 'fix' for this, the only thing that I could forsee
> happening is enforcing the constraint and just erroring out on the
> initial PUT request. Concatenating repeated fields would be something
> that a client would need to worry about.
>
> HTH,
> Paul Davis
>
> On Sat, Sep 19, 2009 at 7:11 PM, Norman Barker <norman.barker@gmail.com>
> wrote:
> > Hi,
> >
> > currently if adding documents to couch using the REST api it is
> > possible to add a document such as
> >
> > {
> >  "prop1": "1",
> >  "prop1": "2"
> > }
> >
> > which only displays partially in Futon (skips first property, "prop1":
> > "1") due to the unique constraints of JSON object properties.
> >
> > This is actually a good feature, since I am generating invalid JSON
> > from an event based API, is there a way to add a normalisation
> > function to the write document operation  (using Erlang ideally) that
> > would group these properties,  its gets difficult when the documents
> > are nested but any thoughts appreciated.
> >
> > Many thanks,
> >
> > Norman
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message