t/db_dependent/Koha/Acquisition/Order.t .. 10/11 No method count found for Koha::Acquisition::Orders DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Incorrect DATE value: '0000-00-00' [for Statement "SELECT COUNT( * ) FROM `aqorders` `me` WHERE ( ( ( `datecancellationprinted` IS NULL OR `datecancellationprinted` = ? ) AND `ordernumber` IN ( ?, ?, ? ) ) )" with ParamValues: 0='0000-00-00', 1=23, 2=24, 3=25] at /kohadevbox/koha/Koha/Objects.pm line 597 We must remove the comparison with 0000-00-00
Highlighted by bug 23166.
Created attachment 109600 [details] [review] Bug 26365: Remove comparison with 0000-00-00 for datecancellationprinted Using MySQL 8: t/db_dependent/Koha/Acquisition/Order.t .. 10/11 No method count found for Koha::Acquisition::Orders DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Incorrect DATE value: '0000-00-00' [for Statement "SELECT COUNT( * ) FROM `aqorders` `me` WHERE ( ( ( `datecancellationprinted` IS NULL OR `datecancellationprinted` = ? ) AND `ordernumber` IN ( ?, ?, ? ) ) )" with ParamValues: 0='0000-00-00', 1=23, 2=24, 3=25] at /kohadevbox/koha/Koha/Objects.pm line 597 We must remove the comparison with 0000-00-00 Highlighted by bug 23166. I wanted to provide a DB rev but we (obviously) cannot: MySQL [koha_kohadev]> UPDATE aqorders SET datecancellationprinted=NULL WHERE datecancellationprinted="0000-00-00"; ERROR 1292 (22007): Incorrect date value: '0000-00-00' for column 'datecancellationprinted' at row 1
Just came across this one yesterday.
Created attachment 109749 [details] [review] Bug 26365: Remove comparison with 0000-00-00 for datecancellationprinted Using MySQL 8: t/db_dependent/Koha/Acquisition/Order.t .. 10/11 No method count found for Koha::Acquisition::Orders DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Incorrect DATE value: '0000-00-00' [for Statement "SELECT COUNT( * ) FROM `aqorders` `me` WHERE ( ( ( `datecancellationprinted` IS NULL OR `datecancellationprinted` = ? ) AND `ordernumber` IN ( ?, ?, ? ) ) )" with ParamValues: 0='0000-00-00', 1=23, 2=24, 3=25] at /kohadevbox/koha/Koha/Objects.pm line 597 We must remove the comparison with 0000-00-00 Highlighted by bug 23166. I wanted to provide a DB rev but we (obviously) cannot: MySQL [koha_kohadev]> UPDATE aqorders SET datecancellationprinted=NULL WHERE datecancellationprinted="0000-00-00"; ERROR 1292 (22007): Incorrect date value: '0000-00-00' for column 'datecancellationprinted' at row 1 Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Hmm.. regarding the db update can we not use $dbh->{mysql_serverversion} to compare and only execute the update if we have an older MySQL version.. that way we're preparing for upgrades..?
In that case I would be in favour of a maintenance script: before you switch to MySQL 8 (or any other DBMS that won't allowed 0000-00-00), then run it and it will fix all the bad dates.
Created attachment 109849 [details] [review] Bug 26365: Remove comparison with 0000-00-00 for datecancellationprinted Using MySQL 8: t/db_dependent/Koha/Acquisition/Order.t .. 10/11 No method count found for Koha::Acquisition::Orders DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Incorrect DATE value: '0000-00-00' [for Statement "SELECT COUNT( * ) FROM `aqorders` `me` WHERE ( ( ( `datecancellationprinted` IS NULL OR `datecancellationprinted` = ? ) AND `ordernumber` IN ( ?, ?, ? ) ) )" with ParamValues: 0='0000-00-00', 1=23, 2=24, 3=25] at /kohadevbox/koha/Koha/Objects.pm line 597 We must remove the comparison with 0000-00-00 Highlighted by bug 23166. I wanted to provide a DB rev but we (obviously) cannot: MySQL [koha_kohadev]> UPDATE aqorders SET datecancellationprinted=NULL WHERE datecancellationprinted="0000-00-00"; ERROR 1292 (22007): Incorrect date value: '0000-00-00' for column 'datecancellationprinted' at row 1 Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Well.. I'm more than happy with the patch so am passing QA.. DB update wise, I'm not really too worried about it. We do have a number of places more recently in the updatedatebase script which will likely fail in the same way: 19.12.00.076 for example.. I think we'de need to clean up at least some of those back to a particular release if we wanted to be consistent. As it is.. I don't think it's worthwhile blocking this bug.
Pushed to master for 20.11, thanks to everybody involved!
missing dependencies for 20.05.x, no backport