On Jan 1, 2009, at 9:14 PM, Flinn Mueller wrote:
On Jan 1, 2009, at 8:24 PM, Geir Magnusson Jr. wrote:
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 :
Isn't this any issue with any data store? It's established that _id
is arbitrary just like it could be in just about any other data
store. If this is a problem in couchdb it's a problem for you in
any data store isn't it?
If the data store chooses to inject it's metadata into my document,
yes it will be, and that's my point.
{
_rev : ...
_id : ...
mydata : { ... the real document ... }
}
then I think that CDB loses something in terms of being a general
JSON document store.
You're looking at couchdb's document as if it's your JSON document.
It's couchdb's document and it happens to be JSON.
Exactly. That is what I note below - that CDB isn't a "general JSON
store", it's a store that "renders" it's data in JSON. (I hope it's
clear that I think the world needs a "general JSON store" :)
There is nothing at all wrong with the above "schema" and it's
arguably the best way to store a document that you don't want to
conflict. The couchdb document is always going to need metadata.
If it's not in _id then it's _farfagnugen and someone will
inevitably have the same issue.
Yep, exactly! That's why I suggest formally separating the metadata
out of the user data, and enhance the REST and view APIs so that you
can get
a) just the user data (e.g. my AJAX app doesn't care or worry about
the metadata)
b) both meta and user in the format like above
c) only meta for things where you don't care about the user data
d) maybe even a legacy mode where you inject meta into the userdata as
it is today
geir
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
