couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Landolt <d...@deanlandolt.com>
Subject Re: single node atomic bulk_docs operations
Date Tue, 17 Mar 2009 13:57:59 GMT
On Tue, Mar 17, 2009 at 9:49 AM, Tim Parkin <info@timparkin.co.uk> 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.

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