GNU bug report logs - #59346
Adding sqlite-backup

Previous Next

Full log

Message #11 received at 59346 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59346 <at> debbugs.gnu.org
Subject: Re: bug#59346: Adding sqlite-backup
Date: Fri, 18 Nov 2022 09:05:58 -0300

[Message part 1 (text/plain, inline)]

On Fri, Nov 18, 2022 at 4:46 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Andrew Hyatt <ahyatt <at> gmail.com>
> > Date: Thu, 17 Nov 2022 23:40:11 -0300
> >
> > Currently there's no great way to perform a proper backup of a sqlite
> database if you use the built-in sqlite in
> > emacs 29.  If you just copy the file, there's a chance another database
> user is in the middle of something,
> > and the database could be corrupted.
> >
> > I've included a patch that fixes this. I would the sqlite-backup
> function to exist so I can use it in the ELPA
> > triples package.
>
> 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.

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.

Hope this clarifies things, let me know if you have any other questions.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.