Re: newbie question #1

[Geir Magnusson Jr.]

On Dec 28, 2008, at 8:46 AM, Paul Davis wrote:
On Sun, Dec 28, 2008 at 8:32 AM, Geir Magnusson Jr. <g...@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