[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.
- Re: Mutating existing persistent data, (continued)
- Re: Mutating existing persistent data, Bob Rogers, 2021/12/07
- Re: sqlite3, Tim Cross, 2021/12/06
- Re: sqlite3, Arthur Miller, 2021/12/06
- Re: sqlite3, Qiantan Hong, 2021/12/06
- Re: sqlite3, Arthur Miller, 2021/12/06
- Re: sqlite3, Yuri Khan, 2021/12/06
- Re: sqlite3, Stefan Monnier, 2021/12/06
- Re: sqlite3, Qiantan Hong, 2021/12/06
- Re: sqlite3, Stefan Monnier, 2021/12/06
- Re: sqlite3, Arthur Miller, 2021/12/06
- Re: sqlite3,
Arthur Miller <=
- Re: sqlite3, Qiantan Hong, 2021/12/06
- Re: sqlite3, Arthur Miller, 2021/12/06
- Re: sqlite3, Qiantan Hong, 2021/12/06
- Re: sqlite3, Qiantan Hong, 2021/12/06
- Re: sqlite3, Karl Fogel, 2021/12/06
- Re: sqlite3, Stefan Kangas, 2021/12/06
- Re: sqlite3, Po Lu, 2021/12/06
- Re: sqlite3, Stefan Kangas, 2021/12/06
- Re: sqlite3, Jose A. Ortega Ruiz, 2021/12/06
Re: sqlite3, Stefan Kangas, 2021/12/06