[Koha-bugs] [Bug 10459] borrowers should have a timestamp
bugzilla-daemon at bugs.koha-community.org
bugzilla-daemon at bugs.koha-community.org
Fri May 27 14:55:09 CEST 2016
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10459
--- Comment #55 from M. Tompsett <mtompset at 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.
More information about the Koha-bugs
mailing list