| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
callbacks
We pretty frequently get bug reports that "dirty is broken inside of
after callbacks". Intuitively they are correct. You'd expect
`Model.after_save { puts changed? }; model.save` to do the same thing as
`model.save; puts model.changed?`, but it does not.
However, changing this goes much farther than just making the behavior
more intuitive. There are a _ton_ of places inside of AR that can be
drastically simplified with this change. Specifically, autosave
associations, timestamps, touch, counter cache, and just about anything
else in AR that works with callbacks have code to try to avoid "double
save" bugs which we will be able to flat out remove with this change.
We introduce two new sets of methods, both with names that are meant to
be more explicit than dirty. The first set maintains the old behavior,
and their names are meant to center that they are about changes that
occurred during the save that just happened. They are equivalent to
`previous_changes` when called outside of after callbacks, or once the
deprecation cycle moves.
The second set is the new behavior. Their names imply that they are
talking about changes from the database representation. The fact that
this is what we really care about became clear when looking at
`BelongsTo.touch_record` when tests were failing. I'm unsure that this
set of methods should be in the public API. Outside of after callbacks,
they are equivalent to the existing methods on dirty.
Dirty itself is not deprecated, nor are the methods inside of it. They
will only emit the warning when called inside of after callbacks. The
scope of this breakage is pretty large, but the migration path is
simple. Given how much this can improve our codebase, and considering
that it makes our API more intuitive, I think it's worth doing.
|
| |
|
|
|
|
|
| |
`:foreign_type` is a valid option for `belongs_to` and `has_one`
so remove this to `SingularAssociation`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem was that when saving an object, we would
call touch_later on the parent which wont be saved immediteally, and
it wont call any callbacks. That was working one level up because
we were calling touch, during the touch_later commit phase. However that still
didnt solve the problem when you have a 3+ levels of parents to be touched,
as calling touch would affect the parent, but it would be too late to run callbacks
on its grand-parent.
The solution for this, is instead, call touch_later upwards when the first
touch_later is called. So we make sure all the timestamps are updated without relying
on callbacks.
This also removed the hard dependency BelongsTo builder had with the TouchLater module.
So we can still have the old behaviour if TouchLater module is not included.
[fixes 5f5e6d924973003c105feb711cefdb726f312768]
[related #19324]
|
|
|
| |
There is no need to to assign reflection name to a variable, because it's called once.
|
|
|
|
|
|
| |
This class is only used internally. We should keep it out of public
documentation. This patch adds nodoc for
`ActiveRecord::Associations::Builder` and everything nested within.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also removes a false positive test that depends on the fixed bug:
At this time, counter_cache does not work with polymorphic relationships
(which is a bug). The test was added to make sure that no
StaleObjectError is raised when the car is destroyed. No such error is
currently raised because the lock version is not incremented by
appending a wheel to the car.
Furthermore, `assert_difference` succeeds because `car.wheels.count`
does not check the counter cache, but the collection size. The test will
fail if it is replaced with `car.wheels_count || 0`.
|
|
|
|
|
|
|
|
|
|
| |
[fixes #18606]
Make belongs_to use touch over touch_later when running the callbacks.
Add more tests and small method rename
Thanks Jeremy for the feedback.
|
|
|
|
| |
Deprecate `required` option in favor of `optional` for belongs_to.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
Fix bug, when ':dependent => :destroy' violates foreign key constraints
Conflicts:
activerecord/CHANGELOG.md
activerecord/lib/active_record/associations/builder/association.rb
activerecord/lib/active_record/associations/builder/has_one.rb
|
| |
| |
| |
| | |
constraints, issue #12380
|
| | |
|
| | |
|
| |
| |
| |
| | |
destroy
|
| |
| |
| |
| | |
create
|
| | |
|
| |
| |
| |
| | |
Fixes: #13445
|
| |
| |
| |
| | |
This is to get activerecord-deprecated_finders work again
|
| |
| |
| |
| | |
It is need in activerecord-deprecated_finders
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Example: Given you have a comments model with a polymorphic commentable
association (e.g. books and songs) with the touch option set.
Every time you update a comment its commentable should be touched.
This was working when you changed attributes on the comment or when you
moved the comment from one book to another. However, it was not working
when moving a comment from a book to a song. This is now fixed.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, the `has_one` macro incorrectly accepts the `counter_cache` option
due to a bug, although that options was never supported nor functional on
`has_one` and `has_one ... through` relationships. It now correctly raises an
`ArgumentError` when passed that option.
For reference, this bug was introduced in 52f8e4b9.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
the instance
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
All the information is on the reflection, so just get it there.
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
if belongs to model with touch option on touch
Closes #11288
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
counter cache
At present, calling destroy multiple times on the same record results
in the belongs_to counter cache being decremented multiple times. With
this change the record is checked for whether it is already destroyed
prior to decrementing the counter cache.
|
|
|
|
|
|
|
|
|
| |
Trying to lookup the parent class when the association is being built
runs the risk of generating uninitialized constant errors because
classes haven't been fully defined yet. To work around this we look up
the class at runtime through the `association` method.
Fixes #10197.
|
|
|
|
|
|
|
|
|
| |
when transitioning to new association" until a proper fix is found for #10197"
This reverts commit 7389df139a35436f00876c96d20e81ba23c93f0a.
Conflicts:
activerecord/test/cases/timestamp_test.rb
|