Re: sqlite3

[Qiantan Hong]

> It would be good for some supporter of each option
> to present all the arguments for that option, conciesely in one message
> for that option.
I’m against using sqlite3, or maybe in general any database.
I support plain Emacs Lisp implementation.

My arguments:

1. Using as a persistent key value store.  However, in this case
the external database provides virtually no benefit over plain
text, because the major cost here is to print/read lisp values,
and you still need to do it when using a database because they
understand strings, not lisp values!

2. As a querying tool over some data.  In this case, the
functionality largely overlaps with LISt Processing itself.  The
argument is the same as why we don’t want to introduce JavaScript
scripting into Emacs.  If developers are lured into writing more
of their code in SQL, those parts are detached from Lisp world
and loses all the niceties from Emacs Lisp (explorability,
dynamic modifiability etc).

3. Database files are not readable directly by a text editor.

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.

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.

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)"

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.