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 <[email protected]> wrote: > 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. > > 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. > So yeah, a JIRA ticket seems like a good idea. Best, > > Adam >
