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
> 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
signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: export notmuch_database_reopen
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? >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 notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: export notmuch_database_reopen
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 signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: export notmuch_database_reopen
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 suggestion that _notmuch_database_reopen might be sensible to export actually stems from olly on IRC ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: export notmuch_database_reopen
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 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 notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
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 notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
