I know I can do that. And if CouchDB is the only "JSON source" that
my apps are talking to, then that's fine - all apps can be written to
expect that "schema".
But I'm taking a different POV - where a "schema" exists outside of my
app (a pseudo-standard defined by someone else) and I want to use
CouchDB as a source of documents that conform to that schema. My apps
should be able to consume documents in that "JSON schema" that are
sourced from CouchDB, a httpd server returning static documents, some
servlet app running in Tomcat, some .NET thingy, etc.
Once you force me to store documents in a new format in order to
protect data in my document that clashes w/ the server's metadata by
sticking the document of interest in a top-level field :
{
_rev : ...
_id : ...
mydata : { ... the real document ... }
}
then I think that CDB loses something in terms of being a general JSON
document store.
Now, I realize that no one ever said that CDB is a general JSON
document store, rather it's a datastore that happens to return data in
JSON. The different is subtle, but very important. It will be
interesting to see how this space ("document databases") plays out,
and if my concerns are valid. Time will tell, I guess.
BTW, for maximum utility, I think that the view API will have to
change as well. There's incredible power in the CDB view model, but
you'll want to be able to return a pure "user document" from a call to
a view (conform to some specific "schema"), rather than at least what
I understand is the current metadata-oriented structure.
geir
On Jan 1, 2009, at 7:53 PM, Damien Katz wrote:
Why can't you just always stick the desired document into an body
field on the document? If you always do that, then you can round
trip without problem.
-Damien
On Jan 1, 2009, at 7:17 PM, Geir Magnusson Jr. wrote:
On Jan 1, 2009, at 7:14 PM, Adam Kocoloski wrote:
On Jan 1, 2009, at 4:45 PM, Geir Magnusson Jr. wrote:
b) I should have the choice to not have it injected at all
So why do I think this is a problem? The 10gen appserver auto-
injects an id field into the JSON documents that are stored in
our database, Mongo. Can you guess what the key is? Yep - "_id"
So how can I roundtrip a doc from 10gen through couch and back?
I can't.
Perhaps its worth noting that CouchDB is perfectly comfortable
with externally generated _ids. It only injects an _id if you
create a new document without one. Best,
I understand that.
I was just pointing out a real-world case where a JSON doc from
"somewhere else" runs into trouble... (and yes, the issue applies
equally to the 10gen platform, when coming from "somewhere else" :)
geir
