| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
This fixes <"SQLite3::SQLException: no such column: legacy_things.person_id: SELECT \"legacy_things\".* FROM \"legacy_things\" WHERE \"legacy_things\".\"person_id\" = ?">
in OptimisticLockingTest#test_lock_destroy
|
|
|
|
| |
Fixes #14383.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When removing records from a `has_many` association it used
the `primary_key` defined on the association.
Our test suite didn't fail because on all occurences of `:primary_key`,
the specified column was available in both tables. This prevented the
code from raising an exception but it still behaved badly.
I added a test-case to prevent regressions that failed with:
```
1) Error:
HasManyAssociationsTest#test_has_many_assignment_with_custom_primary_key:
ActiveRecord::StatementInvalid: SQLite3::SQLException: no such column: essays.first_name: UPDATE "essays" SET "writer_id" = NULL WHERE "essays"."writer_id" = ? AND "essays"."first_name" IS NULL
```
|
|
|
|
|
|
|
|
| |
PR #5210 added a Friendship model to illustrate a bug, but in doing so
created a confusing structure because both belongs_to declarations in
Friendship referred to the same side of the join. The new structure
maintains the integrity of the bug test while changing the follower
relationship to be more useful for other testing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This reverts commit 4e05bfb8e254c3360a3ca4a6cb332995314338fe.
Reason: BlankTopic#blank? should not be removed to check that dynamic finder with a bang can find a model that responds to `blank?`
|
| |
|
|
|
|
|
|
| |
For some reason postgresql doesn't pass an integer value to load.
cc @tenderlove
|
|
|
|
| |
Fix #8575
|
| |
|
|
|
|
|
|
| |
associations with the same foreign key.
This closes #5200.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two possible scenarios where the @mass_assignment_options
instance variable can become corrupted:
1. If the assign_attributes doesn't complete correctly, then
subsequent calls to a nested attribute assignment method will use
whatever options were passed to the previous assign_attributes call.
2. With nested assign_attributes calls, the inner call will overwrite
the current options. This will only affect nested attributes as the
attribute hash is sanitized before any methods are called.
To fix this we save the current options in a local variable and then
restore these options in an ensure block.
|
|\
| |
| | |
Fix deleting from a HABTM join table upon destroying an object of a model with optimistic locking enabled.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Don't use this:
scope :red, where(color: 'red')
default_scope where(color: 'red')
Use this:
scope :red, -> { where(color: 'red') }
default_scope { where(color: 'red') }
The former has numerous issues. It is a common newbie gotcha to do
the following:
scope :recent, where(published_at: Time.now - 2.weeks)
Or a more subtle variant:
scope :recent, -> { where(published_at: Time.now - 2.weeks) }
scope :recent_red, recent.where(color: 'red')
Eager scopes are also very complex to implement within Active
Record, and there are still bugs. For example, the following does
not do what you expect:
scope :remove_conditions, except(:where)
where(...).remove_conditions # => still has conditions
|
|/
|
|
| |
:strict
|
|
|
|
|
|
| |
See the CHANGELOG for details.
Fixes #950.
|
|
|
|
| |
This reverts commit c99d507fccca2e9e4d12e49b4387e007c5481ae9.
|
| |
|
|
|
|
| |
strict mass assignment sanitizer, fixed build_record to not merge creation_attributes, removed failing nested attributes tests (that feature was broken anyway) #4051
|
| |
|
|
|
|
| |
security options (:as and :without_protection) in build, create and create! methods.
|
|
|
|
| |
security scope using the :as option, while also allowing mass-assignment security to be bypassed using :with_protected
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
activerecord/CHANGELOG
activerecord/lib/active_record/association_preload.rb
activerecord/lib/active_record/associations.rb
activerecord/lib/active_record/associations/class_methods/join_dependency.rb
activerecord/lib/active_record/associations/class_methods/join_dependency/join_association.rb
activerecord/lib/active_record/associations/has_many_association.rb
activerecord/lib/active_record/associations/has_many_through_association.rb
activerecord/lib/active_record/associations/has_one_association.rb
activerecord/lib/active_record/associations/has_one_through_association.rb
activerecord/lib/active_record/associations/through_association_scope.rb
activerecord/lib/active_record/reflection.rb
activerecord/test/cases/associations/has_many_through_associations_test.rb
activerecord/test/cases/associations/has_one_through_associations_test.rb
activerecord/test/cases/reflection_test.rb
activerecord/test/cases/relations_test.rb
activerecord/test/fixtures/memberships.yml
activerecord/test/models/categorization.rb
activerecord/test/models/category.rb
activerecord/test/models/member.rb
activerecord/test/models/reference.rb
activerecord/test/models/tagging.rb
|
| |
| |
| |
| | |
the join record is automatically saved too. This requires the :inverse_of option to be set on the source association in the join model. See the CHANGELOG for details. [#4329 state:resolved]
|
| |
| |
| |
| | |
historical and practical reasons, :delete_all is the default deletion strategy employed by association.delete(*records), despite the fact that the default strategy is :nullify for regular has_many. Also, this only works at all if the source reflection is a belongs_to. For other situations, you should directly modify the through association.
|
| | |
|
| | |
|
|/
|
|
| |
Foo.joins(:bar) will work for through associations. There is some duplicated code now, which will be refactored.
|
| |
|
|
|
|
|
|
| |
state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
|
|
|
|
|
| |
state:resolved]
Signed-off-by: Pratik Naik <pratiknaik@gmail.com>
|
|
|
|
|
|
|
|
|
| |
With self referential associations, the scope for the the top level should not affect fetching of associations, for example
when doing
Person.male.find :all, :include => :friends
we should load all of the friends for each male, not just the male friends.
|
| |
|
|
|
|
|
|
| |
[#45 state:resolved]
Signed-off-by: Michael Koziarski <michael@koziarski.com>
|
|
|
|
|
|
| |
Closes #10998. [cpytel]
git-svn-id: http://svn-commit.rubyonrails.org/rails/trunk@8890 5ecf4fe2-1ee6-0310-87b1-e25e094e27de
|
|
git-svn-id: http://svn-commit.rubyonrails.org/rails/trunk@8657 5ecf4fe2-1ee6-0310-87b1-e25e094e27de
|