Mentat

Rajmund Hruska wrote in #note-6:

I noticed that in the original database design (prior to making changes to solve this issue), deleting a group results in deleting reports linked to this group. As now the relationship between groups and reports is many to many, the behavior should be a bit different. The report should only be deleted if all groups linked to that report are deleted. As far as I know, this can only be solved by trigger. Another option is to just keep the reports in the database.

I assume that deleting groups is quite rare. My question is, should I implement this trigger or keep the report even if all groups linked to this report are deleted?

Actually, I think that implementing a trigger is simpler than implementing handling reports without any groups linked to that report.

Actually I don't like that destructive behaviour implicitly. Admin may decide to delete group as a simple solution to some screwup ("ok, let's just delete the screwed group altogether and create/import it anew"), and cascading behaviour may not be completely obvious, and after that admin is really screwed. I'd not trigger cascade delete - at most the orphaned reports will stay in db accessible only by admin through mentat/reports/search, and determined admin can repair the screwup by manually reassigning them to some group.

Pavel Kácha wrote in #note-9:

Actually I don't like that destructive behaviour implicitly. Admin may decide to delete group as a simple solution to some screwup ("ok, let's just delete the screwed group altogether and create/import it anew"), and cascading behaviour may not be completely obvious, and after that admin is really screwed. I'd not trigger cascade delete - at most the orphaned reports will stay in db accessible only by admin through mentat/reports/search, and determined admin can repair the screwup by manually reassigning them to some group.

I agree. As a rule of thumb, CASCADE DELETE should be reserved for cases where:
- The referenced data would not be accessible otherwise,
- The data is decomposed into multiple tables, so the record would be incomplete.
Preferably both.

I believe this is neither of those cases.

Pavel Kácha wrote in #note-9:

Actually I don't like that destructive behaviour implicitly. Admin may decide to delete group as a simple solution to some screwup ("ok, let's just delete the screwed group altogether and create/import it anew"), and cascading behaviour may not be completely obvious, and after that admin is really screwed. I'd not trigger cascade delete - at most the orphaned reports will stay in db accessible only by admin through mentat/reports/search, and determined admin can repair the screwup by manually reassigning them to some group.

I thought that you might suggest preserving reports without any groups linked. I will handle it then.