> On 22. Mar 2020, at 21:18, 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.
We already took COPY from the WebDAV RFC, we might as well introduce MOVE for
database renames.
HTTP/1.1
MOVE /source_db
Location: /target_db
Best
Jan
—
>
>> 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.
