Re: sqlite3

[Alexandre Garreau]

Le merkredo, 8-a de decembro 2021, 6-a horo kaj 41:17 CET Qiantan Hong a 
écrit :
> 3. Database files are not readable directly by a text editor.

Well, if we start supporting sqlite, emacs might become such an editor!  
Imagine if when you opened a binary sqlite3 database emacs offered you the 
database, with many elisp commands to edit it by hand? think like 
phpmyadmin, but lighter

> 4. SQLite3 is an additional dependency. I hear people saying one
> can make it optional, but I highly doubt if people are willing
> to maintain 2 version of code with/without SQLite3, especially
> after they starts to write SQL instead of Elisp.

Exactly, so to make that safe we ought to make a standard abstraction over 
sqlite, that encompass some alternatives.

> 5. Database is essential for manipulating trillions of records,
> but that's not a typical use case of Emacs. It provides little
> benefit if data fits into main memory.

We could see new usages of emacs, replacing more other programs with the 
emacs way, or replacing *better* programs emacs (that is, Lars, through 
emacs) is already trying to replace, such as MUA (gnus, rmail), and 
browsers (eww).

> Some other alternative ((g)dbm, recutils) is free from some of
> those problem, but I think the following option is the best overall:
> 
> 1. Implement a persistent key/value store or object store in
> plain Emacs Lisp. I posted an implementation in anther thread
> titled "Against sqlite3!!! (Was: sqlite3)"

Weren’t there some error about using load instead of more safely reading 
file content?

> 2. I highly doubt if LISP is in any case insufficient for querying.
> But in those case, embeding a Prolog implementation in Emacs
> Lisp is a much better option than SQL.

To me prolog is a little overkill, and sql slightly more readable and 
practical to query complex values.  If you want something almost as 
practical but simpler, there’s also SparQL, which is used by WikiData and 
comes from the semantic/xml/rdf world.

However, one could just as well reimplement SQL into emacs, starting with 
a naive implementation that just do what’s asked, without formidable 
optimisation.  If anyone did that, we could even use that on top of gdbm 
and unintentionally end up with a not undecent lisp database…  And that 
could be used as a even higher sql-ish, yet lisp, abstraction to (efficient 
or not) databases.