https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39107
--- Comment #6 from Saiful Amin <[email protected]> --- I experimented with an alternative approach that avoids enforcing uniqueness on authorised_value. Instead of making the column unique, I temporarily removed the problematic foreign key: +++ b/installer/data/mysql/kohastructure.sql @@ -3814,8 +3814,8 @@ CREATE TABLE `illrequests` ( ... - CONSTRAINT `illrequests_ibfk` FOREIGN KEY (`batch_id`) REFERENCES `illbatches` (`ill_batch_id`) ON DELETE SET NULL ON UPDATE CASCADE, - CONSTRAINT `illrequests_safk` FOREIGN KEY (`status_alias`) REFERENCES `authorised_values` (`authorised_value`) ON DELETE SET NULL ON UPDATE CASCADE + CONSTRAINT `illrequests_ibfk` FOREIGN KEY (`batch_id`) REFERENCES `illbatches` (`ill_batch_id`) ON DELETE SET NULL ON UPDATE CASCADE + -- CONSTRAINT `illrequests_safk` FOREIGN KEY (`status_alias`) REFERENCES `authorised_values` (`authorised_value`) ON DELETE SET NULL ON UPDATE CASCADE ... With this constraint disabled, Koha installs successfully on MySQL 8.4. This isn't a proposed solution, just a data point: removing the FK does allow the installer to complete, which confirms this is the only direct blocker for MySQL 8.4 compatibility. Obviously, the implications need to be discussed: - status_alias becomes unenforced metadata; inconsistent values could creep in. - ERM currently introduces many duplicate authorised_value entries, so even if we switched the FK to use av_uniq (category,authorised_value), it still wouldn't guarantee correctness. - If the FK is dropped permanently, any code relying on referential integrity for ILL status values would lose database-level protection. Posting this only to help frame the decisions: - Do we enforce uniqueness and require ERM values to be deduplicated? - Do we change the FK to point at a different key? - Or do we drop the FK entirely and enforce integrity in application logic? At least this confirms the MySQL 8.4 blocker is isolated to this single FK constraint. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
