| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
decouple the builder classes from the model. Builder objects should be
easier to reuse now.
|
| |
|
| |
|
|\
| |
| | |
Make test order independent
|
| |
| |
| |
| |
| | |
postgresql test if randomly executed then executes "SHOW max_identifier_length". Hence
the need to ignore certain predefined sqls that deal with system calls.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
order on the old ones
The previous behavior added a major backward incompatibility since it
impossible to have a upgrade path without major changes on the
application code.
We are taking the most conservative path to be consistent with the idea
of having a smoother upgrade on Rails 4.
We are reverting the behavior for what was in Rails 3.x and,
if needed, we will implement a new API to prepend the order clauses in
Rails 4.1.
|
| |
|
| |
|
|
|
|
|
|
|
| |
`NestedThroughAssociationsTest` adds records to `member_details` table.
When test performs `@member_details[0]` then the order of record
is not guaranteed. Hence it is best to start with a clean slate by
deleting unwanted records.
|
| |
|
|
|
|
|
|
| |
association proxy
Closes #11248.
|
| |
|
|
|
|
|
|
| |
if belongs to model with touch option on touch
Closes #11288
|
|
|
|
| |
simplified logic to calculate number of queries by using assert_queries
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
neerajdotname/delete_all_should_not_call_callbacks
Do not invoke callbacks when delete_all is called
Conflicts:
activerecord/CHANGELOG.md
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Method `delete_all` should not be invoking callbacks and this
feature was deprecated in Rails 4.0. This is being removed.
`delete_all` will continue to honor the `:dependent` option. However
if `:dependent` value is `:destroy` then the default deletion
strategy for that collection will be applied.
User can also force a deletion strategy by passing parameter to
`delete_all`. For example you can do `@post.comments.delete_all(:nullify)`
|
|/
|
|
|
| |
Deprecated options `delete_sql`, `insert_sql`, `finder_sql` and `counter_sql`
have been deleted.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For example:
class Post < ActiveRecord::Base
default_scope -> { where published: true }
end
class Comment
belongs_to :post
end
When calling `Comment.join(:post)`, we expect to receive only
comments on published posts, since that is the default scope for
posts.
Before this change, the default scope from `Post` was not applied,
so we'd get comments on unpublished posts.
|
|
|
|
| |
They were deprecated in 4.0, planned to remove in 4.1
|
| |
|
| |
|
|
|
|
| |
Closes #11026
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
currently `post.comments.find(Comment.first.id)` would load all
comments for the given post to set the inverse association.
This has a huge performance penalty. Because if post has 100k
records and all these 100k records would be loaded in memory
even though the comment id was supplied.
Fix is to use in-memory records only if loaded? is true. Otherwise
load the records using full sql.
Fixes #10509
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR https://github.com/rails/rails/pull/10566 had to be reverted
because after applying the fix test
"test_raise_record_not_found_error_when_invalid_ids_are_passed"
started failing.
In this test invalid_id is being assigned a really large number
which was causing following failure when PR #10566 was applied.
```
RangeError: bignum too big to convert into `long long'
SELECT `interests`.* FROM `interests`
WHERE `interests`.`man_id` = ? AND `interests`.`id` = ?
LIMIT 1 [["man_id", 970345987], ["id", 2394823094892348920348523452345]]
```
This test is not failing in master because when test code
`man.interests.find(invalid_id)` is executed then interests
are fully loaded in memory and no database query is executed.
After PR #10566 was merged then test code
`man.interests.find(invalid_id)` started executing sql query
and hence the error.
In case someone is wondering why the second part of query is not
failing, then that's because the actual query does not require
any variable substituation where the number is large. In that
case the sql generate is following.
```
SELECT `interests`.* FROM `interests`
WHERE `interests`.`man_id` = ? AND `interests`.`id`
IN (8432342, 2390102913, 2453245234523452) [["man_id", 970345987]]
```
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 2b817a5e89ac0e7aeb894a40ae7151a0cf3cef16, reversing
changes made to 353a398bee68c5ea99d76ac7601de0a5fef6f4a5.
Conflicts:
activerecord/CHANGELOG.md
Reason: the build broke
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
currently `post.comments.find(Comment.first.id)` would load all
comments for the given post to set the inverse association.
This has a huge performance penalty. Because if post has 100k
records and all these 100k records would be loaded in memory
even though the comment id was supplied.
Fix is to use in-memory records only if loaded? is true. Otherwise
load the records using full sql.
Fixes #10509
|
|\
| |
| | |
`CollectionProxy#include?` returns `true` and `false` as documented.
|
| | |
|
|\ \
| |/
|/| |
Fix test, addresss => address
|
| | |
|
|\ \
| | |
| | | |
wonderfull => wonderful
|
| | | |
|
|/ / |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
```
|
|
|
|
|
|
| |
the results. Added tests to check to make sure that inverse associations are
automatically found when has_many, has_one, or belongs_to associations
are defined.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
|
|\
| |
| | |
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
|
| |
| |
| |
| |
| | |
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/associations/preloader/through_association.rb
activerecord/test/cases/associations/eager_test.rb
|