Skip to content

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

Merged
merged 2 commits into from
Aug 25, 2024

Conversation

tuupke
Copy link
Contributor

@tuupke tuupke commented Aug 25, 2024

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 to null.

There might be other cases similar to the user deletion but these have not been looked at.

@vmcj vmcj requested a review from nickygerritsen August 25, 2024 15:29
@tuupke tuupke force-pushed the cascading-some-keys branch from 3bd3df2 to 188d007 Compare August 25, 2024 15:31
@tuupke
Copy link
Contributor Author

tuupke commented Aug 25, 2024

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.

@tuupke tuupke force-pushed the cascading-some-keys branch from 188d007 to 038fd3d Compare August 25, 2024 15:56
Copy link
Member

@vmcj vmcj left a 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.

tuupke added 2 commits August 25, 2024 18:13
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.
@tuupke tuupke force-pushed the cascading-some-keys branch from 038fd3d to acdabd1 Compare August 25, 2024 16:17
@tuupke tuupke requested a review from vmcj August 25, 2024 16:17
@tuupke
Copy link
Contributor Author

tuupke commented Aug 25, 2024

Made it a bit clearer how the migration for submission works.

@tuupke tuupke added this pull request to the merge queue Aug 25, 2024
Merged via the queue into DOMjudge:main with commit d44adc2 Aug 25, 2024
21 of 22 checks passed
@tuupke tuupke deleted the cascading-some-keys branch August 25, 2024 16:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants