From user-return-4083-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Mar 19 08:55:59 2009 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 96271 invoked from network); 19 Mar 2009 08:55:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 19 Mar 2009 08:55:59 -0000 Received: (qmail 72642 invoked by uid 500); 19 Mar 2009 08:55:53 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 72614 invoked by uid 500); 19 Mar 2009 08:55:53 -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 72603 invoked by uid 99); 19 Mar 2009 08:55:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Mar 2009 01:55:53 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of wout.mertens@gmail.com designates 209.85.219.166 as permitted sender) Received: from [209.85.219.166] (HELO mail-ew0-f166.google.com) (209.85.219.166) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Mar 2009 08:55:43 +0000 Received: by ewy10 with SMTP id 10so360972ewy.11 for ; Thu, 19 Mar 2009 01:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=FqjxlUkygu8L88MjTKQ7plWMbN/uob8eWmYAxj8S6nM=; b=JW7gN/35G4597o4qTGHUiifhj3y1jz39urfzsSsc4JwaGASVMBryhGhMupvX9x12oN HsIVJ5hEgOyR+3yJPyIxoqabt0EkEQ5n2w94Su2yc4YNdDqUCL8JOGoFLNZyakJiAUZn F4+bkvAvtS7xhbLlSJhfEWXy+7FEqNVdsHhVM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=tjNqxCMnjWaTU1y+wLuXRSGxDyv4QhFZK/UjRDUS4jhe1P6WkRxISUGbC/8t0Ti18i o+gglHsi1c5uDm5RNWV9Rqu/hcMY+ZvfqzEeO1oy9OzLiflzg8nS0XWc5HwM1mq7TCGA Larm5EoaUOSHmoSNxtlUx7gpolunDK6BAmpXk= Received: by 10.216.8.65 with SMTP id 43mr957373weq.168.1237452921405; Thu, 19 Mar 2009 01:55:21 -0700 (PDT) Received: from thamilto-w2k.cisco.com (56.211-200-80.adsl-dyn.isp.belgacom.be [80.200.211.56]) by mx.google.com with ESMTPS id d2sm1553482nfc.51.2009.03.19.01.55.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Mar 2009 01:55:19 -0700 (PDT) Message-Id: <9A1A2DE3-AA35-4736-96B2-0BA7D81F2E49@gmail.com> From: Wout Mertens To: user@couchdb.apache.org In-Reply-To: <41139fcb0903181753n63d6185bue49a6c9d94138174@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: behavior of document revisions Date: Thu, 19 Mar 2009 09:55:15 +0100 References: <41139fcb0903181753n63d6185bue49a6c9d94138174@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org On Mar 19, 2009, at 1:53 AM, Anand Chitipothu wrote: > I came across an earlier discussion on "behavior of document > revisions"[1], which says that: > >> A revision in CouchDB is meant to be used to test if a document has >> changed since the last time you looked (useful for async updates >> example) and not to actually look back in time at the document. > > [1]: http://osdir.com/ml/db.couchdb.devel/2008-01/msg00123.html > > Does it mean that if I want to create a wiki, I have to manage my own > document revisions? Like shown in this blog post[2]? > > [2]: http://prematureoptimization.org/blog/archives/59 Yes. Note that you have some choice about where and how to store history. You can store the full contents of old versions or just the diffs that will get those; you can store the history in the document or in separate documents. > I tried to extend the wiki idea in [2]. > Here are my views assuming that every page has path, title, body and > revision. > > { > "_id": "_design/wiki", > "language": "javascript", > "views": { > "page": { > "map": "function(doc) { emit([doc.path, doc.revision], > doc)}" > }, > "by_title": { > "map": "function(doc) { emit(doc.title, doc)}", > "reduce": "function(key, values, rereduce) { var doc = > {'revision': 0}; for (var i in values) if (values[i].revision > > doc.revision) doc = values[i]; } return doc; }" > } > } > } > > Actions: > > * get latest version of a page: > /wiki/_design/wiki/_view/page?startkey=["foo", > "Z"]&descending=true&limit=1 Shouldn't that be /wiki/_design/wiki/_view/page? endkey=["foo","Z"]&descending=true&limit=1 ? I didn't test this. BTW hopefully we'll get open-ended searches before 0.9.0 lands which would make this query prettier. > Is this is the right approach? I think so although your database will grow large when you get a lot of small changes to large pages. > I'm not quite happy with the above implementation of by_title as it is > indexing all the revisions, which is unnecessary. If it doesn't index all revisions, how does it know which is the latest one? You could make the latest version of a document be the one with the _id equal to the name. You'd have to store a copy or a diff before you store changes to it though. Using that approach you wouldn't need the by_title view. Another approach: make _id be equal to "nameversion", for example disallow the use of # in wiki names and store version 2 of a page called foo as "foo#2". Then if you simply GET /wiki/_all_docs (with view filters) you can get all revisions of a document, no views needed. You'd get the latest version with the same limit=1 approach. Wout.