| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The implementation was using the source class foreign key field instead
of the reflected primary key one to find the old record.
For instance, for this scenario
class Bulb < ActiveRecord::Base
belongs_to :car, :touch => true
end
class Car < ActiveRecord::Base
has_many :bulbs
end
the current implementation was trying to do this query:
Car.where(car_id: X).first
where we should be doing this query:
Car.where(id: X).first
This should hopefully fix the build.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If we don't use inspect inside the class_eval block then the foreign key
is written without quotes causing us to fetch the foreign key value and
not the column name.
|
| | | |
| | | |
| | | |
| | | | |
thanks to @egilburg for suggestion
|
|\ \ \ \
| | | | |
| | | | | |
has_many through obeys order on through association
|
| | | | |
| | | | |
| | | | |
| | | | | |
fixes #10016
|
|\ \ \ \ \
| |/ / / /
|/| | | | |
minor fixes including variable name change and expanded rdoc
|
| | | | | |
|
| |/ / / |
|
|\ \ \ \
| | | | |
| | | | | |
belongs_to :touch should touch old record when transitioning.
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
optimize some code around merge
|
| | |_|_|/
| |/| | | |
|
| |_|/ /
|/| | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
so that it is consistent with the error thrown for +find+ without an
inverse_of association.
|
|/ / /
| | |
| | |
| | |
| | | |
inverse_of option. I've also refactored the code for raising a
RecordNotFound exception when searching for records with ids.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb
activerecord/test/cases/adapter_test.rb
guides/source/testing.md
[ci skip]
|
| | | | |
|
| | | | |
|
| |_|/
|/| | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Closes #9824.
|
| | |
| | |
| | |
| | |
| | | |
if the association already holds that record in memory before checking
the database for the specified ids.
|
| | |
| | |
| | |
| | | |
2. drop assignment of value to sum in test
|
| | |
| | |
| | |
| | |
| | | |
the primary key on an association will make sure that the corresponding
counter on the association is changed properly. Fixes #9722.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reimplements the behaviour of Rails 3, as I couldn't see why we
shouldn't cache the object, and @alindeman had a good use case for
caching it:
https://github.com/rails/rails/commit/c86a32d7451c5d901620ac58630460915292f88b#commitcomment-2784312
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We moved more and more away from passing options to finder / calculation
methods. The `:distinct` option in `#count` was one of the remaining places.
Since we can now combine `Relation#distinct` with `Relation#count` the option
is no longer necessary and can be deprecated.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The similarity of `Relation#uniq` to `Array#uniq` is confusing. Since our
Relation API is close to SQL terms I renamed `#uniq` to `#distinct`.
There is no deprecation. `#uniq` and `#uniq!` are aliases and will continue
to work. I also updated the documentation to promote the use of `#distinct`.
|
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commit https://github.com/rails/rails/pull/9668 shows warning
when `delete_all` is invoked with `:dependent` option
`:destroy`.
Unfortunately invoking `Post.destroy_all` invokes
`post.comments.delete_all` as part of `has_many` callbacks.
This commit ensures that instead `post.comments.destroy_all` is
invoked and in the process no warning is generated.
See issue #9567 for details .
|
| |
| |
| |
| |
| |
| | |
`post.comments.delete_all` will fire callbacks if :dependent option is
:destroy . It will be fixed in Rails 4.1 . In the meantime display
a warning . Look at #9567 for details .
|
|/
|
|
|
| |
This allows end-users to have a `connection` method on their models
without clashing with ActiveRecord internals.
|
|
|
|
|
|
|
|
|
|
|
| |
Closes #7364.
Collection associations behave similar to Arrays. However there is no
way to prepend records. And to append one should use `<<`. Before this
patch `#append` and `#prepend` did not add the record to the loaded
association.
`#append` now behaves like `<<` and `#prepend` is not defined.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the parent of a `belongs_to` record fails to be saved due to
validation errors, `touch` will be called on a new record, which causes
an exception (see https://github.com/rails/rails/pull/9320).
Example:
class Owner < ActiveRecord::Base
validates_presence_of :name
end
class Pet < ActiveRecord::Base
belongs_to :owner, touch: true
end
pet = Pet.new(owner: Owner.new)
# Before, this line would raise ActiveRecord::ActiveRecordError
# "can not touch on a new record object"
pet.save
|
|\ |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
closes #8663.
When preloading a hmt association there two possible scenarios:
1.) preload with 2 queries: first hm association, then hmt with id IN ()
2.) preload with join: hmt association is loaded with a join on the hm association
The bug was happening in scenario 1.) with a normal order clause on the hmt association.
The ordering was also applied when loading the hm association, which resulted in the error.
This patch only applies the ordering the the hm-relation if we are performing a join (2).
Otherwise the order will only appear in the second query (1).
|
|
|
|
| |
closes #8423.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This caused a bug with the new associations implementation, because now
association conditions are represented as Arel nodes internally right up
to when the whole thing gets turned to SQL.
In Rails 3.2, association conditions get turned to raw SQL early on,
which prevents Relation#merge from interfering.
The current implementation was buggy when a default_scope existed on the
target model, since we would basically end up doing:
default_scope.merge(association_scope)
If default_scope contained a where(foo: 'a') and association_scope
contained a where(foo: 'b').where(foo: 'c') then the merger would see
that the same column is representated on both sides of the merge and
collapse the wheres to all but the last: where(foo: 'c')
Now, the RHS of the merge is left alone.
Fixes #8990
|
|
|
|
|
|
|
| |
Suggested by @dhh.
It doesn't affect the generated SQL, so seems reasonable to continue to
allow it as an association option.
|
|
|
|
| |
Fixes #8795
|
| |
|