couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Parkin <i...@timparkin.co.uk>
Subject Re: Bulk Docs
Date Thu, 12 Mar 2009 22:09:51 GMT
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.

I know it won't work when I replicate but I also know various other
things need to be taken to account when I start to distribute my
application too. I'd like to be able to choose when to consider these
things.

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

Yes but it does work on a single node and allows *better* local 'shard'
consistency and also allows simpler conflict checking whilst an
application is growing (I can spend my initial investment money on
developing application code, not dealing with distribution before it's
needed).

I'll give you an example of why we would really like to have bulk docs.
I would like to have self consistent views for the users of my web
application. At the moment with bulk docs I can manage this as I know a
user will always be served from a single node and hence I can account
for this by making sure my single node is *more consistent* than my
distributed system may be.

I'm not expecting ACID type compliance but I can acheive a lot by making
my local node as self consistent as possible (which is what we are
currently doing).

I don't want to talk about using forks of CouchDB at this point but I
can see having to seriously consider it..

Please, please consider including this and putting a big sign against it
saying "USE THIS WISELY!!" .

And whilst I'm talking - I love using CouchDB and I think the reason
people get passionate about it is because they like it so much.

Tim

Mime
View raw message