On Tue, Mar 17, 2009 at 9:49 AM, Tim Parkin <[email protected]> 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.
