https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10459 --- Comment #55 from M. Tompsett <mtompset@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.