Thanks Mike for quick response. See below
> On Mar 23, 2020, at 4:18 AM, Mike Rhodes <couc...@dx13.co.uk> 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":
>>> "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.
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.
