On Sun, Feb 23, 2014 at 4:45 AM, Jens Alfke <[email protected]> wrote: > What’s the exact definition of the ‘oldDoc’ parameter that’s passed to a > validation function?
So the oldDoc is "the latest available revision of the document that shares the same revision history". Probably, need to get rid any "current" and "latest" pointers to doc since they makes no sense when there are conflicted revisions. -- ,,,^..^,,, On Sun, Feb 23, 2014 at 5:01 AM, Alexander Shorin <[email protected]> wrote: > Not tested / looked in code, but I'm pretty sure that > Situation 1: null - no any stored doc on this revision branch > Situation 2: 1-xxxx since there is no 2-yyyy in database. 2-yyyy is > only known by source db, not target. > > Could be there the case when in database older revision will be > available while younger isn't for the same revision branch? > -- > ,,,^..^,,, > > > On Sun, Feb 23, 2014 at 4:45 AM, Jens Alfke <[email protected]> wrote: >> What’s the exact definition of the ‘oldDoc’ parameter that’s passed to a >> validation function? The current CouchDB docs just say it’s "the current >> document stored in the database”. This is unambiguous during a normal PUT >> operation, but I’ve just realized I’m unsure what the exact behavior is >> during replication or with new_edits=false. >> >> Situation 1: There are no revisions of document “foo” in the database. A >> replication pulls in revision 3-zzzz of “foo”, along with a revision history >> giving the ancestry as 2-yyyy and 1-xxxx. >> —> Is the validation function called with oldDoc=null, or with >> oldDoc={“_rev”:”2-yyyy”}? >> >> Situation 2: The database contains revision 1-xxxx of “foo”. A replication >> pulls in the same revision 3 as described above. >> —> Is the validation function called with oldDoc={“_rev”:”1-xxxx”}, or with >> oldDoc={“_rev”:”2-yyyy”}? >> >> This has an impact on fancy validation functions that want to check for >> invariants between a new revision and its parent. For example, in the >> document-signing spec I’m working on, a document’s signature data needs to >> include the revision ID of the parent, to avoid certain types of replay >> attacks. But if the validation function isn’t called with the exact parent >> revision, there isn’t a way for it to determine the parent rev ID to verify >> the signature. >> >> —Jens
