Hi,
I'm trying to use the notmuch C library in a mail client.
Now, I learned that an open DB is essentially a snapshot at the time of opening.
If I want the current state of the notmuch DB, I need to reopen the DB.
The client I'm running is interactive and can have long running processes.
I'd like
Reto writes:
> I'm trying to use the notmuch C library in a mail client.
> Now, I learned that an open DB is essentially a snapshot at the time of
> opening.
> If I want the current state of the notmuch DB, I need to reopen the DB.
>
> The client I'm running is interactive and can have long runn
On 13 February 2020 23:54:48 CET, David Bremner wrote:
>Do you have any measurements of time or memory savings?
No, but between not having to do a open/close cycle (including garbage
collection on the go side) and having to do it, I expect it would be better if
the DB can be reopened.
The sugg
On Thu 2020-02-13 22:11:27 +0100, Reto wrote:
> I'm trying to use the notmuch C library in a mail client.
> Now, I learned that an open DB is essentially a snapshot at the time of
> opening.
> If I want the current state of the notmuch DB, I need to reopen the DB.
if you have a read/write DB, the
On 20 February 2020 18:18:52 CET, Daniel Kahn Gillmor
wrote:
>if you have a read/write DB, then the changes you make to the DB are
>also visible, right? it's not a static snapshot in that sense.
Ehm, not the behavior I've seen while I was testing it out, but that may have
been my fault then?
On Thu 2020-02-20 19:16:23 +0100, Reto wrote:
> On 20 February 2020 18:18:52 CET, Daniel Kahn Gillmor
> wrote:
>>if you have a read/write DB, then the changes you make to the DB are
>>also visible, right? it's not a static snapshot in that sense.
>
> Ehm, not the behavior I've seen while I was t
