Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Move new warning after example of previous warning [ci-skip] #49884

Merged
merged 1 commit into from Nov 1, 2023
Merged

Move new warning after example of previous warning [ci-skip] #49884

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
24 changes: 12 additions & 12 deletions guides/source/active_record_callbacks.md
View file
Open in desktop
Expand Up @@ -554,18 +554,6 @@ WARNING. The code executed within `after_commit` or `after_rollback` callbacks i

WARNING. Using both `after_create_commit` and `after_update_commit` with the same method name will only allow the last callback defined to take effect, as they both internally alias to `after_commit` which overrides previously defined callbacks with the same method name.

WARNING. In the context of a single transaction, if you interact with multiple
loaded objects that represent the same record in the database, there's a crucial
behavior in the `after_commit` and `after_rollback` callbacks to note. These
callbacks are triggered only for the first object of the specific record that
undergoes a change within the transaction. Other loaded objects, despite
representing the same database record, will not have their respective
`after_commit` or `after_rollback` callbacks triggered. This nuanced behavior is
particularly impactful in scenarios where you expect independent callback
execution for each object associated with the same database record. It can
influence the flow and predictability of callback sequences, leading to potential
inconsistencies in application logic following the transaction.

```ruby
class User < ApplicationRecord
after_create_commit :log_user_saved_to_db
Expand All @@ -585,6 +573,18 @@ irb> @user.save # updating @user
User was saved to database
```

WARNING. In the context of a single transaction, if you interact with multiple
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is maybe for another PR, but I find these huge walls of text (especially in a note/warning block) with no sample code to be difficult to catch.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree.

loaded objects that represent the same record in the database, there's a crucial
behavior in the `after_commit` and `after_rollback` callbacks to note. These
callbacks are triggered only for the first object of the specific record that
undergoes a change within the transaction. Other loaded objects, despite
representing the same database record, will not have their respective
`after_commit` or `after_rollback` callbacks triggered. This nuanced behavior is
particularly impactful in scenarios where you expect independent callback
execution for each object associated with the same database record. It can
influence the flow and predictability of callback sequences, leading to potential
inconsistencies in application logic following the transaction.

### `after_save_commit`

There is also [`after_save_commit`][], which is an alias for using the `after_commit` callback for both create and update together:
Expand Down