| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #12812
Raise `ActiveRecord::RecordNotDestroyed` when a child marked with
`dependent: destroy` can't be destroyed.
The following code:
```ruby
class Post < ActiveRecord::Base
has_many :comments, dependent: :destroy
end
class Comment < ActiveRecord::Base
before_destroy do
return false
end
end
post = Post.create!(comments: [Comment.create!])
post.comments = [Comment.create!]
````
would result in a `post` with two `comments`.
With this commit, the same code would raise a `RecordNotDestroyed`
exception, keeping the `post` with the same `comment`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm pretty confused about the addition of this method. The documentation
says that it was intended to allow the removal of values from the
default scope (in contrast to #except). However it behaves exactly the
same as except: https://gist.github.com/jonleighton/7537008 (other than
having a slightly enhanced syntax).
The removal of the default scope is allowed by
94924dc32baf78f13e289172534c2e71c9c8cade, which was not a change we
could make until 4.1 due to the need to deprecate things. However after
that change #unscope still gives us nothing that #except doesn't already
give us.
However there *is* a desire to be able to unscope stuff in a way that
persists across merges, which would allow associations to be defined
which unscope stuff from the default scope of the associated model. E.g.
has_many :comments, -> { unscope where: :trashed }
So that's what this change implements. I've also corrected the
documentation. I removed the guide references to #except as I think
unscope really supercedes #except now.
While we're here, there's also a potential desire to be able to write
this:
has_many :comments, -> { unscoped }
However, it doesn't make sense and would not be straightforward to
implement. While with #unscope we're specifying exactly what we want to
be removed from the relation, with "unscoped" we're just saying that we
want it to not have some things which were added earlier on by the
default scope. However in the case of an association, we surely don't
want *all* conditions to be removed, otherwise the above would just
become "SELECT * FROM comments" with no foreign key constraint.
To make the above work, we'd have to somehow tag the relation values
which get added when evaluating the default scope in order to
differentiate them from other relation values. Which is way too much
complexity and therefore not worth it when most use cases can be
satisfied with unscope.
Closes #10643, #11061.
|
| |
|
|
| |
automatically
|
| |
|
|
|
|
|
|
|
| |
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
|
