On 12/02/2009, at 8:13 AM, Damien Katz wrote:
Hi Antony. Just to clarify, there is no vote, as there is no patch
ready yet.
Sorry Damien, jumped the gun.
And I think you don't want to vote against the patch, you want to
vote against the removal of guaranteed interactive conflict checking.
I'm not keen on either of the transaction models presented for use
with _bulk_docs. The first is as you say, but also the second, because
it removes write-ordering consistency. Obviously caveat user applies,
but I think it's too dangerous.
Though the code is very much intertwined, the rest of the patch
(replication security and optional revision stemming) is not
directly related to semantics how bulk transactions work.
I have no issue with those given that they are both optional, although
I am interested in an alternative model of history truncation that is
linear wrt the db rather than each document, but that's a separate
issue and I've yet to translate that from the extant research to
CouchDB.
To be clear, the reason I don't want to all of nothing transactions
w/ conflict checking is I don't know how we'll support it in
partitioned cluster. For an example of something I know can support
my proposed models, see this posting by Ricky Ho:
http://horicky.blogspot.com/2008/10/couchdb-cluster.html
Sure, and I think that's the right impulse. I think it would be better
to either
1. Commit to _bulk_docs continuing to work in a single-node case; or
2. Remove it completely until we better understand the design and
constraints of the partitioned CouchDB, and hence the possibilities
and trade-offs for some kind of ACID. My take is that it will be
possible, and the issue will be the cost, which I think should be in
the hands of the user.
Obvious Ricky Ho's model has certain implications, but I'm not sure
that it's the right model for clustering. Putting a proxy into the mix
sounds like it really should be middleware, with it's own operational
contract. I think a less loosely coupled clustering model would be
superior, but then I don't regard fractal uniformity as an ultimate
goal.
As far as distributed transactions go, I'd be thrilled if we could
implement it and also support the rest of couchdb, like views and bi-
directional replication. Please start up a discussion here in dev@
about it and see if you can work out a design.
Distributed transactions is a very misleading term in this
environment. I think the weak-consistency guarantees can be slightly
stronger than CouchDB, but they're still weak. The closure of the
reference graph from Bayou will take a while to follow, but even so, I
think replication that maintains write-dependencies is relatively easy
to do. One key is to recognize that the a local transaction can have
either fail-on-conflict or commit-on-conflict semantics in an ACID
manner, but replication transactions are always commit-on-conflict.
It's obviously important not to confuse the consistency of ACID with
the conflict of weak-consistency.
Anyway, I'll hold off on further discussion until I see your changes
because the devil's in the details, and I'm under the impression that
you have some extensive changes in the pipeline?
There was another use case presented in user@ that was interesting
to me. I'm not sure it's necessary (or even correct) for their case,
but I'm thinking that maybe we should allow all-or-nothing
transactions with guaranteed conflict checking, but making it hard
to enable, or require to pass in a flag name like "non-partitioned-
and-non-replicable-transaction=true", so that it advertises it's
limitations. It's bad to have misleading features, and cause people
relying on CouchDB to do things it can't really do.
Agreed, with the caveat that CouchDB in different configurations can,
and IMO should have configurable semantics.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
You can't just ask customers what they want and then try to give that
to them. By the time you get it built, they'll want something new.
-- Steve Jobs
