-
Notifications
You must be signed in to change notification settings - Fork 278
Change cascading of most 'restrict' foreign keys #2658
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
3bd3df2
to
188d007
Compare
Did quite a few checks in the ui and most important things appeared to be working. Simply some names that disappeared (as expected). This is also when the issue of deleting users resulting in submissions being deleted showed itself. |
188d007
to
038fd3d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only a small remark for the Submission, you change it in file but not in the migration.
Checked all remaining foreign keys using: ``` SELECT rc.DELETE_RULE, rc.UPDATE_RULE, kcu.TABLE_NAME, kcu.COLUMN_NAME, kcu.CONSTRAINT_NAME, kcu.REFERENCED_TABLE_NAME, kcu.REFERENCED_COLUMN_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE kcu INNER JOIN information_schema.REFERENTIAL_CONSTRAINTS AS rc ON kcu.CONSTRAINT_NAME = rc.CONSTRAINT_NAME WHERE kcu.REFERENCED_TABLE_SCHEMA = 'domjudge' AND DELETE_RULE = 'RESTRICT'; ``` After some discussion with Jaap it was decided to set columns referring to judgedaemons to null instead of cascading the delete. A single foreign key's delete rule is kept as 'restrict' since that case looks to be sensible. Fixes DOMjudge#2464, DOMjudge#2465.
The old foreign key was set to cascade, deleting the entire submission when a user got deleted. This feels conceptually wrong since a submission is connected to a team and not to a user. The user of the team of the submission is more 'metadata' than anything else.
038fd3d
to
acdabd1
Compare
Made it a bit clearer how the migration for |
As per #2465, most of the foreign keys who's delete action was set to restrict could have this clause set to either 'cascade' or 'restrict'.
While working on this issue it appeared that deleting a user resulted in deleting of submissions of that team. This has been changed as well. Deleting a team will now simply set the relevant submissions'
userid
attribute tonull
.There might be other cases similar to the user deletion but these have not been looked at.