| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This also mark the association as loaded given we changed it in memory
and avoid the next access to the reader to make a query to the databse.
|
|\
| |
| |
| | |
Use hash lookup for deleting existing associations from `target`
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`Array#delete` searches for all occurrences in the `target` array. When performing `dependent: :destroy` in active_record/associations/collection_association, the loop becomes O(N^2). It is particularly slow when destroying large amount of associations (e.g. 10K records).
Either `Hash` or `Set` can optimize the loop to O(N). `Hash` is slightly faster in this simple usage.
```ruby
class Dummy; end
num = 10_000
test1a = num.times.map { Dummy.new }; nil
test1b = test1a.dup
test2a = num.times.map { Dummy.new }; nil
test2b = test2a.dup
Benchmark.ips do |x|
x.config(stats: :bootstrap, confidence: 95)
x.report("hash") do
hash = test1a.group_by { |r| r }
test1b.select! { |r| !hash[r] }
end
x.report("array") do
test2a.each { |r| test2b.delete(r) }
end
x.compare!
end
```
```
Calculating -------------------------------------
hash 11.000 i/100ms
array 1.000 i/100ms
-------------------------------------------------
hash 114.586 (±16.6%) i/s - 561.000
array 1.710k (±10.3%) i/s - 8.377k
Comparison:
array: 1710.4 i/s
hash: 114.6 i/s - 14.93x slower
```
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In `_create_record`, explicit `transaction` block requires rollback
handling manually when `insert_record` is failed.
We need to handle it in `_create_record`, not in `insert_record`, since
our test cases expect a record added to target and returned even if
`insert_record` is failed,
Closes #31488.
|
| |
| |
| |
| | |
Should be done before `before_add` callbacks.
|
| |
| |
| |
| |
| |
| |
| | |
Currently `ids_reader` doesn't respect dirty target when the target is
not loaded yet unlike `collection.size`. I believe the inconsistency is
a bug, fixes the `ids_reader` to behave consistently regardless of
whether target is loaded or not.
|
| |
| |
| |
| |
| |
| |
| | |
Already loaded associations were running an extra query when `size` was called on the association.
This fix ensures that an extra query is no longer run.
Update tests to use proper methods
|
| |
| |
| |
| |
| | |
So `target.is_a?(Array)` is meaningless, and just use `target.empty?`
instead of `target.blank?`.
|
| |
| |
| |
| |
| |
| |
| | |
With #31615 `type_for_attribute` accepts either
a symbol as well as a string. `has_attribute?` and `attribute_alias`
also accept either. Since these methods call `to_s` on the argument,
we no longer need to do that at the call site.
|
| |
| |
| |
| |
| |
| |
| |
| | |
`ThroughReflection`
This method was introduced in #26718, which is internally used only in
`CollectionAssociation`. There is no need to be in the reflection
classes.
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Fix `reflection.association_primary_key` for `has_many` association
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It is incorrect to treat `options[:primary_key]` as
`association_primary_key` if `has_many` associations because the
`:primary_key` means the column on the owner record, not on the
association record. It will break `ids_reader` and `ids_writer`.
```ruby
people(:david).essay_ids
# => ActiveRecord::StatementInvalid: Mysql2::Error: Unknown column 'essays.first_name' in 'field list': SELECT `essays`.first_name FROM `essays` WHERE `essays`.`writer_id` = 'David'
```
Fixes #14439.
|
|/ /
| |
| |
| |
| | |
Since `Relation` includes `Enumerable`, it is enough to use `super`
simply.
|
|\ \
| | |
| | | |
Return Not found Ids in ActiveRecord::NotFound
|
| |/
| |
| |
| |
| | |
This builds on top of 15e2da656f41af0124f7577858536f3b65462ad5.
now it also returns exact Ids which were not found which will be debugging simple.
|
|/
|
|
|
|
| |
Actually `StatementCache#execute` is always passed the same klass that
the owner klass of the connection when the statement cache is created.
So passing `klass` to `StatementCache.new` will make more DRY.
|
| |
|
|
|
|
|
|
|
| |
This is related with #27680.
Since `where_values_hash` keys constructed by `where` are string, so we
need `stringify_keys` to `create_with_value` before merging it.
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
|\
| |
| |
| | |
Enforce frozen string in Rubocop
|
| | |
|
|/
|
|
| |
Fixes #29627.
|
|\
| |
| |
| |
| | |
kamipo/dont_passing_klass_connection_to_association_scope
Don't passing `klass.connection` to `AssociationScope`
|
| |
| |
| |
| |
| | |
Passing `klass.connection` is redundant because `AssociationScope` is
passed an association itself and an association has `klass`.
|
|/
|
|
|
|
|
|
|
|
|
|
| |
```ruby
car = Car.create!(name: "Tofaş")
# Before
car.bulb_ids # => SELECT "bulbs".ID FROM "bulbs" WHERE "bulbs"."name" = $1 AND "bulbs"."car_id" = $2 [["name", "defaulty"], ["car_id", 3]]
# After
car.bulb_ids # => SELECT "bulbs"."ID" FROM "bulbs" WHERE "bulbs"."name" = $1 AND "bulbs"."car_id" = $2 [["name", "defaulty"], ["car_id", 3]]
```
|
|
|
|
| |
Because constructing `scope` is a little expensive.
|
|
|
|
|
|
|
|
|
|
| |
Some third party modules expects that association returns same proxy
object each time (e.g. for stubbing collection methods:
https://github.com/rspec/rspec-rails/issues/1817).
So I decided that cache the proxy object and reset scope in the proxy
object each time.
Related context: https://github.com/rails/rails/commit/c86a32d7451c5d901620ac58630460915292f88b#commitcomment-2784312
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
association saved in the callback
Related #18155, #26661, 268a5bb, #27434, #27442, and #28599.
Originally #18155 was introduced for preventing double insertion caused
by the after save callback. But it was caused the before save issue
(#26661). 268a5bb fixed #26661, but it was caused the performance
regression (#27434). #27442 added new record to `target` before calling
callbacks for fixing #27434. But it was caused double firing before save
callback (#28599). We cannot add new object to `target` before saving
the object.
This is improving #18155 to only track callbacks after `save`.
Fixes #28599.
|
|\
| |
| | |
Delegate to `scope` rather than `merge!` for collection proxy
|
| |
| |
| |
| | |
Because merging the association scope was removed.
|
| |
| |
| |
| |
| | |
`merge! association.scope(nullify: false)` is expensive but most methods
do not need the merge.
|
|\ \
| | |
| | | |
Avoid to call `set_inverse_instance` twice for `has_many` association
|
| | |
| | |
| | |
| | |
| | | |
`create`, `create!`, and `concat` in `has_many` association hits
`set_inverse_instance` twice. It is enough to hit only once.
|
| | |
| | |
| | |
| | |
| | | |
Simply we can do `target.pluck(reflection.association_primary_key)` if
`target` is loaded.
|
|/ / |
|
|/
|
|
|
|
|
|
|
| |
`append_record` was added at 15ddd51 for not double adding the record.
But adding `append_record` (checking `@target.include?(record)`) caused
performance regression #27434. Instead of checking not double adding the
record, add a record to target before any callbacks loads the record.
Fixes #27434.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|