Re: persistent data feature, or sqlite3 feature?

[Jean Louis <bugs@gnu.support>]

* Richard Stallman <rms@gnu.org> [2021-12-10 07:54]:
> A general-purpose database package such as sqlite3 surely does not
> come with a built-in representation for storing Lisp objects in
> general.  Emacs would need to have a way to encode them as byte
> sequences, and store those byte sequences in the database.
> (This encoding might be `prin1' or it might be something else.)

Not that it exists that I know, and not that it would be hard to make
specific Emacs Lisp type for SQLite

In my personal usage I am converting Emacs Lisp by using
prin1-to-string into the text type of a storage in database and
getting it back from there by using eval.

> It follows that sqlite3 databases containing persistent Lisp data
> stored by Emacs will not in general be naturally interoperable with
> sqlite3 databases made by other programs.

It does not follow. SQLite databases are manageable by other
programs. That data has been written as Lisp is not relevant. Also
text files with Emacs Lisp are not easily run by other programs.

> Other programs won't know about this encoding.  If the other program
> is meant to be a general tool, such as a database explorer, it could
> I suppose operate on Emacs database files, but anything that really
> wants to understand its data won't interoperate with Emacs.

Other programs don't understand Emacs Lisp, true. But other programs
for database management can easily operate on SQLite files created by
Emacs. Interoperability is thus built-in.

> It follows that there is no particular benefit from using a
> general-purpose database system such as sqlite3 _for the purpose of
> holding persistent Lisp data_.

I am doing it all the time, since years already. It is clear that you
do not see the benefit, this is because lack of experience with
databases. Your personal opinion cannot however dispute the fact that
storing information in the databases, especially into relational
databases brings many benefits to computer users, including to
programmers. 

Imagine Emacs profiles, instead of text files, user could press "N"
for new profile or "C" to copy a profile. Profile could contain
packages A, B, C, D, while other profile could contain only C, D
packages; including one profile could have quite different
configuration made for the work in other time zone, different city and
different language, with different input systems and different spell
checking; other profile could be quite different. Simple click could
switch between profiles with the certainty and reliability of data
stored. 

File system is a database. Though maybe not as sophisticated as
relational databases.

For example, we would have such a trouble finding all files on the
file system stored on Mon 14 Feb 2022 05:04:15 PM EAT and it would
take quite long time.

Using more sophisticated databases to store data can only be
helpful. Databases have indexes, and finding objects (files) stored
after Mon 14 Feb 2022 05:04:42 PM EAT would be a breeze.

Numerous intersections queries are available in relational databases.

> 1. Persistent objects.
> 
> 2. Access to arbitrary sqlite3 databases.
> 
> and that makes it incoherent.
> 
> We could implement either feature.  We could implement both.
> But one of them should not control the design of the other!

I don't think those are incoherent. I think that (2) access to
arbitrary sqlite3 databases provides (1) persistent objects by usage
of Emacs Lisp or Emacs C programming (even better); and C programming
should use arbitrary sqlite3 database with the difference that it
would take care of conformity of sexps stored.

By implementing (2) direct Emacs access to arbitraty sqlite3 database
(which already exists through Emacs packages) one achieves (1) to
create persistent objects or anything else one wish and wants.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/