export notmuch_database_reopen

[Daniel Kahn Gillmor]

On Thu 2020-02-20 19:16:23 +0100, Reto wrote:
> On 20 February 2020 18:18:52 CET, Daniel Kahn Gillmor <dkg at 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 at labrat.space').tags.add('testing123')
print("after:")
for m in db.messages('tag:testing123'):
    print(m.messageid)
db.find('95638E1C-E025-4863-9F6C-DAF7F8CD4B1A at labrat.space').tags.remove('testing123')
```

It prints:

```
before:
after:
95638E1C-E025-4863-9F6C-DAF7F8CD4B1A at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20200220/6ee3d94c/attachment.sig>