| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
| |
when transitioning to new association" until a proper fix is found for #10197"
This reverts commit 7389df139a35436f00876c96d20e81ba23c93f0a.
Conflicts:
activerecord/test/cases/timestamp_test.rb
|
| |
|
|
| |
transitioning to new association" until a proper fix is found for #10197
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| |
| |
| | |
Support transactions in Migrator.run
Conflicts:
activerecord/CHANGELOG.md
|
| | | |
|
| | |
| |
| |
| | |
bit column in Postgresql, because solving ambiguity.
|
| |/ |
|
| | |
|
| |
|
|
| |
[ci skip]
|
| |\
| |
| |
| |
| |
| |
| | |
Statement cache
Conflicts:
activerecord/CHANGELOG.md
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| | |
See #10107.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Correctly parse bigint defaults in PostgreSQL
Conflicts:
activerecord/CHANGELOG.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
|
| | | |
| | |
| | |
| | | |
fixes #10016
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
belongs_to :touch should touch old record when transitioning.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Firebird/Sqlserver/Oracle database tasks.
|
| | |/ /
|/| | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
respect auto_increment in rename_column for mysql
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Adds support for algorithm option in MySQL indexes
Moves USING and algorithm options upstream
The syntax is still specific to the Adapter, so the actual executed string happens
in the corresponding adapter
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
