| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| | |
Still touch associations when theres no timestamp
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Prior to Rails 4.0.4 when touching a object which doesn't have timestamp
attributes (updated_at / updated_on) rails would still touch all
associations. After 73ba2c14cd7d7dfb2d132b18c47ade995401736f it updates
associations but rollsback because `touch` would return nil since
there's no timestamp attribute
|
| |/
|
|
| |
Backport test from #14410
|
| |
|
|
|
| |
Dangerous association names conflicts include instance or class
methods already defined by `ActiveRecord::Base`.
|
| |
|
|
|
|
|
|
|
|
| |
Since Rails 4.0, we add an ORDER BY in the `first` method to ensure consistent
results among different database engines. But for singular associations this
behavior is not needed since we will have one record to return. As this
ORDER BY option can lead some performance issues we are removing it for singular
associations accessors.
Fixes #12623.
|
| |
|
|
| |
Fixes: #13445
|
| |
|
|
| |
nullifying its _type column
|
| |
|
|
| |
removed unnecessary test case and improved test case for belongs_to having invalid options
|
| | |
|
| |
|
|
|
|
| |
if belongs to model with touch option on touch
Closes #11288
|
| |
|
|
| |
simplified logic to calculate number of queries by using assert_queries
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes a bug introduced in 96a13fc7 which breaks behaviour of
integer fields.
In 3.2.8, setting the value of an integer field to a non-integer (eg.
Array, Hash, etc.) would default to 1 (true) :
# 3.2.8
p = Post.new
p.category_id = [ 1, 2 ]
p.category_id # => 1
p.category_id = { 3 => 4 }
p.category_id # => 1
In 3.2.9 and above, this will raise a NoMethodError :
# 3.2.9
p = Post.new
p.category_id = [ 1, 2 ]
NoMethodError: undefined method `to_i' for [1, 2]:Array
Whilst at first blush this appear to be sensible, it combines in bad
ways with scoping.
For example, it is common to use scopes to control access to data :
@collection = Posts.where(:category_id => [ 1, 2 ])
@new_post = @collection.new
In 3.2.8, this would work as expected, creating a new Post object
(albeit with @new_post.category_id = 1). However, in 3.2.9 this will
cause the NoMethodError to be raised as above.
It is difficult to avoid triggering this error without descoping before
calling .new, breaking any apps running on 3.2.8 that rely on this
behaviour.
This patch deviates from 3.2.8 in that it does not retain the somewhat
spurious behaviour of setting the attribute to 1. Instead, it explicitly
sets these invalid values to nil :
p = Post.new
p.category_id = [ 1, 2 ]
p.category_id # => nil
This also fixes the situation where a scope using an array will
"pollute" any newly instantiated records.
@new_post = @collection.new
@new_post.category_id # => nil
Finally, 3.2.8 exhibited a behaviour where setting an object to an
integer field caused it to be coerced to "1". This has not been
retained, as it is spurious and surprising in the same way that setting
Arrays and Heshes was :
c = Category.find(6)
p = Post.new
# 3.2.8
p.category_id = c
p.category_id # => 1
# This patch
p.category_id = c
p.category_id # => nil
This commit includes explicit test cases that expose the original issue
with calling new on a scope that uses an Array. As this is a common
situation, an explicit test case is the best way to prevent regressions
in the future.
It also updates and separates existing tests to be explicit about the
situation that is being tested (eg. AR objects vs. other objects vs.
non-integers)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Allows you to do BaseClass.new(:type => "SubClass") as well as
parent.children.build(:type => "SubClass") or parent.build_child
to initialize an STI subclass. Ensures that the class name is a
valid class and that it is in the ancestors of the super class
that the association is expecting.
|
| |
|
|
|
|
|
|
|
| |
Method compilation provides better performance and I think the code
comes out cleaner as well.
A knock on effect is that methods that get redefined produce warnings. I
think this is a good thing. I had to deal with a bunch of warnings
coming from our tests, though.
|
| |
|
|
|
|
|
| |
It doesn't serve much purpose now that ActiveRecord::Base.all returns a
Relation.
The code is moved to active_record_deprecated_finders.
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously it returned an Array.
If you want an array, call e.g. `Post.to_a` rather than `Post.all`. This
is more explicit.
In most cases this should not break existing code, since
Relations use method_missing to delegate unknown methods to #to_a
anyway.
|
| |
|
|
| |
Closes #1190
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
things
|
| | |
|
| |\
| |
| |
| |
| | |
Conflicts:
activerecord/test/cases/associations/belongs_to_associations_test.rb
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
| |
Closes #3104.
|
| | |
|
| | |
|
| |
|
|
| |
record.create_association. Fixes #1960.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
a string
|
| | |
|
| |
|
|
| |
manages the association, and a CollectionProxy class which is *only* a proxy. Singular associations no longer have a proxy. See CHANGELOG for more.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
