Comment 3 for bug 1748712

The commit that corresponds to migration 131 changes the Event model in the following relevant way:

- node = ForeignKey('Node', null=False, editable=False, on_delete=CASCADE)
+ node = ForeignKey('Node', null=True, editable=False, on_delete=SET_NULL)

It's worth noting here that It looks like in this case, Django failed to CASCADE the delete to the event table. The way this happens is noted in the Django docs as follows:

"""
Cascade deletes. Django emulates the behavior of the SQL constraint ON DELETE CASCADE and also deletes the object containing the ForeignKey.
"""

Since Django is /emulating/ the behavior of the cascade delete, it's possible that due to a Django bug (or unlucky timing when stopping a service?) Django failed to delete this row in the database when it should have CASCADEd from the deletion of a Node. With the old model, I wonder if this was implicitly allowed (no foreign key constraint existed at all).

In case anyone else runs across this, here's a general workaround that can be executed from the `sudo maas-region dbshell`:

    DELETE FROM maasserver_event where node_id NOT IN (select id from maasserver_node);