Hi Antony. Just to clarify, there is no vote, as there is no patch
ready yet. And I think you don't want to vote against the patch, you
want to vote against the removal of guaranteed interactive conflict
checking. 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.
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
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.
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.
-Damien
On Feb 11, 2009, at 3:27 PM, Antony Blakey wrote:
I vote against this patch for the following reasons:
1. My reading of the Bayou research has shown me that transactions
can work with replication. The nature of a transaction is an
interesting issue, but orthogonal to this argument.
2. It's not clear on the real performance hit in a partitioned
database. Furthermore, the hit may be highly dependent on the
configuration and details of the write e.g. application design may
result in transactions always going to one shard.
3. In any case, I argue that it should be up the user whether to
tradeoff a possible performance hit for a ACID semantics.
4. I'm not convinced of the utility of the two models proposed as
replacements for the bulk operations. IMO it would be better to not
have a bulk operation than to have the proposed models.
4. The justification is dependent on the implementation details of a
future feature that isn't itself described or known. From a
procedural point of view therefore it's not possible to assess this
argument because the community has no way of assessing it's validity.
5. This argument is also dependent on another argument that CouchDB
must provide a single API over both single-node and multi-node
operation, and must not allow the user to take advantage of the
differences. I disagree with that, but in any case it's not an
argument that has been put and resolved by the community.
On 08/02/2009, at 2:17 AM, Damien Katz wrote:
[snip]
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
There is nothing more difficult to plan, more doubtful of success,
nor more dangerous to manage than the creation of a new order of
things... Whenever his enemies have the ability to attack the
innovator, they do so with the passion of partisans, while the
others defend him sluggishly, So that the innovator and his party
alike are vulnerable.
-- Niccolo Machiavelli, 1513, The Prince.
