| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`touch` option was added to `increment!` (#27660) and `update_counters`
(#26995). But that option behaves inconsistently with
`Persistence#touch` method.
If `touch` option is passed attribute names, it won't update
update_at/on attributes unlike `Persistence#touch` method.
Due to changed from `Persistence#touch` to `increment!` with `touch`
option, #31405 has a regression that `counter_cache` with `touch` option
which is passed attribute names won't update update_at/on attributes.
I think that the inconsistency is not intended. To get back consistency,
ensure that `touch` option updates update_at/on attributes.
|
| | |
|
| |
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| | |
|
| | |
|
| |
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
different types.
When passing in an array of different types of objects to `where`, it would only take into account the class of the first object in the array.
PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)])
# => SELECT "price_estimates".* FROM "price_estimates"
WHERE ("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" IN (1, 2))
This is fixed to properly look for any records matching both type and id:
PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)])
# => SELECT "price_estimates".* FROM "price_estimates"
WHERE (("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" = 1)
OR ("price_estimates"."estimate_of_type" = 'Car' AND "price_estimates"."estimate_of_id" = 2))
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
initialize_attributes
If argument of `build_record` has key and value which is same as
default value of database, we should also except the key from
`create_scope` in `initialize_attributes`.
Because at first `build_record` initialize record object with argument
of `build_record`, then assign attributes derived from Association's scope.
In this case `record.changed` does not include the key, which value is
same as default value of database, so we should add the key to except list.
Fix #21893.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we made sure that the counter gets updated in memory, we only did
it on the has many side. The has many side only does the update if the
belongs to cannot. The belongs to side was updated to update the counter
cache (if it is able). This means that we need to check if the
belongs_to is able to update in memory on the has_many side.
We also found an inconsistency where the reflection names were used to
grab the association which should update the counter cache. Since
reflection names are now strings, this means it was using a different
instance than the one which would have the inverse instance set.
Fixes #18689
[Sean Griffin & anthonynavarre]
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
This reverts commit 70d6e16fbad75b89dd1798ed697e7732b8606fa3, reversing
changes made to ea4db3bc078fb3093ecdddffdf4f2f4ff3e1e8f9.
Seems to be a code merge done by mistake.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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)`
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
destoyed without catching the ActiveRecord::StaleObjectError.
|
| |
|
|
| |
HasManyAssociation#inverse_updates_counter_cache?. Fixes #2755, where a counter cache could be decremented twice as far as it was supposed to be.
|
| |
|
|
| |
association conditions on singular associations. Fixes #481 (again).
|
| |
|
|
| |
be assigned without mass-assignment protection when a record is built on the association.
|
| |
|
|
| |
macro multiple times that will give deprecation warnings, and in 3.2 we will simply overwrite the default scope when you call the macro multiple times.
|
| |
|
|
| |
favour of defining a 'default_scope' class method in the model. See the CHANGELOG for more details.
|
| |
|
|
|
|
|
|
|
| |
while declaring default_scope
Also added test for unscoped using block style with four different
combinations
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
order that is declared first has highest priority in all cases.
Here are some examples.
Car.order('name desc').find(:first, :order => 'id').name
Car.named_scope_with_order.named_scope_with_another_order
Car.order('id DESC').scoping do
Car.find(:first, :order => 'id asc')
end
No special treatment to with_scope or scoping.
Also note that if default_scope declares an order then the order
declared in default_scope has the highest priority unless
with_exclusive_scope is used.
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
child should be respected.
author.posts.create should take into account default_scope
defined on post.
[#3939: state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
belongs_to
[#4984 state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
