https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10459
--- Comment #55 from M. Tompsett <mtomp...@hotmail.com> --- (In reply to Marcel de Rooy from comment #52) > What about filling created_on once in AddMember ? > Mysql accepts: > `stamp1` timestamp NULL DEFAULT NULL, > `stamp2` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE > CURRENT_TIMESTAMP That's a possibility, but the idea was just a structural change. The updated_on is sufficient for the bug's original intention. (In reply to Bernardo Gonzalez Kriegel from comment #54) > Which MySQL version? Whatever is current with Debian 8, I believe. (In reply to Bernardo Gonzalez Kriegel from comment #54) > For example this two columns in virtualshelves give problems on 5.7: > > `lastmodified` timestamp NOT NULL default CURRENT_TIMESTAMP on update > CURRENT_TIMESTAMP, -- date and time the list was last modified > `created_on` TIMESTAMP NOT NULL, -- creation time Well, obviously, because NOT NULL means you need a default value. MySQL is trying to avoid the NULL vs. 0000-00-00 issue. That's why Marcel was suggesting NULL default NULL above. My comment was aimed at the disappointment that the following: `updated_on` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, -- date and time the list was last modified `created_on` TIMESTAMP NOT NULL default CURRENT_TIMESTAMP, -- creation time Which probably is the equivalent to the less explicit version BKG gave above. QA-wise, this should be just fine. I'd push a secondary patch to add created_on with an update in the appropriate Koha perl code in another bug. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org 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/