Database consistency issues

[Daniel Axtens]

>
> I will prepare a patch that adds the foreign keys.

Further to this:

Patchwork 2.1 has that Comment has a foreign key relationship to
submission, not patch.

Patch *inherits* from Submission. This was, in hindsight, one of the
cases where an ORM and object-orientation do not sit well
together. Regardless, there's a migration
(0009_add_submission_model.py) that renames the old Patch to
Submission. It creates a new Patch table, which has Submission as a
foreign key.

Now Submission doesn't have a foreign key to Patch, because a
Submission can be either a Patch or a CoverLetter or the body of a
comment. So deleting a Patch in 2.1 won't delete the Submission, so
it won't trigger the Comment foreign key, and you'll be left with
dangling submissions and comments.

I'm not immediately sure how best to address this except to continue to
unpick the general existence of Submission which is part of my long term
plan.

[Stephen, do we allow comments on cover letters? Can we just add a
foreign key to Comment referencing Patch? Could we add nullable foreign
keys to Submission referencing Patch/CoverLetter/Comment so as to
enforce some more referential integrity? (a la Event)]

In the case of Patchwork 1.1.3, I am more confused - the Comment model
has a foreign key to Patch here. So if you try to delete Patch you
should have got a referential integrity error like I did with
e.g. Events. (Patchwork pre 2.0 is a pain to test as it uses Vagrant
VMs, which use VirtualBox by default, which breaks SecureBoot, so I'm
not going to try to get it going tonight.)

Was there anything you deleted after or during the migration?


Regards,
Daniel

>
> Thanks for the report!
>
> Regards,
> Daniel