Comment 6 for bug 1748712

I think it's likely that this is a subtle/rare bug with postgresql (the transaction should have failed!?), but it could have been something to do with the way MAAS was setting up transaction isolation (IIRC, there were a lot of database transaction related bugs being worked on back then).

A general fix to this issue may involve significantly more than the event table. If I run the following in the MAAS repository:

    git grep AlterField | cut -d':' -f 1 | xargs cat | grep ForeignKey | wc -l

... I see that there are 71 instances in migrations where fields are both altered, and foreign keys are modified. The estimate is a bit high, because a migration could both add a foreign key and modify another field, but each of these 71 alterations implies a change to the constraints. So there are dozens of migrations that *could* cause a foreign key violation, __in the event that the referential integrity of the database has been breached__.

I would rather not implement and maintain dozens of potential workarounds (one more every time we change a foreign key in the model) for database integrity issues in MAAS -- the database should be responsible for database integrity. I feel like we should wait to see if others hit this or similar issues first. If we see this bug happening with the Event model in other environments, maybe we should attempt a one-off workaround (without considering the other foreign keys).

Thoughts?