Call assume_migrated_upto_version on connection to prevent it from first
being picked up in method_missing. In the base class, Migration,
method_missing expects the argument to be a table name, and calls
proper_table_name on the arguments before sending to connection. If
table_name_prefix or table_name_suffix is used, the schema version changes
to prefix_version_suffix, breaking `rake test:prepare`.
Fixes#10411.
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.
fixes#10419
Following code should raise IrreversibleMigration. But the code was
failing since options is an array and not a hash.
def change
change_table :users do |t|
t.remove_index [:name, :email]
end
end
Fix was to check if the options is a Hash before operating on it.
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
fixes bug introduced by #3329
These are the conditions necessary to reproduce the bug:
- For an association, autosave => true.
- An association record is being destroyed
- A new association record is being created.
- There is a unique index one of the association's fields.
- The record being created has the same value as the record being
destroyed on the indexed field.
Before, the deletion of records was postponed until after all
insertions/saves. Therefore the new record with the identical value in
the indexed field caused a non-unique value error to be thrown at the database
level.
With this fix, the deletions happen first, before the insertions/saves.
Therefore the record with the duplicate value is gone from the database
before the new record is created, thereby avoiding the non-uniuqe value
error.
When using symbol keys, ActiveRecord will now translate aliased attribute names to the actual column name used in the database:
With the model
class Topic
alias_attribute :heading, :title
end
The call
Topic.where(heading: 'The First Topic')
should yield the same result as
Topic.where(title: 'The First Topic')
This also applies to ActiveRecord::Relation::Calculations calls such as `Model.sum(:aliased)` and `Model.pluck(:aliased)`.
This will not work with SQL fragment strings like `Model.sum('DISTINCT aliased')`.
Github #7839
*Godfrey Chan*
activerecord/lib/active_record/associations.rb states:
# [association=(associate)]
# Assigns the associate object, extracts the primary key, sets it as the foreign key,
# and saves the associate object.
Since commit 42dd5d9f2976677a4bf22347f2dde1a8135dfbb4 to fix#7191, this
is no longer the case if the associate has changed, but is the same
object. For example:
# Pirate has_one :ship
pirate = Pirate.create!(catchphrase: "A Pirate")
ship = pirate.build_ship(name: 'old name')
ship.save!
ship.name = 'new name'
pirate.ship = ship
That last line should trigger a save. Although we are not changing the
association, the associate (ship) has changed.
This commit fixes a regression bug in which counter_cache columns
were not being updated correctly when newly created records were
being pushed into an assocation. EG:
# this was fine
@post.comment.create!
# this was fine
@comment = Comment.first
@post.comments << @comment
# this would not update counters
@post.comments << Comment.create!
The entry is basically copy & paste of the commit message, but the CHANGELOG
has a different purpose than Git history, it just communicates what is new:
* No need to explain why did the bug happen (unless it is truly relevant).
* No need to explain how was the bug fixed.
* Whether the user gives new names to columns does not really matter, use of
select to cherry-pick a column for example also presented that behaviour.
Non-selected attributes are the key, either because they were not included
in the selected list, or because they were but with a different alias.
* In the case of an attribute alias, what you really want to depict is that
respond_to? returns false for the original attribute name.
fixes#4208
If a query selects only a few columns and gives custom names to
those columns then respond_to? was returning true for the non
selected columns. However calling those non selected columns
raises exception.
post = Post.select("'title' as post_title").first
In the above case when `post.body` is invoked then an exception is
raised since `body` attribute is not selected. Howevere `respond_to?`
did not behave correctly.
pos.respond_to?(:body) #=> true
Reason was that Active Record calls `super` to pass the call to
Active Model and all the columns are defined on Active Model.
Fix is to actually check if the data returned from the db contains
the data for column in question.
This reverts commit e8727d37fc49d5bf9976c3cb5c46badb92cf4ced, reversing
changes made to d098e1c24bc145e0cc14532348436e14dc46d375.
Reason: it broke the mysql build
fixes bug introduced by #3329
These are the conditions necessary to reproduce the bug:
- For an association, autosave => true.
- An association record is being destroyed
- A new association record is being created.
- There is a unique index one of the association's fields.
- The record being created has the same value as the record being
destroyed on the indexed field.
Before, the deletion of records was postponed until after all
insertions/saves. Therefore the new record with the identical value in
the indexed field caused a non-unique value error to be thrown at the database
level.
With this fix, the deletions happen first, before the insertions/saves.
Therefore the record with the duplicate value is gone from the database
before the new record is created, thereby avoiding the non-uniuqe value
error.
Fixes#3002. Also see #5494.
```
class Comment < ActiveRecord::Base
belongs_to :post
end
class Author < ActiveRecord::Base
has_many :posts
end
class Post < ActiveRecord::Base
belongs_to :author
has_many :comments
end
```
`Comment.joins(:post).merge(Post.joins(:author).merge(Author.where(:name => "Joe Blogs"))).all` would
fail with `ActiveRecord::ConfigurationError: Association named 'author' was not found on Comment`.
It is failing because `all` is being called on relation which looks like this after all the merging:
`{:joins=>[:post, :author], :where=>[#<Arel::Nodes::Equality: ....}`. In this relation all the context that
`Post` was joined with `Author` is lost and hence the error that `author` was not found on `Comment`.
Ths solution is to build JoinAssociation when two relations with join information are being merged. And later
while building the arel use the previously built `JoinAssociation` record in `JoinDependency#graft` to
build the right from clause.
Thanks to Jared Armstrong (https://github.com/armstrjare) for most of the work. I ported it to make it
compatible with new code base.
