> On 22. Mar 2020, at 21:18, 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 giv
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/_r
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 datab
Thanks a lot, Mike for your comments and suggestion on APIs. They are quite
helpful. Please see embedded response below.
> On Mar 20, 2020, at 10:07 PM, Mike Rhodes wrote:
>
> Looking good. I'm going to skip the database internals as I'm not at all
> qualified to comment. I do have some comme
Looking good. I'm going to skip the database internals as I'm not at all
qualified to comment. I do have some comments on the HTTP API however.
First, I think this API spec is missing how you find databases which have
soft-deleted versions. For example, this could be:
/_all_dbs
- lists onl
; I also wonder a little bit about the use of "restore" here. I guess there
> maybe should be a little consideration of whether there might be some
> future backup/restore functionality and whether it be able to restore via
> the same method or not. If not then calling thi
mething like "undelete".
Thanks,
Rich
From: jiangph
To: dev@couchdb.apache.org
Date: 18/03/2020 12:05
Subject:[EXTERNAL] [DISCUSS] soft-deletion
Hi Everyone,
Instead of automatically and immediately removing data and index in
database after a delete operation, soft-deletion
Thanks a lot to Nick for further suggestion. Please see below my embedded
response about API nits.
> On Mar 19, 2020, at 6:01 AM, Nick Vatamaniuc wrote:
> I like the API shape, and the implementation looks pretty small and
> easy so far. Bonus points for using the HCA to hopefully get some
> pe
> On Mar 18, 2020, at 14:03, Joan Touzet wrote:
>> And this would all rely on having a continuous backup configured and running
>> that would hold a minimum of 48 hours of changes.
>
> People aren't in the habit of doing this in the field. I don't know if we'd
> be able to impress upon people t
I think it looks good, Peng Hui. Nice work!
I like the API shape, and the implementation looks pretty small and
easy so far. Bonus points for using the HCA to hopefully get some
performance improvement from smaller keys overall. That was Paul's
original idea all along I believe.
Was wondering abo
Alex,
The first con I see for that approach is that its not soft-deletion.
Its actual deletion with an API for restoration. Which, fair enough,
is probably a feature we should consider supporting for CouchDB
installations that are based on FoundationDB.
The second major con is that it relies on C
Hi Alex,
On 2020-03-18 3:31 p.m., Alex Miller wrote:
And this would all rely on having a continuous backup configured and running
that would hold a minimum of 48 hours of changes.
People aren't in the habit of doing this in the field. I don't know if
we'd be able to impress upon people the p
Let me perhaps paint an alternative RFC:
1) `DELETE /{db}`
If soft-deletion is enabled, delete the database subspace, and also record into
?DELETED_DBS the timestamp of the commit and the database subspace prefix
2) `GET /{db}/_deleted_dbs_info`
Return the timestamp (and whatever other info on
Alex,
All joking aside, soft-deletion's target use case is accidental
deletions. This isn't a replacement for backup/restore which will
still happen for all the usual reasons.
Paul
On Wed, Mar 18, 2020 at 1:42 PM Paul Davis wrote:
>
> On Wed, Mar 18, 2020 at 1:29 PM Alex Miller
> wrote:
> >
>
On Wed, Mar 18, 2020 at 1:29 PM Alex Miller
wrote:
>
>
> > On Mar 18, 2020, at 05:04, jiangph wrote:
> >
> > Instead of automatically and immediately removing data and index in
> > database after a delete operation, soft-deletion allows to restore the
> > deleted data back to original state due
> On Mar 18, 2020, at 05:04, jiangph wrote:
>
> Instead of automatically and immediately removing data and index in database
> after a delete operation, soft-deletion allows to restore the deleted data
> back to original state due to a “fat finger”or undesired delete operation, up
> to defin
Hi Everyone,
Instead of automatically and immediately removing data and index in database
after a delete operation, soft-deletion allows to restore the deleted data back
to original state due to a “fat finger”or undesired delete operation, up to
defined periods, such as 48 hours.
In CouchDB 3.
17 matches
Mail list logo
