Re: sqlite3

[Pip Cet]

On Tue, Dec 7, 2021 at 5:11 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Richard Stallman <rms@gnu.org> writes:
>
> > Would someone please post a concise description of the proposal that is
> > being considered?  There have been over 100 messages in this thread,
> > too many for me to read, but I'd like to know what the issue is.
>
> 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!" What I've been able to make of this so far is:

The proposal is to have Emacs store some user data in some binary
format that cannot be readily inspected, diffed, backed up,
version-controlled, shared, altered, or understood. (Or archived,
published, indexed, checksummed, ...)

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?

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.

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.

(I believe there are also good reasons for avoiding SQL, but those are
not as important as the non-technical issues mentioned above.)

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.

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.

Pip