On Thu, Mar 12, 2009 at 6:38 PM, Antony Blakey wrote:

On 13/03/2009, at 1:46 AM, Damien Katz wrote:

Atomic bulk docs is in the patch, it just doesn't do conflict checking. If
any docs are conflicts, they are saved anyway as conflicts. This means it's
really for message queue functionality, not database consistency, your data
is safe and committed but might not be immediately available or consistent
between docs. The reasons we are removing all or nothing with conflict
checking as it doesn't work with replication (both offline and clustering)
as docs are not replicated in a single transaction or even in update order.
And getting it to work with partitioning would cause unacceptable write
performances. If we leave it, people will rely on the behavior not
understanding it doesn't really work with the rest of CouchDB.

So if you are currently using bulk docs to guarantee inter-document
consistency, it already doesn't work with replication. It only works on a
single machine, so no master-slave and no hot stand-by setup would work as
neither are guaranteed to be in a consistent state at any point.
The current bulk docs IS useful in a particular scenario.

It allows me, on a single node, to do transactional updates in response to
e.g. a web submit/AJAX call, without having to expose the conflict model to
the user and deal with conflicts in my single-node code.

I then have two distinct phases of operation for peers:

1. Replication is triggered by the user and they do nothing else until
replication commpletes, after which they have to resolve the conflicts
generated by replication. This code deals with conflicts and a resolution UI
and nothing else.

2. Normal operation - concurrent access by multiple applications, multiple
users. The code never sees a conflict, and hence the user interaction and
programming model is considerable simpler

There are a few additional features useful in this model, the principal
ones being either 1) the ability to roll back a partial replication to deal
with network failures; or b) the ability to maintain monotonic source writes
which ensures that each replication step is consistent. To date neither of
these features have gained sufficient community support to be considered.

I've presented this model before, and it has been rejected as being
incompatible with the initial couchdb intentions, but in response to Tim
Parkin, this is the reason for my fork. There are more details to my effort
- pure binary bodies rather than JSON, unification of attachments with
documents, strict metadata/content separation, map/reduce over arbitrary
data, generalised derivation, an immutable model of fully reified state,
replication of operations rather than data - but maybe anyone interested can
contact me offlist - it's no longer CouchDB and I'm sure everyone's sick of
saying/reading "forget it, it's not going to happen" :)

Will this code still be Apache? Meaning, will some of this features be able
to meander their way back into couch? I can totally understand the need for
a fork (differing goals sometimes cannot be reconciled), but if it's a
friendly fork, so to speak, everybody benefits -- especially if some of
these features get rolled back in to make it easier for you to keep up with
trunk otherwise.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 29 | next ›
Discussion Overview
groupdev @
postedMar 12, '09 at 12:17p
activeMar 16, '09 at 8:09p



site design / logo © 2018 Grokbase