Re: Against sqlite3!!!

[Qiantan Hong]

> I'm not very knowledgable with cl-* stuff but doesn't your
> implementation load all key-value pairs at once?  That would be quite a
> disadvantage compared to a DB approach where I'd naturally expect that
> only the value I'm asking for is loaded.
It does, but I’ve done some benchmark and it loads 10k entries in 0.02~0.03 
seconds. 100k entries takes <0.5s.
I’d say it should be suffice for most Emacs application I know of.
Nobody is using Emacs for trillions of business records.

On the other hand save operation is fully incremental and don’t
even need to be invoked explicitly.

Being said that, if we really find out loading is not fast enough, I might
come up with some way to load it in segments lazily. I doubt if that will
ever become necessary.

> Also, how would it ensure consistency when I have 2 parallel emacs
> sessions (like one for mail/irc and one for programming/editing) where
> session 1 modifies the value of key A and the other of key B?  It looks
> like the values of the kv-store that gets saved later will win.  In case
> that's the emacs session which has modified B, it'll revert A to the
> state before the other session modified it, no?
Since it records a log of deltas instead of printing the whole data structure,
different key won’t interfere.

Being said that, currently it probably won’t work because UNIX append
is not atomic and will probably be interleaved into nonsense.
There’re various workarounds, lock file being one, but I like
the idea of keeping only one “controller” instance with exclusive
access to the file more.

> If that were true, I'd say your resist!.el is a non-starter in the
> current form.  It should at least load only values explicitly asked for
> and only persist/override actually changed values.  A trivial solution
> could use one file per key.  Not sure how sensible that is.
It does the latter.

As I’ve mentioned, from the benchmark results, the former doesn’t
seem to be a big problem. You’ll do it at most once for every Emacs
instance anyway.


Best,
Qiantan