[PATCH] test thread breakage when messages are removed and re-added

[Daniel Kahn Gillmor]

On Thu 2016-03-31 14:34:53 -0300, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> ghost-on-removal
> ----------------
>
> We could unilaterally add a ghost upon message removal.  This has a
> few disadvantages: the message index would leak information about what
> messages the user has ever been exposed to, and we also create a
> perpetually-growing dataset -- the ghosts can never be removed.
>
> ghost-on-removal-when-shared-thread-exists
> ------------------------------------------
>
> We could add a ghost upon message removal iff there are other
> non-ghost messages with the same thread ID.
>
> We'd also need to remove all ghost messages that share a thread when
> the last non-ghost message in that thread is removed.
>
> This still has a bit of information leakage, though: the message index
> would reveal that i've seen a newer message in a thread, even if i had
> deleted it from my message store

One more proposal along these lines:

track-non-ghost-count-per-thread
--------------------------------

If each thread had a count of all the non-ghost messages associated with
it, and that count was properly maintained by the database, then upon
message deletion you would decrement the count.  when that count reached
zero, you could destroy the thread.

This has the same metadata leakage as
ghost-on-removal-when-shared-thread-exists, but i think it might be more
efficient, if we can cope with the denormalized database.

This does have the downside of needing a database transition, though:
we'd have to add this count to all threads in a database upgrade.



What do people think of the different options?  what do you prefer?  is
there some better approach that i've missed?

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20160401/5fe7a645/attachment.sig>