aboutsummaryrefslogtreecommitdiffstats
path: root/railties/lib/rails/welcome_controller.rb
diff options
context:
space:
mode:
authorRyuta Kamizono <kamipo@gmail.com>2018-08-08 06:35:13 +0900
committerRyuta Kamizono <kamipo@gmail.com>2018-09-19 05:29:21 +0900
commitfe929c171966c6102452f3612c613a245a5e8bb7 (patch)
treef5f6f30b7ff9d222b2a36b1d906494ca226a91ba /railties/lib/rails/welcome_controller.rb
parent1b90f614b1b3d06b7f02a8b9ea6cd84f15d58643 (diff)
downloadrails-fe929c171966c6102452f3612c613a245a5e8bb7.tar.gz
rails-fe929c171966c6102452f3612c613a245a5e8bb7.tar.bz2
rails-fe929c171966c6102452f3612c613a245a5e8bb7.zip
Don't update counter cache unless the record is actually saved
This is a 4th attempt to make counter cache transactional completely. Past attempts: #9236, #14849, #23357. All existing counter cache issues (increment/decrement twice, lost increment) are caused due to updating counter cache on the outside of the record saving transaction by assigning belongs_to record, even though assigning that doesn't cause the record saving. We have the `@_after_replace_counter_called` guard condition to mitigate double increment/decrement issues, but we can't completely prevent that inconsistency as long as updating counter cache on the outside of the transaction, since saving the record is not always happened after that. We already have handling counter cache after create/update/destroy, https://github.com/rails/rails/blob/1b90f614b1b3d06b7f02a8b9ea6cd84f15d58643/activerecord/lib/active_record/counter_cache.rb#L162-L189 https://github.com/rails/rails/blob/1b90f614b1b3d06b7f02a8b9ea6cd84f15d58643/activerecord/lib/active_record/associations/builder/belongs_to.rb#L33-L59 so just removing assigning logic on the belongs_to association makes counter cache transactional completely. Closes #14849. Closes #23357. Closes #31493. Closes #31494. Closes #32372. Closes #33113. Closes #33117 Closes #33129. Closes #33458.
Diffstat (limited to 'railties/lib/rails/welcome_controller.rb')
0 files changed, 0 insertions, 0 deletions