couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Trouble with replication
Date Fri, 30 Jan 2009 08:00:26 GMT
On Thu, Jan 29, 2009 at 10:56 PM, Antony Blakey <> wrote:
> Extending this to update functions means that conflict resolution is no
> longer globally deterministic, because it depends on the propagation pattern
> of the update function. Same with validation and authentication.
> This will only affect some use cases, but it's a very difficult problem in
> meshes.

Ahh, I didn't consider the validation function as being replicated as
well. I suppose I'm imagining that validation functions will define
the borders of applications, and thinking of these data flows as
within a particular application.

This is a straightforward consequence of the fact that design docs are
documents just like any other, which of course has so many good
effects that it's hard to find fault with the system because of edge
cases like this.

Another edge case from validation functions (which can happen even on
a single node) is that documents which have been added to a db, can be
invalidated by the addition of a validation function after they have
been saved. Having a view of all newly-invalid docs will definitely be

It seems like if you want to ensure that your system follows some of
the stricter principles you outlined, you'll have to avoid use of
(changing) validation functions in your applications. Or at least be
very thoughtful about code roll-outs.

This may be a logical fallacy, but finding an "inconsistency" like
this, encourages me that we maybe dealing with a "complete" system.
I'd rather have something powerful enough to generate inconsistencies
than something so meager that it can't.

Chris Anderson

View raw message