Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 54973 invoked from network); 28 Dec 2008 13:12:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 28 Dec 2008 13:12:52 -0000 Received: (qmail 72268 invoked by uid 500); 28 Dec 2008 13:12:46 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 72222 invoked by uid 500); 28 Dec 2008 13:12:45 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 72210 invoked by uid 99); 28 Dec 2008 13:12:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Dec 2008 05:12:45 -0800 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 216.86.168.178 is neither permitted nor denied by domain of geir@pobox.com) Received: from [216.86.168.178] (HELO mxout-03.mxes.net) (216.86.168.178) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Dec 2008 13:12:34 +0000 Received: from [10.0.1.194] (unknown [67.86.14.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7157223E3F1 for ; Sun, 28 Dec 2008 08:12:11 -0500 (EST) Message-Id: <98979283-BB61-4D15-AF05-196979FA42BC@pobox.com> From: "Geir Magnusson Jr." To: user@couchdb.apache.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: newbie question #1 Date: Sun, 28 Dec 2008 08:12:10 -0500 X-Mailer: Apple Mail (2.929.2) X-Virus-Checked: Checked by ClamAV on apache.org I work for a company (10gen) that's making what I refer to as a "document oriented" database (called MongoDB*), and I've long been meaning to grok CouchDB. Now that I have some time during the year- end hibernation, I figured this is a good time to dig in. So I have some basic questions. Warning - these are really basic, and could be caused entirely by my current lack of caffination. I assume the best place to find docs is the wiki. If there's something better, any pointers welcome. First newbie question : Looking at http://wiki.apache.org/couchdb/HTTP_Document_API, I understand that _id and _rev are reserved fields in the document**. Now, looking at the _all_docs example, I see I get back a list of docs : { "total_rows": 3, "offset": 0, "rows": [ {"id": "doc1", "key": "doc1", "value": {"rev": "4324BB"}}, {"id": "doc2", "key": "doc2", "value": {"rev":"2441HF"}}, {"id": "doc3", "key": "doc3", "value": {"rev":"74EC24"}} ] } what is "id"? is that supposed to be "_id"? what is "key"? I see that in futon as well - how does it relate to "_id" or "id" for that matter? Also, I assume that "rev" is the "_rev" of the document. Why not make it "_rev"? I'm guessing that "id" is "_id", as I can see similar things in the PUT example, but I guess then the question changes to why not just be consistent and use "_id" everywhere, especially since I'm allowed to use "id" in my document? I'm sorry if this is a stupid question - I just don't understand. I'm happy to update the wiki when I understand :) geir I put these notes at the bottom as they are asides... * MongoDB - I'm getting a "community" site going (http:// www.mongodb.org) indep of our corp site (http://www.10gen.com/). It's open source, written in C, and has some very nice features. ** 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 that a better way to do this is provide a JSON-based "envelope" for documents in which the database reserves all fields, and the user document is "hung" in there on one of them. This allows adding metadata over time free of collision with the user documents : { _id : whatever _rev : whatever doc : { ..... the full user document that can have _id, _rev and whatever....} }