couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Goodall <>
Subject Re: Avoiding updating a doc's _rev if nothing changed
Date Thu, 15 Oct 2009 15:31:33 GMT
2009/10/15 Adam Kocoloski <>:
> 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.  So even if the body didn't change, the hash
> won't match the old rev.

Yeah, I suspected something like that was happening from the revs I
was seeing. The bit after the numerically increasing bit would have
been the same otherwise.

> 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.

I'm guessing it's something to do with tracking a document's revision ancestry.

But anyway, if the old rev is included that would mean calculating two
hashes per update ... which would likely slow real updates down.

>  So yeah, a JIRA ticket seems like a good idea.  Best,

Will do.

> Adam

View raw message