emacs-devel
[Top][All Lists]
Advanced

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

Re: sqlite3


From: Arthur Miller
Subject: Re: sqlite3
Date: Mon, 06 Dec 2021 15:35:07 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Arthur Miller <arthur.miller@live.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I suggested hashmap serialzied to/from file. I used such approach myself for
>>> key-value pairs. It worked fine for me, it was quite simple to read/write
>>> it. Currently I am testing a thing, and I use just assoc list to read/write 
>>> it
>>> to a file, and it works fine for me too.
>>
>> The problem with this approach (which is the standard solution currently
>> in ELisp) is that it works OK for simple cases but breaks down when:
>> - there's a lot of data.
>> - the data is modified by several Emacs sessions at the same time.
>> This second case is what can happen with `ecomplete` or `savehist`.
>
> I wouldn't be surprised, if several processes are involved, if that is what  
> you
> mean with several Emacs sessions at the time, than some locking is needed of
> course, and sqlite is a winner there. I believe.
By the way, after second thought; sqlite locks entire database. If I remember
well they advice against using sqlite db when concurrent write access is needed.

Does Emacs already has possibility to lock files, or possibly a particular
symbol for read/write access; if not, is such mechanism to much work to add?

And about lots of data; sqlite mmaps db file, if I am not misstaken about, and
Emacs has can mmap files right? How granular and usable is portable dumper? Is
it possible to dump a hashmap or some other object to a file, and read in dump
at runtime?

If those two things would be possible, than there is a fast, multiprocess
key-value store with already existing means.

And I still think sqlite would be useful in core :). For example, easier
importing/exporting with other applications, with some more, 'lispy' interface
if we had it in core.



reply via email to

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