Data integrity problems are among the most common database issues Rails developers face. Besides allowing for proper validation, correctly designed transaction blocks ensure that your data isn’t partially created or updated.
However, transactions can also harm your application — or even take down your whole database — when not properly designed.
This article offers a set of good practices for working with transactions. The tips are pretty simple, but they will help make your transactions bulletproof, readable, and relatively safe.
Let’s dive in!
1. Use Bang Methods in Rails When Possible
In Rails, method versions with
! can give you confidence that an error will be raised when something goes wrong.
For example, the
#save method also exists in the
save! version. You might want to use this version in the controller if you don’t want to raise any errors:
def create user = User.new(user_params) if user.save # redirect else render :new end end
The above approach won’t work well in transactions. By using
save, we can’t roll back the process when the error is raised. That’s why it is so important to use the
! version of the methods:
ActiveRecord::Base.transaction do user = User.create(user_attributes) user.memberships.create(membership_attributes) end
In the above, the transaction succeeds even if the membership record isn’t created, and we end up with a messed-up data structure in the database.
If you use the following version, the transaction reverts due to an
ActiveRecord::Base.transaction do user = User.create!(user_attributes) user.memberships.create!(membership_attributes) end
2. Handle Errors in Rails Transactions Properly
When it comes to errors in transactions, there are a few rules that you should respect. By following these rules, you’ll have readable and well-working code that will not create confusion among other developers or weird behavior that is hard to debug.
Do Not Rescue from
ActiveRecord::StatementInvalid is a special error raised when something on the database level goes wrong. Never rescue from this error. You should always be explicitly notified when something goes wrong with the database query.
Avoid the following code:
def perform_action(...) User.transaction do # perform transaction end rescue ActiveRecord::StatementInvalid # do something end
Use the Rescue on the Right Level
If you use rescue on the following level, you’ll catch the error:
User.transaction do user.perform_action! user.perform_another_action! rescue SomeError # rescue end
The transaction does not roll back because you caught the error. Let the error be raised and catch it outside the transaction block:
def some_method User.transaction do user.perform_action! user.perform_another_action! end rescue SomeError # rescue end
In the above approach, the transaction rolls back in case of an error, and you catch the error. This is the right approach to catch errors raised inside transactions without overwriting transaction behavior.
Do Not Catch Generic Errors
You should avoid catching generic errors like
ArgumentError. This is more like a general rule for readable and easily testable code, but it’s worth mentioning.
Catching these errors can make debugging harder, as other places in the code may raise the errors. This could silence some serious issues in your app that are not necessarily related to the place you rescue them.
Use ActiveRecord’s Default Rollback Error Wisely
ActiveRecord provides a particular error class that you can use inside a transaction to make a silent rollback. You roll back the transaction by raising the
ActiveRecord::Rollback error, but the error isn’t raised outside, as happens with other errors. Keep this behavior in mind and use it wisely.
3. Know When to Avoid Using Transactions in Rails
As with anything, you should not overuse transactions in your code. For example, a common mistake is to wrap only one query into your transaction. This does not make sense because, if the query doesn’t succeed, there is no need to roll back anything.
Another common mistake is to wrap code unrelated to your database call into a transaction. You should avoid such an approach, as the transaction will hold the connection unless the code inside the block executes. Limit the code inside the block to call only your database, if possible.
4. Understand the Disadvantages of Transactions
Transactions help maintain data integrity inside a database, but you should also be aware of their disadvantages. For example, queries wrapped in a transaction block take more DB resources than single queries.
Another drawback of using transactions is that it leads to more complex code. Transactions can make your code less readable when used incorrectly.
5. Use the Transaction Block in the Right Context
You can use the transaction method when a class inherits from the
ActiveRecord class. This does not mean that the version you use does not matter. Although it might not matter from a functional perspective, it matters in terms of ensuring your code is readable.
Three common versions use the transaction method:
ActiveRecord::Base.transaction Model.transaction Model.new.transaction
When you use many models and mix instance method invocations with classes inside a block, you should use
ActiveRecord::Base.transaction do attributes = user.prepare_attributes(account) membership = Membership.create(attributes) LogService.log_creation(user, membership) end
If you deal mostly with code that belongs to a given model, invoke the transaction method on a class:
User.transaction do user = User.create!(attributes) user.log_activity(‘creation’) end
When you operate on a model instance, it makes sense to invoke the transaction method on the instance level:
user.transaction do user.make_transaction(attributes) user.log_activity(‘transaction’) end
Of course, these rules are not official. They are just suggestions to make code more readable.
Next Steps: Review Transactions in Your Ruby on Rails Project
I hope you’ve found these tips for working with transactions in Ruby on Rails useful.
We’ve covered the importance of designing Rails transactions properly to improve data integrity and ensure that your processes perform without surprising side effects.
However, a proper error handling policy isn’t only beneficial when using transactions — it will also improve your whole codebase. Keep that in mind the next time you expect your code to throw some errors.
Now is an excellent time to review transactions in your Ruby on Rails project design to avoid errors. Design for efficient and reliable communication with your database to make your application more stable.
P.S. If you’d like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!