[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.
- Re: sqlite3, (continued)
- Re: sqlite3, Richard Stallman, 2021/12/17
- Re: sqlite3, Eli Zaretskii, 2021/12/18
- Re: sqlite3, Alexandre Garreau, 2021/12/09
- Re: sqlite3, Georges Ko, 2021/12/09
- Re: sqlite3, Lars Ingebrigtsen, 2021/12/07
- Re: sqlite3, Pip Cet, 2021/12/08
- Re: sqlite3,
Eli Zaretskii <=
- Re: sqlite3, Alexandre Garreau, 2021/12/09
- Re: sqlite3, Pip Cet, 2021/12/09
- Re: sqlite3, Eli Zaretskii, 2021/12/09
- Re: sqlite3, Qiantan Hong, 2021/12/09
- Re: sqlite3, Michael Heerdegen, 2021/12/09
- Re: sqlite3, Qiantan Hong, 2021/12/10
- Re: sqlite3, Eli Zaretskii, 2021/12/10
- Re: sqlite3, Qiantan Hong, 2021/12/10
- Re: sqlite3, Eli Zaretskii, 2021/12/10
- Re: sqlite3, Michael Heerdegen, 2021/12/11