couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
Subject Re: Trouble with replication
Date Fri, 30 Jan 2009 08:35:31 GMT

On 30/01/2009, at 6:30 PM, Chris Anderson wrote:

> 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.

No fault with design docs being normal docs, and in fact I can't see  
how making it otherwise could solve this problem.

> 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
> useful.
>
> 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.

That's assuming that there is such a thing as a roll-out. If your code  
is replicated with your data, which it must be with design doc  
functions because they are applicable to the db in which they reside,  
then I can't seen an effective way to use those features with mesh  
deployments.

An alternative might be to regard these non-functional features as  
being a layer above the canonical store maintained by replication,  
something like a view. So replication would never block, and the  
underlying model would always guarantee that a global steady state is  
reachable regardless of ordering.

And thinking of your 'newly-invalid' docs view, that feels like the  
same kind of thing I'm suggesting.

I haven't thought more than that about what a solution would look  
like, and I'm not sure at this point if partial replication is an  
identical problem or not. My gut feel is that intermingling the  
CouchDB-as-application features with CouchDB-as-replicated-document- 
store functionality is problematic and requires enormous care, and a  
more layered and partitioned approach might be prudent.

Regardless of the issue for meshes, it seems that using validation, or  
any other non-functional feature that impacts the canonical data, as  
opposed to derived data such as views, opens a real can of worms for  
developers. Given your IRC comment about unfortunate memes being  
generated by naive developers (c.f. single-node transactions), it  
seems to me that if the underlying model presented by CouchDB becomes  
more difficult to use or requires a more subtle understanding of the  
very very hairy problem of distribution/global state etc, then the  
meme will be 'CouchDB is impossible to get right'.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The trouble with the world is that the stupid are cocksure and the  
intelligent are full of doubt.
   -- Bertrand Russell



Mime
View raw message