[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