Re: sqlite3

[Pip Cet]

On Fri, Dec 10, 2021 at 12:33 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Pip Cet <pipcet@gmail.com> writes:
> > I agree that .newsrc.eld and the Gnus registry, as you describe them,
> > have problems that need to be fixed. Making those permanently
> > unfixable by switching to a binary-only format seems like a bad idea
> > to me, unless there are overwhelming advantages that I'm just failing
> > to see so far.
>
> "Need to be fixed"?

Yes. Not particularly urgently, since Emacs has so many long-standing issues.

>  They've been like this for three decades now, and
> it's amusing how they suddenly "need" to be fixed when they're brought
> up as an example for how textual data isn't really a panacea for
> editability, diffing, etc.

I agree, of course, that it's not a panacea. It's easy to get text
formats wrong, and when one does, they need to be fixed.

> The Gnus data is edited within Gnus, because editing the data outside of
> Gnus will lead to breakage.

How were you planning, assuming you want to migrate it to sqlite, to
encourage people to follow that suggestion? I think "editing this file
will most likely break things" is something that should be
communicated to users who have somehow started looking at an sqlite
file, and I'm not sure how they'd know.

Again, I never said that all text formats are, by virtue of being
text-based, readily editable, diffable, etc. What I said is that this
particular binary format isn't.

> >> Putting it in VC is meaningless.
> >
> > How so? I usually have my home directory under version control, and
> > git's xdelta implementation should deal with alists just fine (and
> > produce readable output at sub-line granularity)...
>
> It's meaningless because you can't really do anything with that
> information.

Yes, I can. Not necessarily as much as I'd like to :-)

> >> course) Emacs will come with a mode to inspect and edit these files more
> >> free-form.
> >
> > Indeed, I would have considered it a good idea to introduce such a
> > mode well before proposing (as you might or might not have done) that
> > random packages start using a new library.
>
> Er...  I should have written a new library to allow editing SQLite files
> before starting a discussion about whether Emacs should have in-core
> SQLite support.  Check.

I believe others have pointed out quite clearly that two proposals
have become quite mixed up here, at least in my mind. If it's clear to
you you weren't proposing to use sqlite3 as Emacs's persistent
key-value store, I must have misread the first message.

> (For instance, my imdb mode stashes about 12GB worth of data in sqlite
> and is simple and performant.)

Thanks for the example.

Pip