https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10459 --- Comment #30 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to M. Tompsett from comment #29)
Because while thinking about that very problem, I found: DROP TABLE IF EXISTS `borrower_debarments`; CREATE TABLE borrower_debarments ( -- tracks restrictions on the patron's record borrower_debarment_id int(11) NOT NULL AUTO_INCREMENT, -- unique key for the restriction borrowernumber int(11) NOT NULL, -- foreign key for borrowers.borrowernumber for patron who is restricted expiration date DEFAULT NULL, -- expiration date of the restriction `type` enum('SUSPENSION','OVERDUES','MANUAL','DISCHARGE') NOT NULL DEFAULT 'MANUAL', -- type of restriction `comment` text, -- comments about the restriction manager_id int(11) DEFAULT NULL, -- foreign key for borrowers.borrowernumber for the librarian managing the restriction created timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, -- date the restriction was added updated timestamp NULL DEFAULT NULL, -- date the restriction was updated PRIMARY KEY (borrower_debarment_id), KEY borrowernumber (borrowernumber), CONSTRAINT `borrower_debarments_ibfk_1` FOREIGN KEY (`borrowernumber`) REFERENCES `borrowers` (`borrowernumber`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
I think there is a logic error on the created timestamp. That is, I think the ON UPDATE clause should be on the updated timestamp.
Good catch. Proving at the same time that we did not adhere to just timestamp everywhere in Koha :) And I am not saying that we should, but others did.. -- You are receiving this mail because: You are watching all bug changes.