From dev-return-49183-archive-asf-public=cust-asf.ponee.io@couchdb.apache.org Sun Mar 22 20:18:49 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 0A19A180645 for ; Sun, 22 Mar 2020 21:18:48 +0100 (CET) Received: (qmail 28498 invoked by uid 500); 22 Mar 2020 20:18:48 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 28485 invoked by uid 99); 22 Mar 2020 20:18:47 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 22 Mar 2020 20:18:47 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id AA1CD18138A for ; Sun, 22 Mar 2020 20:18:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, KAM_COUK=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=dx13.co.uk header.b=HpC6MZbB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TKkfcKt4 Received: from mx1-he-de.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id wGrz-HqVsPX7 for ; Sun, 22 Mar 2020 20:18:44 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=64.147.123.20; helo=wout4-smtp.messagingengine.com; envelope-from=couchdb@dx13.co.uk; receiver= Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id A6A437F623 for ; Sun, 22 Mar 2020 20:18:43 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 5FAAB447 for ; Sun, 22 Mar 2020 16:18:36 -0400 (EDT) Received: from imap8 ([10.202.2.58]) by compute3.internal (MEProxy); Sun, 22 Mar 2020 16:18:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dx13.co.uk; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=RT3Pww4VU+IRaepBv77cm8qH4tVkiTH ud1LDzVx8C/U=; b=HpC6MZbBR07ioWEEt4wBsTrmi5kaB5f7uPyZbGIJIBv+AKw Art58iOhoeZOvw8Ea+Jkw1zkA4jAwa+N72gS4TDsjcMkYoXiNdU5aiUgGd76pnMa BStve/z5sNRiX6Y9jCzBmbcrNDzIlHwHbUzPBe8WwX3iicZu6jFWJiDfIAsZsvXt J+O/E4b05B59RNourp0RONwUCuZ/wRKhiGg7FSimQslyA3TiwnKq6ct1qdqwigsR h+qUgl101bcqIs3LvYKtBSm52zfRSP1x3mfrOwaXlfuqOMHS2/bdDPrHLeTSu4oK Zowx0aM5evHgbSjse4c+eooy8RjUPkG9Moo5KsA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=RT3Pww 4VU+IRaepBv77cm8qH4tVkiTHud1LDzVx8C/U=; b=TKkfcKt4wpvvTZcZlXHBgU g5eB/nWdLxsV02HvyW6qeH6ZDmuv4YLHJ16pDwZyKGTyHibtb7egbqLbT6aJuD9K klTCVFcXQ3wHO+OSVegMqvQ7bgbng8vJaYFwKdgel1J63xxP22nkQ+IYPA1GncFm AQWuUiD2efQfsDI3G5fMlgkf4RBPIuokqFK6nWJ1MZOcvnzDdhtL3uxsVwOIHwAd re2/F9ucmbCn6saVV7h7MQBhjk+QDjMcFN6iueREYT5oveDpjfuMe2+QU+ldVbhf dG8qIF03GmYLtDf35e0drk39F5O+He6Sec/T2qzF93FIVYpcAICsSWxANR0kRM5A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudegiedgudefjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdfoihhkvgcutfhhohguvghsfdcuoegtohhutghhuggs segugidufedrtghordhukheqnecuffhomhgrihhnpegsvghlohifrdhpohhsthenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtohhutghhuggs segugidufedrtghordhukh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D0DAA520093; Sun, 22 Mar 2020 16:18:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: <55fd1267-3a91-4b4f-bb80-b42b65f7bed8@www.fastmail.com> In-Reply-To: References: Date: Sun, 22 Mar 2020 20:18:15 +0000 From: "Mike Rhodes" To: dev@couchdb.apache.org Subject: Re: [DISCUSS] soft-deletion Content-Type: text/plain 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": ""}, "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": "", "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.