Re: sqlite3

[Arthur Miller <arthur.miller@live.com>]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think many user experience things in Emacs would be better if Emacs
> remembered more.
>
> The bigger systems don't have this problem -- Gnus needs a large
> .newsrc.eld file, and it maintains that.
>
> The tiny things don't really have this problem, either: You save options
> with `customize-save-variable', and that fine.
>
> It's the many things that fall between these two extremes that have the
> problem: Where you want to store some state, but figuring it's just too
> much work to figure out Yet Another Storage Format, but the data is too
> messy to stash in somebody's .emacs file via Customize (like lists of
> stuff).
>
> So there's a bunch of stuff that Emacs just forgets when you shut down,
> where it perhaps shouldn't.

I would definitely like to see sqlite in core and avialable by default. I really
love it and think it is a great as application/desktop database. I think it
would open for some nice applications people could write.

> I've brought this up before, but I didn't really have a solution then,
> but I think I do now: sqlite3.
>
> sqlite3 is supported on more platforms than Emacs is, the interface is
> small and stable, and (best of all) somebody has already created
> interface functions for Emacs (via a module):
>
>   https://github.com/syohex/emacs-sqlite3
>
> I think it'd be good to bring that into core, and then write a small
> wrapper library (well, a trivial ORM) for the rest of Emacs to use, so
> that we don't have to write SQL all over the place.  That is:
>
> (setf (persistent-data :namespace "emoji" :key "favorites") emoji--favorites)
>
> I.e., what Emacs needs is a persistent key/value store, and this would
> give us that.

> In addition, if somebody really wants to write SQL stuff (it can be very
> handy for some things), having sqlite3 in there gives us that in
> addition for free.
>
> This comes with questions about how the users are supposed be able to
> clear out the data, for instance, but we could have a `M-x
> list-persistent-data' where the users could blow out whatever they want
> to.

My only remark is that sqlite is usually used for exactly same purpose as what
Emacs already has: customize. Your example:

> (setf (persistent-data :namespace "emoji" :key "favorites") emoji--favorites)

looks to me like something one would use customize for.

Also in general since we can read/write lisp objects easily in elisp it is not
hard to serialize/deserialize a hashmap or an assoc list as an application
key-value db. I don't know how many application does this, but I have used it
myself, and it felt trivial to use in my app. Objects that are not serializable
will not be serializable to sql either, without some extra work, so there is not
much win to use sqllite db instead of hashmap. 

Anyway I still think sqlite in core would be nice; I have thought of it several
times myself.

Back to your example, I also wonder if api, as suggested in your example could
be done so it in addition also can automatically take applications prefix as
namespace and variable name as key, so your example could look like: 

(defgroup my-app nil
"My cool app."
:prefix 'my-app-
:group 'applications)

(defcustom my-app-emoji-favorites nil
"List of most used emojis."
:persist t
:type 'list
:group 'my-app)

(setf (persistent-data 'my-app-emoji-favorites) my-app-emoji--favorites)

And if we could also have more declarative api for defvars:

(defvar my-app-foo 'bar
"Foo property of my-app."
:persist t)

Just thoughts.