On Mon, May 25, 2009 at 1:44 AM, Scott Shumaker sshuma...@gmail.com wrote:
Chris - you said:
Distributed bulk transactions would make for chaotic behavior, as
someone's mostly unrelated change on a remote node could eventually
replicate to me (months later) and knock an entire line of work
On 25/05/2009, at 3:01 PM, Scott Shumaker wrote:
'A' maintains an ordered list of 'B' elements, where the order is
user-defined - imagine allowing a user to re-order photos in a
slideshow. You want to store the photos separately from the
slideshow, because they can be used in multiple
On Sun, May 24, 2009 at 10:44 PM, Scott Shumaker sshuma...@gmail.com wrote:
Chris - you said:
Distributed bulk transactions would make for chaotic behavior, as
someone's mostly unrelated change on a remote node could eventually
replicate to me (months later) and knock an entire line of work
2009/5/25 Chris Anderson jch...@apache.org:
Right, but at least in those cases I can diff the document to figure
out what the conflict is. The bulk transactions you describe could
become conflicting and before I could save the doc I'm working on, I'd
have to figure which other doc was causing
2009/5/25 Antony Blakey antony.bla...@gmail.com:
There is another solution to this problem that I posted to this list about
16 March 2009. In short:
Personally at that point I would reassess my usage of CouchDB
altogether, it just doesn't seem appropriate anymore. Whether or not
couchdb should
Inter-document dependencies come up pretty quickly when you start
trying to represent complex data structures in CouchDB. There are
still a few cases we've encountered where there isn't a great way to
avoid needing transactions. A few examples:
1)
'A' maintains an ordered list of 'B' elements,
Chris - you said:
Distributed bulk transactions would make for chaotic behavior, as
someone's mostly unrelated change on a remote node could eventually
replicate to me (months later) and knock an entire line of work that
I've done into a conflict state.
Months later? If you're really out of sync
On Thu, May 21, 2009 at 8:30 PM, Yuval Kogman nothingm...@woobling.org wrote:
2009/5/21 Adam Kocoloski kocol...@apache.org:
Hi Yuval, thanks for this well-written proposal. I don't really want to
rehash all the discussion from back in February (see the thread beginning at
As a user, when I chose couchdb for my most recent project, I chose it
because I didn't care about transactions. I would've used RDBMS if that
were important.
I chose it because couch solved the problems I needed solved very well.
I don't think transactions should be a big dev focus.
On Fri,
Hello,
In 0.9 CouchDB removed the transactional bulk docs feature in favour
of simplifying sharding/replication.
The priorities behind this decision as I understood them are:
1. ensure that applications developed in a single server don't
suffer from a degradation of guarantees if deployed
1) Generate foo/1 and bar/1 in an atomic _bulk_docs operation
2) Update foo - foo/2
Compact the DB (foo/1 is deleted)
Start replicating to a mirror
Replication crashes before it reaches foo/2
By crash you mean an error due to a conflict between foo/2 and foo/1'
(the mirror's version of
11 matches
Mail list logo
