From dev-return-6878-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Thu Oct 15 15:25:37 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 39872 invoked from network); 15 Oct 2009 15:25:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 15 Oct 2009 15:25:37 -0000 Received: (qmail 98619 invoked by uid 500); 15 Oct 2009 15:25:36 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 98537 invoked by uid 500); 15 Oct 2009 15:25:36 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 98527 invoked by uid 99); 15 Oct 2009 15:25:36 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Oct 2009 15:25:36 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.210.176 as permitted sender) Received: from [209.85.210.176] (HELO mail-yx0-f176.google.com) (209.85.210.176) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Oct 2009 15:25:34 +0000 Received: by yxe6 with SMTP id 6so898930yxe.13 for ; Thu, 15 Oct 2009 08:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=2qIPHXJt7Ffsm4MEfvUVBTB+DrvZZ4eb7v2tF4sL7h8=; b=QIebJwz+yGAkK5wddAgYJ3uuPxGYKL44Ge5di/IrpPoCzIKwNM1HqfFJl6k+WbzILP Bx5zezTX+HlQubwxwB65pbAeGvphN1iTSK5bWcSe6nx8zmnADriZWGsxvg3MNReXbTbJ dOZzfz3eHiqJBD8GO6ppYr89UtnvLA37CV2C0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=MxUgtA+fVNME/AzlusdssLld1msrgbMzPgfowmyts/Xkg//jfci1mLcXquVcWQc/bX xg5waBuB10vT/39LUS/XXQnRBUC8ATaPqizjQVuyzqkqVyoyq13PIwsJ+TR42g622HJm 0tAqe1hJt18cTljB6CwjFfTAjsoyvy9wJOljg= MIME-Version: 1.0 Received: by 10.101.53.11 with SMTP id f11mr225811ank.158.1255620004931; Thu, 15 Oct 2009 08:20:04 -0700 (PDT) In-Reply-To: <1A9EA2D5-C2FA-4D56-8F81-D2077709B5C2@apache.org> References: <214c385b0910150728m10dd313fg1f02e517587a102f@mail.gmail.com> <1A9EA2D5-C2FA-4D56-8F81-D2077709B5C2@apache.org> Date: Thu, 15 Oct 2009 11:20:04 -0400 Message-ID: Subject: Re: Avoiding updating a doc's _rev if nothing changed From: Paul Davis To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you don't include the previous document's revision, then your hashes are unidirected and don't form a Merkle tree. This makes things like conflict resolution a tad more crazy. For instance, say you have two edits, A -> B -> A. That loop makes things harder. HTH, Paul Davis On Thu, Oct 15, 2009 at 11:05 AM, Adam Kocoloski wrot= e: > On Oct 15, 2009, at 10:28 AM, Matt Goodall wrote: > >> Hi, >> >> I think this is more of a dev question given that it needs some >> knowledge of the deterministic rev algorithm ... >> >> I was just wondering if CouchDB could use the deterministic rev stuff >> to avoid writing changes to the database if nothing has actually >> changed in the doc that is PUT back (or bulk updated, of course). >> >> The most obvious use case is that it's horrifyingly common for users >> to click an HTML form's submit button, instead of using the back >> button, when they haven't changed anything. I suspect most >> applications do not check if the user made any changes and therefore >> end up sending exactly the same data back as an update ... >> unnecessarily creating a new document rev, growing the database, >> invalidating views, and triggering _changes updates. >> >> CouchDB obviously has to calculate the hash for the new rev anyway, so >> perhaps it could compare the new value to the current value, skip it >> if it's unchanged and return the current _rev in the response. >> >> Is that feasible? If so, I'll create a ticket for it. >> >> - Matt > > Hi Matt, it would easily be possible except for the fact that the old > revision of the document is part of the content used to generate the hash > that becomes the new revision. =A0So even if the body didn't change, the = hash > won't match the old rev. > > I think it would be a nice improvement, and I honestly don't remember off > the top of my head the argument _why_ the old revision had to be included= . > =A0So yeah, a JIRA ticket seems like a good idea. =A0Best, > > Adam >