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
|