| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
was using nullify strategy
This caused a regression in applications trying to upgrade.
Also if the user set the dependent option as destroy he expects to get
the records removed from the database.
|
| |
|
|
|
|
| |
broken
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to build associated records for owners which has not been saved
need to get where values to use as default attributes.
But for new record owner uses `ActiveRecord::NullRelation` which
override `where_values_hash` to return empty hash stub.
`where_values_hash` is not used to invoke any sql query, but good to
build others chains (even will be never executed) like:
```ruby
post = Post.new
admin_comment = post.admin_comments.build
assert_equal 'Admin', admin_comment.author
```
Closes #11376, #11676, #11675
|
|
|
|
| |
.find([1]) should return an Array of entries, even when a invese object is in memory already
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When first or last is called with an integer on an unloaded association,
the entire collection is loaded. This differs surprisingly from the
behavior of Relation#first/last, which translate the call into a limit
query. For large collections this can make a big difference in
performance.
Change CollectionAssociation#fetch_first_or_last_using_find? to make
this kind of call delegate to Relation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
|
| |
|
|
|
|
| |
Closes #11026
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 primary key on an association will make sure that the corresponding
counter on the association is changed properly. Fixes #9722.
|
| |
|
|
|
|
| |
closes #9201
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
because of an ambiguous column name. This happened if the association
model had a default scope that referenced a third table, and the third
table also referenced the original table (with an identical
foreign_key).
Mysql requires that ambiguous columns are deambiguated by using the full
table.column syntax. Postgresql and Sqlite use a different syntax for
updates altogether (and don't tolerate table.name syntax), so the fix
requires always including the full table.column and discarding it later
for Sqlite and Postgresql.
|
|
|
|
|
| |
This reverts commit 637a7d9d357a0f3f725b0548282ca8c5e7d4af4a, reversing
changes made to 5937bd02dee112646469848d7fe8a8bfcef5b4c1.
|
|\
| |
| | |
Replace deprecated find_by_* with find_by
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Suggested by @dhh.
It doesn't affect the generated SQL, so seems reasonable to continue to
allow it as an association option.
|
| |
| |
| |
| | |
Fixes #8795
|
|/ |
|
|
|
|
| |
This test does not belong to has many associations test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider this scenario:
if params[:foo]
conditions = { foo: true }
end
foos = Foo.where(conditions).order(:id)
When params[:foo] is nil, this would call:
foos = Foo.where(nil).order(:id)
In this scenario, we want Foo.where(conditions) to be the same as calling
Foo.all, otherwise we'd get a "NoMethodError order for WhereChain".
Related to #8332.
|
|\
| |
| |
| |
| |
| |
| |
| | |
Relation.where with no args can be chained with not, like, and not_like
Conflicts:
activerecord/CHANGELOG.md
activerecord/lib/active_record/relation/query_methods.rb
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
examples:
Model.where.not field: nil
#=> "SELECT * FROM models WHERE field IS NOT NULL
Model.where.like name: 'Jeremy%'
#=> "SELECT * FROM models WHERE name LIKE 'Jeremy%'
this feature was originally suggested by Jeremy Kemper https://github.com/rails/rails/pull/5950#issuecomment-5591330
Closes #5950
|
| | |
|
|/
|
|
|
|
|
|
| |
Allows you to do BaseClass.new(:type => "SubClass") as well as
parent.children.build(:type => "SubClass") or parent.build_child
to initialize an STI subclass. Ensures that the class name is a
valid class and that it is in the ancestors of the super class
that the association is expecting.
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
prevent mass assignment of polymorphic type when using `build`
Conflicts:
activerecord/CHANGELOG.md
|
| |
| |
| |
| | |
Closes #8265
|
|/
|
|
|
|
|
| |
To perform a sum calculation over the array of elements, use to_a.sum(&block).
Please check the discussion in f9cb645dfcb5cc89f59d2f8b58a019486c828c73
for more context.
|
|
|
|
| |
See issue #7950.
|
| |
|
|\
| |
| | |
:counter_cache option for to support custom named counter caches
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
So that the scope may be a NullRelation and return a result without
executing a query.
Fixes #7928
|
| |
| |
| |
| |
| |
| |
| | |
Fixes #8102.
I couldn't find a nicer way to deal with this than delegate the call to
#scope, which will be a NullRelation when we want it to be.
|
|/
|
|
|
|
|
|
|
|
| |
null relations
For example, the following should not run any query on the database:
Post.new.comments.where(body: 'omg').to_a # => []
Fixes #5215.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patches `CollectionAssociation#count` to return 0 without querying
if the parent record is new. Consider the following code:
class Account
has_many :dossiers
end
class Dossier
belongs_to :account
end
a = Account.new
a.dossiers.build
# before patch
a.dossiers.count
# SELECT COUNT(*) FROM "dossiers" WHERE "dossiers"."account_id" IS NULL
# => 0
# after
a.dosiers.count # fires without sql query
# => 0
Fixes #1856.
|