couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Rhodes" <>
Subject Re: [DISCUSS] soft-deletion
Date Sun, 22 Mar 2020 20:18:15 GMT
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.

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


View raw message