| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Fixes casting of IDs to the data type of the association primary key,
rather than then the data type of the model's primary key. (Tests use a
string primary key on the association, rather than an int.)
Tests issue #20995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
9c9fb19 changed the behaviour of the _ids= setters for associations to
raise an AssociationTypeMismatch when unknown IDs are given:
Class: <ActiveRecord::AssociationTypeMismatch>
Message: <"Developer(#43811860) expected, got NilClass(#16732720)">
This restores the original ActiveRecord::RecordNotFound exception with a
much clearer error message:
Class: <ActiveRecord::RecordNotFound>
Message: <"Couldn't find all Developers with 'id': (1, -9999) [WHERE \"contracts\".\"company_id\" = ?] (found 1 results, but was looking for 2)">
Fixes #25719
|
|\
| |
| |
| |
| | |
kamipo/respect_new_records_for_collection_proxy_distinct
Respect new records for `CollectionProxy#uniq`
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently if `CollectionProxy` has more than one new record,
`CollectionProxy#uniq` result is incorrect.
And `CollectionProxy#uniq` was aliased to `distinct` in a1bb6c8b06db.
But the `uniq` method and the `SELECT DISTINCT` method are different
methods. The doc in `CollectionProxy` is for the `SELECT DISTINCT`
method, not for the `uniq` method.
Therefore, reverting the alias in `CollectionProxy` to fix the
inconsistency and to have the both methods.
|
|\ \
| |/
|/| |
Add missing `+` around a some literals.
|
| |
| |
| |
| |
| |
| | |
Mainly around `nil`
[ci skip]
|
|\ \
| | |
| | | |
Remove unnecessary `target.uniq.size` in `CollectionAssociation#size`
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If `association_scope` have `distinct_value`, same record cannot exist
in `target`.
https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/associations/collection_association.rb#L419-L424
```ruby
def add_to_target(record, skip_callbacks = false, &block)
if association_scope.distinct_value
index = @target.index(record)
end
replace_on_target(record, index, skip_callbacks, &block)
end
```
|
|\ \
| | |
| | | |
Remove unused internal `:dependent` option in `CollectionAssociation#delete`
|
| |/
| |
| |
| |
| | |
The internal `:dependent` option was introduced at #10604.
But currently unused.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was caused by 6d0d83a33f59d9415685852cf77818c41e2e2700. While the
bug it's trying to fix is handled if the association is loaded in an
after_(create|save) callback, it doesn't handle any cases that load the
association before the persistence takes place (validation, or before_*
filters). Instead of caring about the timing of persistence, we can just
ensure that we're not double adding the record instead.
The test from that commit actually broke, but it was not because the bug
has been re-introduced. It was because `Bulb` in our test suite is doing
funky things that look like STI but isn't STI, so equality comparison
didn't happen as the loaded model was of a different class.
Fixes #26661.
|
|
|
|
| |
`CollectionAssociation` is internal class and `uniq` is not called.
|
|
|
|
|
| |
Already checked `if !find_target? || loaded?`, unnecessary `!loaded?` in
elsif condition.
|
|
|
|
| |
Simply use its own method because `CollectionProxy` inherits `Relation`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a parent association was accessed in an `after_find` or
`after_initialize` callback, it would always end up loading the
association, and then immediately overwriting the association we just
loaded. If this occurred in a way that the parent's `current_scope` was
set to eager load the child, this would result in an infinite loop and
eventually overflow the stack.
For records that are created with `.new`, we have a mechanism to
perform an action before the callbacks are run. I've introduced the same
code path for records created with `instantiate`, and updated all code
which sets inverse instances on newly loaded associations to use this
block instead.
Fixes #26320.
|
|
|
|
| |
Simply use its own methods because `CollectionProxy` inherits `Relation`.
|
|
|
|
|
|
|
| |
`length` is delegated to `records` (`load_target`) by
`ActiveRecord::Delegation`.
https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/relation/delegation.rb#L38
|
|\
| |
| |
| |
| | |
kamipo/remove_unnecessary_select_for_collection_proxy
Remove unnecessary `select` method for `CollectionProxy`
|
| |
| |
| |
| |
| |
| |
| | |
Currently `CollectionProxy` inherits `Relation` and `Relation` includes
`QueryMethods`. This method is completely duplicated.
https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/relation/query_methods.rb#L271-L275
|
|/
|
|
|
| |
Currently `CollectionProxy` inherits `Relation` therefore we can use
its own methods rather than delegating to collection association.
|
|
|
|
|
|
|
| |
`#second`, `#third`, etc finder methods was added in 03855e790de2224519f55382e3c32118be31eeff.
But the signature of these methods is inconsistent with the original
finder methods. And also the signature of `#first` and `#last` methods
is different from the original. This commit fixes the inconsistency.
|
|
|
|
|
| |
`#first`, `#second`, ..., `#last` methods respects dirty target. But
`#take` doesn't respect it. This commit fixes the inconsistent behavior.
|
|
|
|
| |
Some case expressions remain, need to think about those ones.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Because `scope` (`target_scope`) is a `AssociationRelation`.
`AssociationRelation` handles `set_inverse_instance`.
https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/association_relation.rb#L31-L33
See also #26022.
|
|
|
|
|
|
|
| |
Because `scope` (`target_scope`) is a `AssociationRelation`.
`AssociationRelation` handles `set_inverse_instance`.
https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/association_relation.rb#L31-L33
|
|\
| |
| | |
Add missing `the`
|
| |
| |
| |
| | |
[ci skip]
|
| |
| |
| |
| |
| |
| |
| |
| | |
Ruby 2.4 unifies Fixnum and Bignum into Integer: https://bugs.ruby-lang.org/issues/12005
* Forward compat with new unified Integer class in Ruby 2.4+.
* Backward compat with separate Fixnum/Bignum in Ruby 2.2 & 2.3.
* Drops needless Fixnum distinction in docs, preferring Integer.
|
|/ |
|
| |
|
| |
|
|\
| |
| |
| |
| | |
Changed id-writer to save join table records based on association
primary key #20995.
|
| |
| |
| |
| |
| |
| | |
key #20995
Changed id-writer to save join table records based on association primary key
|
| |
| |
| |
| |
| | |
When same association is loaded in the model creation callback
The new object is inserted into association twice
|
| |
| |
| |
| |
| | |
When `require 'active_support/rails'`, 'active_support/deprecation'
is automatically loaded.
|
| |
| |
| |
| |
| |
| |
| | |
If the through class has default scopes we should skip the statement
cache.
Closes #20745.
|
|/
|
|
|
|
| |
Fixes #21082
remove extra space
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is to simplify the association API, as you can call `reload` on the
association proxy or the parent object to get the same result.
For collection association, you can call `#reload` on association proxy
to force a reload:
@user.posts.reload # Instead of @user.posts(true)
For singular association, you can call `#reload` on the parent object to
clear its association cache then call the association method:
@user.reload.profile # Instead of @user.profile(true)
Passing a truthy argument to force association to reload will be removed
in Rails 5.1.
|
|
|
|
| |
When replacing a has_many association with the same one, there is nothing to do with database but a setter method should still return the substituted value for backward compatibility.
|
|
|
|
|
|
|
|
|
|
| |
present from the start.
When a new record has the necessary information prior to save, we can
avoid busting the cache.
We could simply clear the @proxy on #reset or #reset_scope, but that
would clear the cache more often than necessary.
|
|
|
|
|
|
|
|
|
|
|
| |
Instead use .scope_attributes? consistently in ActiveRecord to check whether
there are attributes currently associated with the scope.
Move the implementation of .scope_attributes? and .scope_attributes to
ActiveRecord::Scoping because they don't particularly have to do specifically
with Named scopes and their only dependency, in the case of
.scope_attributes?, and only caller, in the case of .scope_attributes is
contained in Scoping.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Use SQL COUNT and LIMIT 1 queries for none? and one? methods if no block or limit is given,
instead of loading the entire collection to memory. The any? and many? methods already
follow this behavior.
[Eugene Gilburg & Rafael Mendonça França]
|
|
|
|
|
|
|
|
|
| |
There are many ways that things end up getting passed to `concat`. Not
all of those entry points called `flatten` on their input. It seems that
just about every method that is meant to take a single record, or that
splats its input, is meant to also take an array. `concat` is the
earliest point that is common to all of the methods which add records to
the association. Partially fixes #18689
|