On 04/12/2008, at 9:31 AM, Chris Anderson wrote: > On Wed, Dec 3, 2008 at 2:50 PM, Antony Blakey > wrote: >> >> On 04/12/2008, at 9:07 AM, Chris Anderson wrote: >> >>> It should just be clear that timestamps are the application's >>> business, not the database's. >> >> But it's possible for Couch to be the application, especially if >> you use >> your apps-in-the-db approach. I'm not sure I see any fundamental >> difference >> between a validation function in a design document and some >> javascript in an >> attachment, of even a function inan _external handler. >> > > The problem with writing from the validation functions is that you are > supposed to be able to trust them. Eg, if you look at the function, > you can know what contract holds on the data that passes through it. A > timestamp on new docs doesn't pass this test. There's no way to know > whether the timestamp was added by a different function. With proper > pass/fail validations, you know that running the same validations at > replication time will give the same pass/fail result as at original > write time. IIUC, replication conflicts in a P2P configuration allow for a situation where even a validator that is purely funtional wrt the database state can generate different results upon replication. Or maybe I'm missing something? Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 A reasonable man adapts himself to suit his environment. An unreasonable man persists in attempting to adapt his environment to suit himself. Therefore, all progress depends on the unreasonable man. -- George Bernard Shaw