From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrew Hyatt Newsgroups: gmane.emacs.bugs Subject: bug#59346: Adding sqlite-backup Date: Fri, 18 Nov 2022 23:05:20 -0300 Message-ID: References: <837czsd7sr.fsf@gnu.org> <83h6ywbgo5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d91c5a05edc941d0" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34550"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 59346@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 19 03:06:18 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1owDFJ-0008ol-6G for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 19 Nov 2022 03:06:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1owDF6-0000eM-AR; Fri, 18 Nov 2022 21:06:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1owDF4-0000e0-4j for bug-gnu-emacs@gnu.org; Fri, 18 Nov 2022 21:06:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1owDF3-0001KT-So for bug-gnu-emacs@gnu.org; Fri, 18 Nov 2022 21:06:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1owDF3-0006mQ-Li for bug-gnu-emacs@gnu.org; Fri, 18 Nov 2022 21:06:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Andrew Hyatt Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Nov 2022 02:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59346 X-GNU-PR-Package: emacs Original-Received: via spool by 59346-submit@debbugs.gnu.org id=B59346.166882354226038 (code B ref 59346); Sat, 19 Nov 2022 02:06:01 +0000 Original-Received: (at 59346) by debbugs.gnu.org; 19 Nov 2022 02:05:42 +0000 Original-Received: from localhost ([127.0.0.1]:38581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owDEk-0006lt-0B for submit@debbugs.gnu.org; Fri, 18 Nov 2022 21:05:42 -0500 Original-Received: from mail-yw1-f170.google.com ([209.85.128.170]:45767) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1owDEg-0006le-8O for 59346@debbugs.gnu.org; Fri, 18 Nov 2022 21:05:40 -0500 Original-Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-369426664f9so65685977b3.12 for <59346@debbugs.gnu.org>; Fri, 18 Nov 2022 18:05:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vSEDD0iZRSif4zXHXNcSA7C2Ykcg4tIkzH4LbBcA5oI=; b=I9QOn85gEHDUO8hma9yymkisRQzgE+LVRGuRzwYUBwLzDqsLhdSsrMLtk2HjRkiK+G 8qo9Z+nPOYzqgf1Q0H4DjqnRUzUQZzBd1pUNoi2DBrY3kdQ1gGWQBdHLrYjQ2oYx+xJ+ 9/1lG5PiolDPtlULjKG/AbnTMEMZ0gSsPBIFUYPQox/IUdt16eFkJat7lQgSi8UZzA4b rzzs0/Na0ALlLzlPw+VMBMVlLv/wjj1nXIUdIXCX+68AXnZXqRFn/Me2Ern+MllibC1K rqMe2P6iE5EvzXbSCDBVt5x1+6huNqV/Hs7QI+DsFOz9+KzBT0H901ggFh953dWEjHFZ l37A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vSEDD0iZRSif4zXHXNcSA7C2Ykcg4tIkzH4LbBcA5oI=; b=UWtC5zzHU0HHLoXF4C/ma1pZp49NrJghJIqmSDfSJPVOaP6kuTumb5PZP42HCyAJv3 2qj9CRL+ch47+Txudh5flxteWXRwBxWmAIdi/iBVA4/Tfq3vpfVrmngL9DG0MD4sEcG9 0gkb2nxQATsgWqJtvmOO4zpBZLfr9XAfQvMH2mPbpIF1Cm4KFnyOj5O0ma26SwcVK97A 54CjoWVl0vKIurw9Wq8THnRRdr998nRRk/q7/xPogEfje+icTNN7oLW+knwQs5ruvOgU Tu45gX5PhvQN6HDf1mXFEWfmIKWtPfcl9ATNfkKxgW7myPe4v7iv4Qu83iX92uhOpx+2 0R8w== X-Gm-Message-State: ANoB5pkDjrJNBR3z0WB+0Q588dW+iwExoaZGOuBkT2gwFboGXnjO9/5e nzjB/6gNIvstlDoQr6I1A0g+h4OPlPld5Br0HmCchaTY87BpvA== X-Google-Smtp-Source: AA0mqf7T7Bq9EFZHinO7qrIWEV4eLhKDFmTevCBKURa435xAaYKv/ONbJj409B9MkSZ7Z3n5fc0TFzoCRjZq+dbcXLM= X-Received: by 2002:a05:690c:789:b0:373:5455:6125 with SMTP id bw9-20020a05690c078900b0037354556125mr8933253ywb.27.1668823532508; Fri, 18 Nov 2022 18:05:32 -0800 (PST) In-Reply-To: <83h6ywbgo5.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:248288 Archived-At: --000000000000d91c5a05edc941d0 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 18, 2022 at 9:17 AM Eli Zaretskii wrote: > > From: Andrew Hyatt > > Date: Fri, 18 Nov 2022 09:05:58 -0300 > > Cc: 59346@debbugs.gnu.org > > > > Thanks, but I'm not sure Emacs should support DB administration > > functions of sqlite. Aren't there utilities out there which can be > > used for this? Why should we have this built-in in Emacs? why not > > simply use shell-command or somesuch to invoke the necessary external > > program? > > > > Good questions. Let me respond to your two questions: why does emacs > need to be involved in backups, > > and why can't it control backups some other way? > > > > Emacs already has a file backup facility, but if emacs is primarily > working with data in sqlite, there is no > > mechanism for backups, which seems scary to me. I'd like modules that > rely on sqlite for data to be able to > > back up their data, because the user would like to have some security, > knowing if something goes wrong > > they can always restore a recent backup. > > A database is not like a normal file, and so the fact that Emacs has > backups doesn't seem to be a reason good enough to extend the backups > to DB operations. We don't bother with this when we send email or do > other operations. We also have auto-save and file-locks for normal > file, but not for DBs. And a DB is not a file, it is a (large) > collection of tables and records, and Emacs deals with at most a > single table at a time, AFAIU. > More generally, DB administration is outside of the Emacs scope, and > how to do that properly is outside our expertise. There's more to it > than just backing up the DB. > > So I don't think we should extend the Emacs sqlite3 support in this > direction. > I disagree, but I understand this is just a difference of opinion, so I'm happy to let this patch sit here until there's more demand for this sort of thing. But if you are interested in furthering the conversation, which has a lot to do with what I'm talking about in my upcoming (and already recorded) Emacs conference talk, I don't think the distinction you are making between files and databases is important. Let's say I wanted to store, use and otherwise manipulate contact information with emacs. Right now that sort of thing happens with a file with emacs-readable lists inside, but it's really more natural to do it with a database. The fact that it's done via a file now seems historical, especially now that we have sqlite. I expect that sqlite will be used for this sort of thing more often. However, if there's no database option, then maybe not, since it won't be seen as reliable as the filesystem. I don't think it is reasonable to expect users to figure out how to do this, even if the info is easy to find. I'd like us to be able to encourage the use of sqlite for data, and give the user a good experience when sqlite is the backend. > > > But why can't we do this by invoking backup via the binary? Certainly a > possibility, and in fact that's how I > > would implement it if the sqlite library was instead emacsql-sqlite. > However, I have no idea how to locate the > > binary; that isn't part of the current built-in sqlite implementation. > For good reason, too, it's a built-in > > implementation, including a variable holding the executable path seems > odd. I could add one, but this > > solution seems better to me, since it doubles down on the built-in > sqlite, and doesn't provide an alternative > > mechanism for doing things with sqlite. > > This SO article: > > > https://stackoverflow.com/questions/25675314/how-to-backup-sqlite-database > > (which is the first hit I get if I "how to backup sqlite database" > into the browser search box) says that you can backup the DB by using > the sqlite3 executable. I think it is reasonable to expect users who > want to backup their DB to have this executable and use it for that > purpose (and other purposes, as they need). I do have this executable > here, FWIW. > > So I think these needs should be fulfilled "by other means", not by > Emacs Lisp programs. > --000000000000d91c5a05edc941d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 18, 2022 at 9:17 AM Eli Zaret= skii <eliz@gnu.org> wrote:
> From: Andrew Hyatt <ahyatt@gmail.com>
> Date: Fri, 18 Nov 2022 09:05:58 -0300
> Cc: 59346@d= ebbugs.gnu.org
>
>=C2=A0 Thanks, but I'm not sure Emacs should support DB administrat= ion
>=C2=A0 functions of sqlite.=C2=A0 Aren't there utilities out there = which can be
>=C2=A0 used for this?=C2=A0 Why should we have this built-in in Emacs? = why not
>=C2=A0 simply use shell-command or somesuch to invoke the necessary ext= ernal
>=C2=A0 program?
>
> Good questions. Let me respond to your two questions: why does emacs n= eed to be involved in backups,
> and why can't it control backups some other way?
>
> Emacs already has a file backup facility, but if emacs is primarily wo= rking with data in sqlite, there is no
> mechanism for backups, which seems scary to me.=C2=A0 I'd like mod= ules that rely on sqlite for data to be able to
> back up their data, because the user would like to have some security,= knowing if something goes wrong
> they can always restore a recent backup.

A database is not like a normal file, and so the fact that Emacs has
backups doesn't seem to be a reason good enough to extend the backups to DB operations.=C2=A0 We don't bother with this when we send email or= do
other operations.=C2=A0 We also have auto-save and file-locks for normal file, but not for DBs.=C2=A0 And a DB is not a file, it is a (large)
collection of tables and records, and Emacs deals with at most a
single table at a time, AFAIU.=C2=A0

More generally, DB administration is outside of the Emacs scope, and
how to do that properly is outside our expertise.=C2=A0 There's more to= it
than just backing up the DB.

So I don't think we should extend the Emacs sqlite3 support in this
direction.

I disagree, but I understand= this is just a difference of opinion, so I'm happy to let this patch s= it here until there's more demand for this sort of thing.=C2=A0
But if you are interested in furthering the conversation, which= has a lot to do with what I'm talking about in my upcoming (and alread= y recorded) Emacs conference talk, I don't think the distinction you ar= e making between files and databases is important.=C2=A0 Let's say I wa= nted to store, use and otherwise manipulate contact information with emacs.= =C2=A0 Right now that sort of thing happens with=C2=A0a file with emacs-rea= dable lists inside, but it's really more natural to do it with a databa= se.=C2=A0 The fact that it's done via a file now seems historical, espe= cially now that we have sqlite.=C2=A0 I expect that sqlite will be used for= this sort of thing more often.=C2=A0 However, if there's no database o= ption, then maybe not, since it won't be seen as reliable as the filesy= stem.=C2=A0 I don't think it is reasonable to expect users to figure ou= t how to do this, even if the info is easy to find.=C2=A0 I'd like us t= o be able to encourage the use of sqlite for data, and give the user a good= experience when sqlite is the backend.
=C2=A0

> But why can't we do this by invoking backup via the binary?=C2=A0 = Certainly a possibility, and in fact that's how I
> would implement it if the sqlite library was instead emacsql-sqlite.= =C2=A0 However, I have no idea how to locate the
> binary; that isn't part of the current built-in sqlite implementat= ion.=C2=A0 For good reason, too, it's a built-in
> implementation, including a variable holding the executable path seems= odd.=C2=A0 I could add one, but this
> solution seems better to me, since it doubles down on the built-in sql= ite, and doesn't provide an alternative
> mechanism for doing things with sqlite.

This SO article:

=C2=A0 https://stackoverfl= ow.com/questions/25675314/how-to-backup-sqlite-database

(which is the first hit I get if I "how to backup sqlite database"= ;
into the browser search box) says that you can backup the DB by using
the sqlite3 executable.=C2=A0 I think it is reasonable to expect users who<= br> want to backup their DB to have this executable and use it for that
purpose (and other purposes, as they need).=C2=A0 I do have this executable=
here, FWIW.

So I think these needs should be fulfilled "by other means", not = by
Emacs Lisp programs.
--000000000000d91c5a05edc941d0--