https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10459
--- Comment #30 from Marcel de Rooy <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] http://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/
