On 04/12/2008, at 9:31 AM, Chris Anderson wrote:
On Wed, Dec 3, 2008 at 2:50 PM, Antony Blakey
<[EMAIL PROTECTED]> 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
