Re: sqlite3 usage for multisession variable storage

[Lars Ingebrigtsen]

Robin Tarsiger <rtt@dasyatidae.com> writes:

> The difference is in crash recovery; if one instance crashes hard in the
> middle of a transaction, it's "restore the file from backup" time.
> Whether that's okay depends on your surrounding strategy, but it feels
> similar to a subset of the lockfile strategies Emacs already considers
> okay.

It's the "restore from backup" thing that's not acceptable, which makes
MEMORY unworkable here, I think.

> Hmm. What pattern/frequency/relative-frequency of reads/writes is expected
> to be common for these variables? And in particular, what about read-
> modify-write operations? Will applications tend to expect these to be
> atomic (deliberately or otherwise)?

I expect the writes to typically not happen very often.  But it's nice
that they're fast if somebody has a use case for updating a lot.

> If you want periodic maintenance of the DB file, there may also be
> application-level maintenance that would be useful, as I extrapolate it?
> Depending on what's stored in these variables, clearing out stale entries
> and the like may want to be done at an elisp level. Leaving cleanup+VACUUM
> to be done explicitly on timer or user request and then having a hook for
> the non-DB-format-related cleanup might be workable? Not sure.

There's really no way of knowing whether a value is "stale" -- there's
no central list of which keys are in use.

> It cheaply removes a little chunk of potentially surprising behaviors. But
> you may be right in a sense---it depends on whether elisp assumes it can
> trust values read from the store. If so, then the entire DB is just in the
> same "may do anything" trusted zone as the rest of .emacs.d, I suppose?

Yes, it doesn't seem to be a significant attack vector in this context.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no