-
Notifications
You must be signed in to change notification settings - Fork 11.1k
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
[8.x] Compare custom date/immutable_date using date comparison #38720
Merged
taylorotwell
merged 1 commit into
laravel:8.x
from
macbookandrew:bugfix/custom-date-casts-dirty-attributes
Sep 8, 2021
Merged
[8.x] Compare custom date/immutable_date using date comparison #38720
taylorotwell
merged 1 commit into
laravel:8.x
from
macbookandrew:bugfix/custom-date-casts-dirty-attributes
Sep 8, 2021
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
andrewminion-luminfire
deleted the
bugfix/custom-date-casts-dirty-attributes
branch
September 8, 2021 16:55
chu121su12
pushed a commit
to chu121su12/framework
that referenced
this pull request
Sep 8, 2021
GrahamCampbell
changed the title
[8.x] - compare custom date/immutable_date using date comparison
[8.x] Xompare custom date/immutable_date using date comparison
Sep 9, 2021
GrahamCampbell
changed the title
[8.x] Xompare custom date/immutable_date using date comparison
[8.x] Compare custom date/immutable_date using date comparison
Sep 9, 2021
taylorotwell
added a commit
that referenced
this pull request
Sep 27, 2021
)" This reverts commit cc13463.
Reverted. |
andrewminion-luminfire
pushed a commit
to macbookandrew/framework
that referenced
this pull request
Sep 27, 2021
See laravel#38828 and laravel#38720
andrewminion-luminfire
referenced
this pull request
Sep 27, 2021
This affects model attribute casts 'date', 'datetime', 'immutable_date', and 'immutable_datetime' with a custom date format being used. e.g., $casts = ['month' => 'datetime:Y-m'] Last week a fix was introduced for attributes being set with Carbon objects that were mistakenly flagged as "dirty" in the model even though dates were the same. However that fix broke behavior of date _strings_ such as $request->validated() being filled into a model. For: $model->fill(['month' => '2021-09'])->save(); Instead of the SQL query binding being "2021-09", it's "2021-09-01 00:00:00" because the date string is reformatted through fromDateTime(), using getDateFormat() and not the custom cast date. Keep the v8.60.0 behavior that sets the raw date string in the attributes payload which is eventually bound in the database query. Avoid going through fromDateTime() that reformats that string. Also remove the added redundant conditional in originalIsEquivalent() as method isDateAttribute() already includes isDateCastable().
andrewminion-luminfire
pushed a commit
to macbookandrew/framework
that referenced
this pull request
Sep 27, 2021
taylorotwell
pushed a commit
that referenced
this pull request
Sep 28, 2021
…38994) * add tests See #38828 and #38720 * update test to pass against current framework * use correct carbon instance types * add custom datetime back to isDateCastable See #388828, #38720 * use underlying Carbon * assign strings instead of Carbon instances * check for custom datetime format only when comparing equivalence
victorvilella
pushed a commit
to cdsistemas/framework
that referenced
this pull request
Oct 12, 2021
victorvilella
pushed a commit
to cdsistemas/framework
that referenced
this pull request
Oct 12, 2021
…avel#38720)" (laravel#38993) This reverts commit cc13463.
victorvilella
pushed a commit
to cdsistemas/framework
that referenced
this pull request
Oct 12, 2021
…aravel#38994) * add tests See laravel#38828 and laravel#38720 * update test to pass against current framework * use correct carbon instance types * add custom datetime back to isDateCastable See #388828, laravel#38720 * use underlying Carbon * assign strings instead of Carbon instances * check for custom datetime format only when comparing equivalence
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description:
Model attributes cast as custom date(time) formats are incorrectly marked as dirty attributes when the value has not in fact changed.
I first noticed this happening as part of a Livewire controller, but it’s not limited to just Livewire.
Steps To Reproduce:
See #38719 for some steps.
Most basic example:
https://github.com/macbookandrew/laravel-bug-report/blob/e44c1422b154b02bb59c2aedae3c9ce45798bc2d/tests/Feature/EventDateTest.php#L41
Cause
The
HasAttributes
originalIsEquivalent
method does not treat custom date/immutable_date attributes as date objects and does a strict comparison; if the Carbon instance has changed, it fails.Suggested solution
If an attribute
isDateCastable()
then compare them usingfromDateTime()
rather than creating new Carbon instances and comparing them.