couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
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. <geir@pobox.com>  
> 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

>
>
>>
>> geir
>>
>>
>
> HTH,
> Paul Davis
>
> [1] http://www.ietf.org/rfc/rfc4627.txt?number=4627


Mime
View raw message