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
