You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2009/03/17 12:20:42 UTC
Removing MOVE
Hi dev@,
CouchDB supports the HTTP method MOVE to move a
document to a new document id within a database. MOVE
is really just a convenience method for COPY & DELETE.
In fact internally, it does just that. Damien says the COPY &
DELETE that MOVE does under the hood is not atomic on a
single node. And it is hard to support in the multi-node setup.
Hence, I propose to remove the MOVE feature. A client
can simply do COPY & DELETE to achieve the same
result (modulo having a concurrent change to the source
doc between the COPY and the DELETE which should
be taken care of by the application anyway).
I have a patch that I'll commit if no one objects here.
Cheers
Jan
--
Re: Removing MOVE
Posted by Noah Slater <ns...@apache.org>.
On Tue, Mar 17, 2009 at 01:15:01PM +0100, Jan Lehnardt wrote:
> MOVE is commonly understood to be an atomic sequence of copy & delete.
> In CouchDB (single or multi-node) MOVE is not atomic.
I forgot that MOVE is from RFC2518 (WebDAV) not RFC2616 (HTTP).
The MOVE operation on a non-collection resource is the logical equivalent of a
copy (COPY), followed by consistency maintenance processing, followed by a
delete of the source, where all three actions are performed atomically.
- http://tools.ietf.org/html/rfc2518#section-8.9
I'm sold. Let's toss it.
--
Noah Slater, http://tumbolia.org/nslater
Re: Removing MOVE
Posted by Jan Lehnardt <ja...@apache.org>.
On 17 Mar 2009, at 13:01, Noah Slater wrote:
> On Tue, Mar 17, 2009 at 12:58:46PM +0100, Jan Lehnardt wrote:
>> the feature doesn't work as advertised and creates false expectations
>> about atomicity of operations.
>
> As advertised? The only intrinsic advertisement is the word MOVE
> itself.
MOVE is commonly understood to be an atomic sequence of copy & delete.
In CouchDB (single or multi-node) MOVE is not atomic.
> If there is a problem with expectation, this can be solved with
> documentation.
I don't think we can implement MOVE for multi-node CouchDB without
too much effort (if at all). This is much like the old bulk_docs
behaviour
that we dropped for the same reasons.
I don't think documentation can help here :)
Cheers
Jan
--
Re: Removing MOVE
Posted by Noah Slater <ns...@apache.org>.
On Tue, Mar 17, 2009 at 12:58:46PM +0100, Jan Lehnardt wrote:
> the feature doesn't work as advertised and creates false expectations
> about atomicity of operations.
As advertised? The only intrinsic advertisement is the word MOVE itself.
If there is a problem with expectation, this can be solved with documentation.
--
Noah Slater, http://tumbolia.org/nslater
Re: Removing MOVE
Posted by Jan Lehnardt <ja...@apache.org>.
On 17 Mar 2009, at 12:37, Noah Slater wrote:
> On Tue, Mar 17, 2009 at 12:20:42PM +0100, Jan Lehnardt wrote:
>> Hi dev@,
>>
>> CouchDB supports the HTTP method MOVE to move a
>> document to a new document id within a database. MOVE
>> is really just a convenience method for COPY & DELETE.
>> In fact internally, it does just that. Damien says the COPY &
>> DELETE that MOVE does under the hood is not atomic on a
>> single node. And it is hard to support in the multi-node setup.
>
> So, it's provided as a user convenience feature at no cost co CouchDB.
>
>> Hence, I propose to remove the MOVE feature. A client
>> can simply do COPY & DELETE to achieve the same
>> result (modulo having a concurrent change to the source
>> doc between the COPY and the DELETE which should
>> be taken care of by the application anyway).
>
> And you're proposing to remove this useful feature for what reason?
> Heh.
the feature doesn't work as advertised and creates false expectations
about atomicity of operations.
Cheers
Jan
--
Re: Removing MOVE
Posted by Noah Slater <ns...@apache.org>.
On Tue, Mar 17, 2009 at 12:20:42PM +0100, Jan Lehnardt wrote:
> Hi dev@,
>
> CouchDB supports the HTTP method MOVE to move a
> document to a new document id within a database. MOVE
> is really just a convenience method for COPY & DELETE.
> In fact internally, it does just that. Damien says the COPY &
> DELETE that MOVE does under the hood is not atomic on a
> single node. And it is hard to support in the multi-node setup.
So, it's provided as a user convenience feature at no cost co CouchDB.
> Hence, I propose to remove the MOVE feature. A client
> can simply do COPY & DELETE to achieve the same
> result (modulo having a concurrent change to the source
> doc between the COPY and the DELETE which should
> be taken care of by the application anyway).
And you're proposing to remove this useful feature for what reason? Heh.
--
Noah Slater, http://tumbolia.org/nslater
Re: Removing MOVE
Posted by Paul Carey <pa...@gmail.com>.
>>> Hence, I propose to remove the MOVE feature.
>>
>> I had the impression that at some point MOVE would also (atomically)
>> move the underlying .view files if applied to a design doc. Such a
>> feature would be very useful for upgrading clients.
>>
>> Am I wrong, or was there ever such a proposal?
>
> There was an idea. There's an alternative idea (hashing view index
> filenames by view-function code) that looks more feasible in
> general and doesn't rely on MOVE. If we were to go with moving
> the view files, COPY & DELETE will work, too.
Fine so. Consider my tentative objection retracted.
Paul
Re: Removing MOVE
Posted by Jan Lehnardt <ja...@apache.org>.
On 17 Mar 2009, at 12:40, Paul Carey wrote:
>> Hence, I propose to remove the MOVE feature.
>
> I had the impression that at some point MOVE would also (atomically)
> move the underlying .view files if applied to a design doc. Such a
> feature would be very useful for upgrading clients.
>
> Am I wrong, or was there ever such a proposal?
There was an idea. There's an alternative idea (hashing view index
filenames by view-function code) that looks more feasible in
general and doesn't rely on MOVE. If we were to go with moving
the view files, COPY & DELETE will work, too.
Cheers
Jan
--
Re: Removing MOVE
Posted by Paul Carey <pa...@gmail.com>.
> Hence, I propose to remove the MOVE feature.
I had the impression that at some point MOVE would also (atomically)
move the underlying .view files if applied to a design doc. Such a
feature would be very useful for upgrading clients.
Am I wrong, or was there ever such a proposal?