emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sqlite3


From: Eli Zaretskii
Subject: Re: sqlite3
Date: Wed, 08 Dec 2021 20:57:32 +0200

> From: Pip Cet <pipcet@gmail.com>
> Date: Wed, 8 Dec 2021 18:36:24 +0000
> Cc: eric@ericabrahamsen.net, cesar mena <cesar.mena@gmail.com>,
>  Richard Stallman <rms@gnu.org>, emacs-devel@gnu.org
> 
> > Just read the first one.  It explains everything.
> 
> I disagree, FWIW. There's very little in that message that goes beyond
> "let's use sqlite!"

Why is that a problem?

> The proposal is to have Emacs store some user data in some binary
> format

No, the proposal is to have Emacs _capable_ of storing data in a DB.
We didn't yet seriously discuss whether some core features will
actually use that, and if so, which ones.

> that cannot be readily inspected, diffed, backed up,
> version-controlled, shared, altered, or understood. (Or archived,
> published, indexed, checksummed, ...)

That's incorrect: tools exist that can browse sqlite databases and
compare them.

> Those are huge disadvantages. The benefits are not clear to me at all,
> but they seem to revolve around the time it takes for an interrupted
> or terminated session to restart?

No, the benefit is to be able to store and retrieve data from a
persistent DB.  Python has it, Lua has it, JS has it, so why
shouldn't Emacs be able to have it?

> I don't think there are any applications for which the trade off (gain
> some performance; lose some user freedom) is worth it, but even if
> there are, we should look harder at alternatives which allow us to
> gain similar amounts of performance without littering unsuspecting
> users' .emacs.ds with binary-only files.

If you are right, then this capability will remain largely unused.
Like Lisp threads, for example.  Let's talk in a couple of years.

> And we need to be careful about introducing this "as an option", of
> course, because that means two versions of many packages' core code
> need to be maintained, only one of which will be tested by users who
> have not had the time to customize the defaults.

No, it means the packages that need such a capability will _require_
Emacs with sqlite support.  Like any package that needs to display
SVG requires Emacs with librsvg support, for example.

> I've tested a little and at least in those initial tests, sqlite seems
> to actually delete data from sqlite files when the corresponding rows
> are deleted, but I'd like to mention this explicitly because I'm not
> sure there's actually a guarantee of it in place: if sqlite ever keeps
> storing data that the user thought they deleted, that makes it
> unsuitable for storing the kind of data I would expect in .emacs.d.

Your file system doesn't actually erase the data from the disk,
either, as you probably well know.  That doesn't mean we cannot use
disk I/O in Emacs.

> Of course, none of this is meant to stop people experimenting in any
> way, but I don't see any package that should realistically be able to
> make use of it without an opt-in option and probably an extra warning.

I don't see any reason for these precautions.  We never did that for
any other optional feature that requires an optional library.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]