I'm not keen on prolonging this agony, but I am going to respond to
these points.
On 06/02/2009, at 3:43 PM, Paul Davis wrote:
A brief history:
1. The mythical IRC conversation on 'removing' the feature: (roughly
quoted)
It wasn't mythical - Damien has stated that is what happened. Why do
you use the word 'mythical'?
Damien: I don't think we can support transactional commits in the face
of multiple nodes. We can do ACID writes to disk so that updates
aren't lost, but checking with an unbounded number of servers that a
commit doesn't conflict isn't feasible.
Not unbounded. Look at Scalaris. And in any case, what exactly is this
multi-node mode? Why compromise the API for something that is so
ephemeral that conflict management isn't feasible? What IS feasible?
View consistency? MVCC semantics. If I write a document and then read
it, do I maybe see an earlier document. What about in the view?
Because if views are going to have a consistency guarantee wrt.
writes, then that looks to me like distributed MVCC. Is this not 2PC?
And if views aren't consistent, then why bother? Why not have a client
layer that does content-directed load balancing.
Regardless, this discussion is also about whether supporting a single-
node style of operation is useful, because CouchDB had an ACID
_bulk_docs. IMO it's also about, the danger/cost of abstracting over
operational models with considerably different operational
characteristics - c.f. transparent distribution in object models.
Everyone else: That's pretty reasonable.
Everyone == ? Damien told me explicitly that this change was decided,
and that decision was made on IRC.
What's with this revisionist history Paul?
2. A patch was applied to trunk that made commits to CouchDB
optionally ACID compliant (which gives users the traditional
speed/safety choice) as well as removing the atomic 'all or none'
semantics.
If it's not all or none then it's not ACID with respect to the user
data model. Conflicts are a metadata feature.
Near as I can tell Damien has been nose to the grindstone for quite
some time on this very specific part of the api. Would I like more
status updates and ideas on where he's heading? Of course. Do I trust
him? Yes. Is the community as a whole going to blindly accept some
asinine patch that has no value that removes a crap load of
functionality? No.
Is the PMC going to accept some massive patch that has significant
benefit, but as a side effect removes a key feature, for no good
technical reason? That's what is happening. Damien's patches are
neither asinine, nor of no value. On IRC Chris Anderson noted in
response to a question that Damien has a heap of changes coming, but
that we (the community) have to wait and see what they are.
I tend to think that the 'discussion' that everyone keeps referring to
hasn't even occurred yet. I look at the patch that was applied that
caused this as an unfortunate early release.
And if commits don't represent some sort of decision, what are they? I
saw the patch, thought WTF?, asked about it, and was eventually told
that yes, a decision had been made that the ACID API was being removed.
Admissions first: I have no money riding on this issue. Whether or not
CouchDB has transactional _bulk_docs worries me not at all. Though, I
can't say that I have that much sympathy for a business model that
relies on an open source project's trunk to remain compatible with
required assumptions.
Having an ACID guarantee explicitly stated, and then removed with no
replacement, is not a 'required assumption' on my part. ACID is a big
deal.
And in any case, my 'business model' response is to fork CouchDB,
which is the appropriate response. But still, do you want people to
use this project or not? Promote it or not? What message does that send?
Reductio ad absurdum:
That's about right.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Don't anthropomorphize computers. They hate that.
