export notmuch_database_reopen

classic Classic list List threaded Threaded
6 messages Options
Reto Reto
Reply | Threaded
Open this post in threaded view
|

export notmuch_database_reopen

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
_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
David Bremner-2 David Bremner-2
Reply | Threaded
Open this post in threaded view
|

Re: export notmuch_database_reopen

Reto <[hidden email]> 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
_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
Reto Reto
Reply | Threaded
Open this post in threaded view
|

Re: export notmuch_database_reopen

On 13 February 2020 23:54:48 CET, David Bremner <[hidden email]> 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
_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
Daniel Kahn Gillmor Daniel Kahn Gillmor
Reply | Threaded
Open this post in threaded view
|

Re: export notmuch_database_reopen

In reply to this post by Reto
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

_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch

signature.asc (233 bytes) Download Attachment
Reto Reto
Reply | Threaded
Open this post in threaded view
|

Re: export notmuch_database_reopen

On 20 February 2020 18:18:52 CET, Daniel Kahn Gillmor <[hidden email]> 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

_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
Daniel Kahn Gillmor Daniel Kahn Gillmor
Reply | Threaded
Open this post in threaded view
|

Re: export notmuch_database_reopen

On Thu 2020-02-20 19:16:23 +0100, Reto wrote:
> On 20 February 2020 18:18:52 CET, Daniel Kahn Gillmor <[hidden email]> 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('[hidden email]').tags.add('testing123')
print("after:")
for m in db.messages('tag:testing123'):
    print(m.messageid)
db.find('[hidden email]').tags.remove('testing123')
```

It prints:

```
before:
after:
[hidden email]
```

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

_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch

signature.asc (233 bytes) Download Attachment