Bug 30490 - Should deleting a parent itemtype be CASCADING?
Summary: Should deleting a parent itemtype be CASCADING?
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Database (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
Depends on:
Blocks: 30486
  Show dependency treegraph
Reported: 2022-04-07 14:32 UTC by Marcel de Rooy
Modified: 2022-06-25 15:33 UTC (History)
0 users

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Note You need to log in before you can comment on or make changes to this bug.
Description Marcel de Rooy 2022-04-07 14:32:54 UTC
This is a sync issue between schema and upgrades.

MASTER structure:   CONSTRAINT `itemtypes_ibfk_1` FOREIGN KEY (`parent_type`) REFERENCES `itemtypes` (`itemtype`) ON DELETE CASCADE ON UPDATE CASCADE

$DBversion = ''; ALTER TABLE itemtypes ADD CONSTRAINT itemtypes_ibfk_1 FOREIGN KEY (parent_type) REFERENCES itemtypes (itemtype)

NOTE: When you do not add CASCADE, you fallback to RESTRICT !

Main question is now: Which is right? Should the delete be cascading or not? I would opt for RESTRICT here. A pragmatical choice too; deleting item types will normally not be done so much :)
Comment 1 Katrin Fischer 2022-06-25 15:33:18 UTC
My feeling would be that if you delete a parent itemtype, it should set the field to NULL in the 'child itemtypes'. Does that make sense?

IIUC quietly deleting the 'children' seems a dangerous move, although it should hopefully not be possible while items exist for them.