On 08/02/2009, at 3:52 PM, Damien Katz wrote:
No, CouchDB replication doesn't support replicating the
transactions. Never has, never will. That's more like transaction
log replication that's in traditonal dbs, a different beast.
So just to be clear, replication ignores MVCC? And there is therefore
no way to achieve any form of consistency, even the weaker ACID you've
proposed - which sounds like it's really only Durability. I presume it
at least replicates according to update_seq? If so, would it be
difficult to ensure that the update_seq that the replicator sees is
always on an MVCC boundary? That would allow for transactional
replication of the form I'm talking about.
For the new bulk transaction model, I'm only proposing supporting
eventual consistency. All changes are safe to disk, but the db may
not be in a consistent state right away.
Or indeed, ever.
Not necessarily, and even if they did, it's likely that they'll
have multiple browser windows open.
What's the front end written in?
On OSX, an Objective-C app that provides an embedded Safari connecting
to an embedded Ruby/Merb admin server, although I'm thinking of
changing to Yaws et al. That provides a traditional OS app, with a GUI
that looks like iTunes, provided via HTML. The admin app can then
replicate/download web applications written in e.g. Ruby (for now)
which do the real work.
On Windows, something similar, I presume .NET/C++/Gecko. Discussed in
the contract RFI I posted.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Human beings, who are almost unique in having the ability to learn
from the experience of others, are also remarkable for their apparent
disinclination to do so.
-- Douglas Adams
