FAQ

[CouchDB-dev] single node atomic bulk_docs operations

Dean Landolt
Mar 17, 2009 at 1:58 pm

On Tue, Mar 17, 2009 at 9:49 AM, Tim Parkin wrote:

Dean Landolt wrote:
--snip --
Interesting read -- and good examples. But I would argue there are more than
philosophical drawbacks. As I understand it, it would mean giving up the
replication feature entirely. Forever...or at least as long as bulk-docs are
relied upon. There's more to replication than scaling (fault tolerance, for
one). If your application absolutely needs transactions, and you can't
design around it (e.g. doc-level transactions), you may need another tool
for the job -- one not named for a "cluster of unreliable commodity
hardware".
Could you explain why it would mean giving up on replication completely?

Tim

The possible application I'm talking about doesn't need transactions,
they just need a simple way of rolling back a set of changes
(preferably atomically but not necessarily). I'm not looking to banish
conflicts, just minimise them where possible.
I can't find the message right now, but Damien pointed out some edge cases
that make replication really tangled if you're looking for consistency.
Though as you noted, if your model can handle conflicts, this would be a
non-issue.
reply

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 8 | next ›