export notmuch_database_reopen

export notmuch_database_reopen

[Reto]

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 to avoid unnecessary create / destroy cycles of the DB,
especially as I'm calling the C lib via a go wrapper.

Would it be possible to export `_notmuch_database_reopen`?
Then I could call that instead. I mostly have a read only DB open anyhow.

Kind regards,
Reto

Re: export notmuch_database_reopen

[David Bremner]

Reto <reto@labrat.space> 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 running processes.
> I'd like to avoid unnecessary create / destroy cycles of the DB,
> especially as I'm calling the C lib via a go wrapper.

Do you have any measurements of time or memory savings?

d

Re: export notmuch_database_reopen

[Reto]

On 13 February 2020 23:54:48 CET, David Bremner <david@tethera.net> 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 suggestion that _notmuch_database_reopen might be sensible to export actually stems from olly on IRC

Re: export notmuch_database_reopen

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

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, then the changes you make to the DB are
also visible, right?  it's not a static snapshot in that sense.

I think you're asking about a situation where you have a read-only DB,
and someone else has modified the database in the meantime.  Is that
correct?

In that case, it might also be nice to be able to detect *when* some
other change has been made, so that you can perform such a reopen.

I don't know xapian well enough to know whether that kind if
inter-process signalling is possible, though.  Maybe Olly can provide
some guidance here?

      --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: export notmuch_database_reopen

[Reto]

On 20 February 2020 18:18:52 CET, Daniel Kahn Gillmor <dkg@fifthhorseman.net> 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?


>I think you're asking about a situation where you have a read-only DB,
>and someone else has modified the database in the meantime.  Is that
>correct?

Yeah, something along those lines.

>In that case, it might also be nice to be able to detect *when* some
>other change has been made, so that you can perform such a reopen.

That'd be great yes.

Thanks for the follow up.

Cheers,
Reto

Re: export notmuch_database_reopen

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]

On Thu 2020-02-20 19:16:23 +0100, Reto wrote:
> On 20 February 2020 18:18:52 CET, Daniel Kahn Gillmor <dkg@fifthhorseman.net> 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?

Just to confirm/clarify:

If i run the following python3 code against a database with your message
in it:

```
import notmuch2
db = notmuch2.Database(mode=notmuch2.Database.MODE.READ_WRITE)
print("before:")
for m in db.messages('tag:testing123'):
    print(m.messageid)
db.find('95638E1C-E025-4863-9F6C-DAF7F8CD4B1A@labrat.space').tags.add('testing123')
print("after:")
for m in db.messages('tag:testing123'):
    print(m.messageid)
db.find('95638E1C-E025-4863-9F6C-DAF7F8CD4B1A@labrat.space').tags.remove('testing123')
```

It prints:

```
before:
after:
95638E1C-E025-4863-9F6C-DAF7F8CD4B1A@labrat.space
```

The fact that "before:" shows nothing, and "after:" shows that the
message ID was tagged suggests to me that changes i make to a r/w
database object *are* reflected in subsequent queries to the same
database object.

Anyway, i agree that it'd be nice to be able to refresh a read-only
database object with a new view of the db if the underlying db has
changed.  However, i wonder what happens to any existing message objects
that are hanging off of the database object at the time that the
database gets reopened.  Should all of those objects all be refreshed as
well?

For example, consider a message object that you can use to enumerate
tags.  When the associated database is reopened, should the enumerated
list of tags change for that message object?

      --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]