couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jiangph <>
Subject Re: [DISCUSS] soft-deletion
Date Mon, 23 Mar 2020 01:21:17 GMT
Thanks Mike for quick response. See below

> On Mar 23, 2020, at 4:18 AM, 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.

Yes, I can imagine that it will be more complex to implement *rename* in CouchDB 3.0 or before.
If this is desired feature, I would like to start implement from soft-deletion piece. For
purely *rename* endpoint, this can be  done in separated bits.

>> 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.

>From the effort’s point of view for restoring to another destination, it should be manage-able
in coming weeks.

> --
> Mike.

View raw message