aboutsummaryrefslogtreecommitdiffstats
path: root/guides/source/active_record_callbacks.md
diff options
context:
space:
mode:
Diffstat (limited to 'guides/source/active_record_callbacks.md')
-rw-r--r--guides/source/active_record_callbacks.md62
1 files changed, 54 insertions, 8 deletions
diff --git a/guides/source/active_record_callbacks.md b/guides/source/active_record_callbacks.md
index 379c0925b5..8f54e78224 100644
--- a/guides/source/active_record_callbacks.md
+++ b/guides/source/active_record_callbacks.md
@@ -1,4 +1,4 @@
-**DO NOT READ THIS FILE ON GITHUB, GUIDES ARE PUBLISHED ON http://guides.rubyonrails.org.**
+**DO NOT READ THIS FILE ON GITHUB, GUIDES ARE PUBLISHED ON https://guides.rubyonrails.org.**
Active Record Callbacks
=======================
@@ -239,13 +239,12 @@ Skipping Callbacks
Just as with validations, it is also possible to skip callbacks by using the following methods:
-* `decrement`
+* `decrement!`
* `decrement_counter`
* `delete`
* `delete_all`
-* `increment`
+* `increment!`
* `increment_counter`
-* `toggle`
* `update_column`
* `update_columns`
* `update_all`
@@ -310,7 +309,7 @@ end
### Using `:if` and `:unless` with a `Proc`
-Finally, it is possible to associate `:if` and `:unless` with a `Proc` object. This option is best suited when writing short validation methods, usually one-liners:
+It is possible to associate `:if` and `:unless` with a `Proc` object. This option is best suited when writing short validation methods, usually one-liners:
```ruby
class Order < ApplicationRecord
@@ -319,6 +318,14 @@ class Order < ApplicationRecord
end
```
+As the proc is evaluated in the context of the object, it is also possible to write this as:
+
+```ruby
+class Order < ApplicationRecord
+ before_save :normalize_card_number, if: Proc.new { paid_with_card? }
+end
+```
+
### Multiple Conditions for Callbacks
When writing conditional callbacks, it is possible to mix both `:if` and `:unless` in the same callback declaration:
@@ -330,6 +337,20 @@ class Comment < ApplicationRecord
end
```
+### Combining Callback Conditions
+
+When multiple conditions define whether or not a callback should happen, an `Array` can be used. Moreover, you can apply both `:if` and `:unless` to the same callback.
+
+```ruby
+class Comment < ApplicationRecord
+ after_create :send_email_to_author,
+ if: [Proc.new { |c| c.user.allow_send_email? }, :author_wants_emails?],
+ unless: Proc.new { |c| c.article.ignore_comments? }
+end
+```
+
+The callback only runs when all the `:if` conditions and none of the `:unless` conditions are evaluated to `true`.
+
Callback Classes
----------------
@@ -427,7 +448,9 @@ class PictureFile < ApplicationRecord
end
```
-WARNING. The `after_commit` and `after_rollback` callbacks are called for all models created, updated, or destroyed within a transaction block. However, if an exception is raised within one of these callbacks, the exception will bubble up and any remaining `after_commit` or `after_rollback` methods will _not_ be executed. As such, if your callback code could raise an exception, you'll need to rescue it and handle it within the callback in order to allow other callbacks to run.
+WARNING. When a transaction completes, the `after_commit` or `after_rollback` callbacks are called for all models created, updated, or destroyed within that transaction. However, if an exception is raised within one of these callbacks, the exception will bubble up and any remaining `after_commit` or `after_rollback` methods will _not_ be executed. As such, if your callback code could raise an exception, you'll need to rescue it and handle it within the callback in order to allow other callbacks to run.
+
+WARNING. The code executed within `after_commit` or `after_rollback` callbacks is itself not enclosed within a transaction.
WARNING. Using both `after_create_commit` and `after_update_commit` in the same model will only allow the last callback defined to take effect, and will override all others.
@@ -450,10 +473,33 @@ end
=> User was saved to database
```
-To register callbacks for both create and update actions, use `after_commit` instead.
+There is also an alias for using the `after_commit` callback for both create and update together:
+
+* `after_save_commit`
+
+```ruby
+class User < ApplicationRecord
+ after_save_commit :log_user_saved_to_db
+
+ private
+ def log_user_saved_to_db
+ puts 'User was saved to database'
+ end
+end
+
+# creating a User
+>> @user = User.create
+=> User was saved to database
+
+# updating @user
+>> @user.save
+=> User was saved to database
+```
+
+To register callbacks for both create and destroy actions, use `after_commit` instead.
```ruby
class User < ApplicationRecord
- after_commit :log_user_saved_to_db, on: [:create, :update]
+ after_commit :log_user_saved_to_db, on: [:create, :destroy]
end
```