-
Notifications
You must be signed in to change notification settings - Fork 175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[tools] Script to remove Zero dates for mysql 5.7 #2444
[tools] Script to remove Zero dates for mysql 5.7 #2444
Conversation
" WHERE CAST(".$field['COLUMN_NAME']." AS CHAR(20))='0000-00-00 00:00:00';\n"; | ||
} | ||
} | ||
$output .="SET FOREIGN_KEY_CHECKS=1; \n"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just do the update/alter in the other order? That way you wouldn't need to disable the foreign key checks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be better to use SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0
AND SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS
at the end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@driusan I think it is because some field are not nullable but should be after the ALTER statement. But the only ones that should be nullable are those that have a default value of 0000-00-00 00:00:00 and not CURRENT_TIMESTAMP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another issue popped up where you can not alter if there are 0000-00-00 dates and you cannot update to NULL if column NOT NULL so catch22
change of logic needed
{ | ||
if ($field['COLUMN_DEFAULT']=='0000-00-00') { | ||
echo "The script will modify the date schema for TABLE: `".$field['TABLE_NAME']."` FIELD: `".$field['COLUMN_NAME']."` to default to NULL\n"; | ||
$output .= "ALTER TABLE `".$field['TABLE_NAME']."` MODIFY `".$field['COLUMN_NAME']."` DATE DEFAULT NULL;\n"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what if the column name has a precision set? You can just add COLUMN_TYPE to your select statement and use that value instead of a hardcoded "DATE" to ensure you're setting it back to the exact same data type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(same for datetime below)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gluneau any arguments?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@driusan not sure what "precision" you are talking about. Those statements will only be generated for fields that currently try to default to "0000-00-00". The statements only change the default value of that field without affecting other characteristics of it.
* | ||
* @category Main | ||
* @package Loris | ||
* @author Various <example@example.com> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@author Loris team info-loris.mni@mcgill.ca maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't Rida the author? We should maybe standardize on something for the author line across all of standard LORIS, but right now I think everything just has the original author.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rida/greg collaboration
$output .= "UPDATE ".$database['database'].".".$field['TABLE_NAME']. | ||
" SET ".$field['COLUMN_NAME']."=NULL". | ||
" WHERE CAST(".$field['COLUMN_NAME']." AS CHAR(20))='0000-00-00';\n"; | ||
} else if ($field['DATA_TYPE'] == 'datetime' || $field['DATA_TYPE'] == 'timestamp') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about timestamp column with CURRENT_TIMESTAMP as a default value?
Could you add a COLUMN_DEFAULT <> 'CURRENT_TIMESTAMP' in the select statement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well this will only change if the date is 0000-00-00 whic is closest to null than current_timestamp no ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xlecours If column default is current timestamp, does it mean that it is impossible to have a 0000-00-00 value in that column ??
(my guess is no since even if the default is current timestamp, someone could have tried entering at somepoint an invalid date causing a 0000-00-00 date value to enter the DB)
" WHERE CAST(".$field['COLUMN_NAME']." AS CHAR(20))='0000-00-00 00:00:00';\n"; | ||
} | ||
} | ||
$output .="SET FOREIGN_KEY_CHECKS=1; \n"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be better to use SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0
AND SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS
at the end.
details: |
We looked at this at the PR meeting
* Added script for 00:00:00 dates * bad path * Changed author * reset foreign key check to original value * Reorganize output * More details in query * Replace type by original type * fixed catch 22 * typo * handle non-nullable fields
* Added script for 00:00:00 dates * bad path * Changed author * reset foreign key check to original value * Reorganize output * More details in query * Replace type by original type * fixed catch 22 * typo * handle non-nullable fields
* Added script for 00:00:00 dates * bad path * Changed author * reset foreign key check to original value * Reorganize output * More details in query * Replace type by original type * fixed catch 22 * typo * handle non-nullable fields
No description provided.