incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: newbie question #1
Date Sun, 28 Dec 2008 13:58:34 GMT

On Dec 28, 2008, at 8:46 AM, Paul Davis wrote:

> On Sun, Dec 28, 2008 at 8:32 AM, Geir Magnusson Jr. <>  
> wrote:
>> On Dec 28, 2008, at 8:19 AM, Noah Slater wrote:
>>> On Sun, Dec 28, 2008 at 08:12:10AM -0500, Geir Magnusson Jr. wrote:
>>>> I've had this debate internally at 10gen too, and I'm not  
>>>> interested in
>>>> picking a fight here :) I think that by reserving fields like  
>>>> this, you
>>>> can't
>>>> claim to be storing JSON anymore, but "JSON--" or "almost JSON".
>>> I think this is bogus. I've started calling these JSON profiles  
>>> and they
>>> are
>>> just as much JSON as an XML vocabulary is a type of XML.
>> <sigh> :)
>> I didn't want to start this argument.
>> My point is that an arbitrary, legal JSON document can have "_id"  
>> and "_rev"
>> as fields, but you couldn't store that in CouchDB (or MongoDB, for  
>> that
>> matter), since CouchDB would want to use those reserved field names  
>> for
>> itself.
> To say that reserving underscore prefixed fields for CouchDB use is a
> violation of rfc4627 [1] is provably false.

That's not what I said.  The documents that CouchDB produces for  
storage are legal JSON.

What I said was that you couldn't store an arbitrary, legal JSON  
document from a user with fidelity in CouchDB.

The following two documents are legal JSON documents, but CouchDB  
can't store them (if I grok CouchDB right) :

   "_id" : "geir's document",
   "foo" : "bar"

   "_id" : "geir's document",
   "foo" : "woogie"

> To question the merit of
> having a system that has the possibility for collisions between a
> document's fields and reserved fields is an implementation decision.
> Its good to question design decisions if you feel so inclined though.
> :D Being realistic, there's probably not a chance that this decision
> will be overturned.

I realize that :)  I was just trying to figure out the tradeoffs that  
went into the decision.

>> Maybe an example in XML-land might illustrate better - I think it  
>> would be
>> the same if an XML data store restricted the entities that you  
>> could put in
>> your schema...
>> Or maybe I can express it as a preference - I'd like a system that  
>> could
>> store any arbitrary JSON document.
>> That's all.
> The awesome thing about the schemaless design is that there is no
> schema. Or spoon. You're completely free to store all of your docs in
> a {"_id": "foo", "_rev": "0123492394", "doc": ...actual doc...} just
> like you suggested. Nothing breaks by doing that.

I completely understand.  And that's exactly what I just suggested a  
JSON store should do - hang the user document on a field in an  
"envelope" so that there can be no collision between the user's fields  
and the fields the database needs.

I do hope you also note the irony that CouchDB's storage isn't schema  
free :)

(And neither is Mongo's - don't take any of this as a criticism.....)


>> geir
> HTH,
> Paul Davis
> [1]

View raw message