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":
> > "animaldb"}
> >
> > - 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.
--
Mike.
