couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
Subject Re: Update notifications including update sequence
Date Mon, 19 Jan 2009 06:35:54 GMT

On 19/01/2009, at 3:51 PM, Paul Davis wrote:

> There can be many _external processes for a single definition. So, not
> only are requests not serialized, they can be concurrent etc.

OK. I'll be patching my deployment to ensure a single external process  
per external definition.

IMO the _external system is considerable less useful in this form,  
especially for external indexing. Concurrency and consistency should  
be a matter for the external system to control, because it's the  
external system that understands/imposes/relaxes the concurrency and  
serialization requirements.

Maybe an external that acts more like a real server, even if the  
single command channel needs a request multiplexing protocol.


> A single _external process should only see monotonically increasing
> update_seq's. I think it's techincally possible to have a smaller
> update_seq processed later in time in a different os process though
> (later in time <= few ms).

Possible => broken.

> The ideas from the other thread about having a UUID per db and
> compaction are interesting, are either of those included the fs layout
> stuff you were working on?

No. UUIDs are useful for the fs because you need a strictly functional  
mapping from name -> file, and using a UUID is begging the question.

The compaction issue isn't real. My first thought is that the purge  
issue could be dealt with by a) having a notification of the purge and  
b) having the purge_seq be set to the update_seq of the snapshot seen  
by the purge. Maybe it works that way already.

I definitely prefer state transitions to be reified rather than  
notified, and IMO it's more consistent with the overall couch model.

Personally I think an _external system with a few richer protocol is  
required, rolling in notifications with the requests, so that an  
external system can maintain accurate state-correspondence with the  
canonical couch data, without exceptions e.g. without needing some  
sideband for database life-cycle events. Also being able to make  
queries to a given snapshot, using either the request channel or an  
additional parameter via HTTP. The request channel is by far a better  
idea because the snapshot can be implicitly scoped by the request.

I am adding the db UUID, view function UUID and revs in view results  
for my own purposes, but there wasn't much interest on the list, and I  
haven't the time to convince/shepherd/clean/publish etc that proposal  
or implementation.

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

I contend that we are both atheists. I just believe in one fewer god  
than you do. When you understand why you dismiss all the other  
possible gods, you will understand why I dismiss yours.
   --Stephen F Roberts



Mime
View raw message