[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sqlite3

From: Qiantan Hong
Subject: Re: sqlite3
Date: Sun, 12 Dec 2021 06:41:24 +0000

> Qiantan Hong <qhong@mit.edu> writes:
>> This interface seems closer to a key value store than
>> persistent variable (which I expect would add persistence
>> functionality to an existing variable).
> It's a persistent variable.  See the scratch/sqlite branch.  (I haven't
> merged this part yet.)
I believe it’s closer to key value store, at least in my program.
It’s basically 
(defvar multisession-store …) 
(defmacro (multisession-value foo) `(store-get ,foo multisession-store))

The persistent variable interface I provide instead
transparently persist and restore the value cell of a variable,
basically you just (persist-make-variable foo), then other code
just use foo directly with no need to change.

I’ve read through multisession, it seems that all of multisession.el,
the current persist.el on Elpa, and my resist!.el & proposal that
would move into persist.el namespace, have very similar aim.
I believe the best plan so far is to provide one unifying interface
under persist.el namespace, and support multiple backend for
persistent store. 
There’s a summary of the plan in

According to the plan above, the current multisession.el would
be reworked a bit to provide store-get and store-put interface.
Users can use the store interface directly, which is very similar to 
`(multisession-value …)`, or they can backed their
“transparent” persistant variables using sqlite3 backend.
We should probably also add (setf store-get) so it functions as a place.
Are you willing to proceed in this direction?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]