Object leak on reference flush

Objects with foreign key references register for changed events. If you flush these objects and let them disappear from scope and all the caches, they are garbage collected but leave their ObjectInfo records still attached and subscribed to the change events.

Targetting for 0.16 since we have a patch and this is making bits of Launchpad explode.

Assigning a task to rosetta as this bug is blocking message sharing data migration. We can wait for 0.16 or put together a package with the fix to use in the interim.

If we are having a re-rollout, this is something I'd like to see in it.

While breaking the cached reference when a flush occurs might solve this bug, do we really want to invalidate this cache at that point?

Given we've had a number of problems with EventSystem holding references longer than we'd like, might it be worth extending it to use weakrefs to remove this class of problem completely?

Django's signal system behaves this way (the main complication is that bound instance method objects are flyweight, so it needs to reference the instance object and unbound instance method).

Merged in storm trunk in r342.

With the time to test this slipping, we are going to QA this for 3.1.11 LP release due next week, but only patched with this revision: we can't wait for a new release and live with only few days of QA today.

FYI, we have QAd this fix and it does indeed fix the leak we've experienced with our script.

New storm integrated into lp:launchpad/devel r9949.

This bug was mentioned in stable r9949 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/9949>