| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
initialize_attributes
If argument of `build_record` has key and value which is same as
default value of database, we should also except the key from
`create_scope` in `initialize_attributes`.
Because at first `build_record` initialize record object with argument
of `build_record`, then assign attributes derived from Association's scope.
In this case `record.changed` does not include the key, which value is
same as default value of database, so we should add the key to except list.
Fix #21893.
|
| |
|
|
|
|
|
| |
If the through class has default scopes we should skip the statement
cache.
Closes #20745.
|
| |
|
|
|
| |
for a namespaced association
fixes #20541
|
| | |
|
| |
|
|
|
|
|
| |
Construction of relations can be a hotspot, we don't want to create one
of these in the constructor. This also allows us to do more expensive
things in the predicate builder's constructor, since it's created once
per AR::Base subclass
|
| |
|
|
|
|
|
| |
Reflection has an available method that is used to check if the
reflection is a collection. Any :has_many macro is considered a
collection and `collection?` should be used instead of
`macro == :has_many`.
|
| |
|
|
|
|
| |
Instead of checking for `macro == :has_one` throughout the
codebase we can create a `has_one?` method to match the `belongs_to?`,
`polymorphic?` and other methods.
|
| |
|
|
|
|
|
|
|
| |
Fix habtm reflection
Conflicts:
activerecord/CHANGELOG.md
activerecord/lib/active_record/counter_cache.rb
activerecord/lib/active_record/reflection.rb
activerecord/test/cases/reflection_test.rb
|
| | |
|
| |
|
|
|
| |
AssociationScope no longer maintains state, so we're safe to keep a
singleton and save on GC time
|
| | |
|
| |
|
|
|
| |
methods that call set_inverse_instance with a record will not have to
pay the cost of a nil check on every call
|
| | |
|
| |
|
|
| |
automatically
|
| | |
|
| |
|
| |
check at association reader that record is inverted and should not be reloaded because of stale was changed at target record
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous implementation was necessary in order to support stuff
like:
class Post < ActiveRecord::Base
default_scope where(published: true)
scope :ordered, order("created_at")
end
If we didn't evaluate the default scope at the last possible moment
before sending the SQL to the database, it would become impossible to
do:
Post.unscoped.ordered
This is because the default scope would already be bound up in the
"ordered" scope, and therefore wouldn't be removed by the
"Post.unscoped" part.
In 4.0, we have deprecated all "eager" forms of scopes. So now you must
write:
class Post < ActiveRecord::Base
default_scope { where(published: true) }
scope :ordered, -> { order("created_at") }
end
This prevents the default scope getting bound up inside the "ordered"
scope, which means we can now have a simpler/better/more natural
implementation of default scoping.
A knock on effect is that some things that didn't work properly now do.
For example it was previously impossible to use #except to remove a part
of the default scope, since the default scope was evaluated after the
call to #except.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Suppose Man has_many interests, and inverse_of is used.
Man.first.interests.first.man will correctly execute two queries,
avoiding the need for a third query when Interest#man is called. This is
because CollectionAssociation#first calls set_inverse_instance.
However Man.first.interests.where("1=1").first.man will execute three
queries, even though this is obviously a subset of the records in the
association.
This is because calling where("1=1") spawns a new Relation object from
the CollectionProxy object, and the Relation has no knowledge of the
association, so it cannot set the inverse instance.
This commit solves the problem by making relations spawned from
CollectionProxies return a new Relation subclass called
AssociationRelation, which does know about associations. Records loaded
from this class will get the inverse instance set properly.
Fixes #5717.
Live commit from La Conf! :sparkles:
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
assignment
For one-to-one nested associations, if you build the new (in-memory)
child object yourself before assignment, then the NestedAttributes
module will not overwrite it, e.g.:
class Member < ActiveRecord::Base
has_one :avatar
accepts_nested_attributes_for :avatar
def avatar
super || build_avatar(width: 200)
end
end
member = Member.new
member.avatar_attributes = {icon: 'sad'}
member.avatar.width # => 200
|
| |\
| |
| |
| |
| | |
Conflicts:
guides/source/action_mailer_basics.md
|
| | | |
|
| |\ \
| |/
|/| |
Association with inverse_of does not set the parent in association building block
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes inconsistency when building children of association
which has inverse_of set properly.
When creating new association object with a block:
parent.association.build do |child|
child.parent.equal?(parent) # false
end
So the block the `child.parent` did not point to the same object.
But when the object is created it points to same instance:
child = parent.association.build
child.parent.equal?(parent) # true
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb
activerecord/test/cases/adapter_test.rb
guides/source/testing.md
[ci skip]
|
| | | | |
|
| | | | |
|
| | |/
|/| |
|
| |/ |
|
| | |
|
| |
|
|
| |
Closes #8265
|
| |\
| |
| |
| |
| |
| |
| | |
Conflicts:
actionpack/lib/action_controller/metal/mime_responds.rb
activerecord/lib/active_record/attribute_methods.rb
guides/source/working_with_javascript_in_rails.md
|
| | | |
|
| | | |
|
| |/
|
|
| |
It's sometimes hard to quickly find where deprecated call was performed, especially in case of migrating between Rails versions. So this is an attempt to improve the call stack part of the warning message by providing caller explicitly.
|
| |
|
|
| |
65843e1acc0c8d285ff79f8c9c49d4d1215440be
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by Active Support)
Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in
https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d
we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.
In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 3803fcce26b837c0117f7d278b83c366dc4ed370.
Conflicts:
activerecord/CHANGELOG.md
It will be deprecated only in 4.0, and removed properly in 4.1.
|
| |
|
|
|
|
|
| |
It doesn't serve much purpose now that ActiveRecord::Base.all returns a
Relation.
The code is moved to active_record_deprecated_finders.
|
| | |
|
| | |
|
| | |
|
| | |
|
