[8.x] Support useCurrentOnUpdate for MySQL datetime column types #36817
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit introduces support for
useCurrentOnUpdate
for MySQL datetimecolumn types. MySQL has supported using
ON UPDATE CURRENT_TIMESTAMP
for
DATETIME
columns sincev5.6.5
(and Laravel supports MySQL 5.7+from what I can tell). Laravel previously only supported
useCurrentOnUpdate
for
TIMESTAMP
columns in MySQL.This allows using
DATETIME
columns for metadata likecreated_at
and
updated_at
more effectively. SinceTIMESTAMP
columns inMySQL suffer from the Year 2038 Problem,
using
DATETIME
columns is preferred in some applications.We set the fractional seconds precision to be consistent
throughout the column initialization (for the column type, the default,
and the on update). MySQL requires that the precision be identical
throughout. Note that this implicitly fixed a (likely rare) bug when
users tried to run something like
->dateTime('foo', 2)->useCurrent()
.Previously this would result in MySQL error code 1067 for invalid
default values. It will not set the default to have the same precision
as the column definition.
The actual code was borrowed heavily from
typeTimeStamp
. Since theyare distinct column types, it felt incorrect to DRY it up despite their
similarities.
Relevant MySQL documentation:
MySQL 5.6
MySQL 5.7
MySQL 8.0