couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: [DISCUSS] soft-deletion
Date Mon, 23 Mar 2020 10:42:21 GMT

> On 22. Mar 2020, at 21:18, Mike Rhodes <> wrote:
> On Sat, 21 Mar 2020, at 13:47, jiangph wrote:
>> Thanks a lot, Mike for your comments and suggestion on APIs.  They are 
>> quite helpful. Please see embedded response below.
>>> POST /_deleted_dbs/_restore
>>>   - Restore a database at a given timestamp
>>>   - Allows supplying a destination database.
>>>   - I view _restore as an RPC-like call than a REST call, so it has a body 
>>>       containing the arguments rather than supplying as part of the path:
>>>        { "source": {"db": "animaldb", "ts": "<deletedTS>"}, "destination":
>>>   - Fails if "destination" exists.
>>> If we choose to go with the original suggestion, I would still suggest taking
the RPC approach to restore, meaning it looks like this:
>>>   POST /{db}/_restore
>>>   { "sourceTS": "<deletedTS>", "destination": "animaldb"}
>>> For either approach, "destination" could be optional and default to the original
database name.
>> From technical point of view, it is feasible to implement to restore 
>> database to different destination database. I just want to bring up my 
>> concern about this. If I am correct, there is no endpoint to rename 
>> database in CouchDB 3.0 or before.  if we support to restore database 
>> to new database here, it will provide alternative way to support 
>> *rename*. I am not sure whether this is expected or not.
> Renaming a database is a nice feature. It's not offered in CouchDB 2.0, by my understanding,
because it's not possible to do easily as the rename would essentially be a distributed file
rename across the cluster. In FoundationDB, per my understanding of your original email's
details on the FoundationDB side of things, what soft-delete is, is essentially a rename with
a specialised use-case -- and also a cheap operation. Database rename has certainly been a
feature that I've seen requested a decent number of times, and one which I think it's worth
re-considering given it is practically achievable with the new architecture.
> I am not sure on a good API for renaming a database. As REST doesn't provide us with
clear guidance there, perhaps it'd suit another RPC-like call. I think that works fine for
rarely-used administrative operations, and in my view it's easy to get too wedded to REST
and end up with awkward APIs.

We already took COPY from the WebDAV RFC, we might as well introduce MOVE for database renames.

MOVE /source_db
Location: /target_db


>> You mentioned that restoring database might fail if there is live 
>> database with same name, and it will cause data loss. But I think that 
>> users may replicate live database to another database, and then delete 
>> it, and then restore previously deleted database back to live database, 
>> and replicate data again. The result seems to be equivalent as we 
>> provide restoring to different destination.  
> For me it's about the usability rather than the overall functionality. The scenario I
have in mind is that a user has deleted a database and set up a new production database re-using
the same name. Later that day they realise they need a few documents from the old database
-- being able to restore to a new database path would allow them to do this safely in a few
minutes. The proposed approach involves both a sequence of CouchDB replication operations,
and likely a change to production application configuration part way through to point to a
new database.
> In terms of extra code and testing required by adding options to the restore matrix,
I don't know the difference here. So after outlining the scenario that I had in mind when
I made the suggestion, I'll have to leave the decision here to those who better know the effort
involved to set against the possible benefits.
> --
> Mike.

View raw message