> > 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 _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
