couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Landolt <d...@deanlandolt.com>
Subject Re: Bulk Docs
Date Thu, 12 Mar 2009 23:42:08 GMT
On Thu, Mar 12, 2009 at 6:38 PM, Antony Blakey <antony.blakey@gmail.com>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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message