Ecto's uniqueness constraint vs Rails' uniqueness validation
I really like how closely Ecto integrates with our database. That was a surprising difference when I first came from Rails.
Ecto’s constraints are a great example of that. Like Rails, Ecto has validations. But unlike Rails, Ecto also has constraints. Validating uniqueness is the example that most easily comes to my mind.
Rails uniqueness validation
validates that the attribute’s value is unique right before the object gets saved.
class Account < ApplicationRecord
validates :email, uniqueness: true
class Account < ApplicationRecord
But as the Rails guides state:
It does not create a uniqueness constraint in the database, so it may happen that two different database connections create two records with the same value for a column that you intend to be unique.
Because the validation happens before records are inserted into the database, we always have the possibility of a race condition — for example, if one user quickly submits the same form twice or two users submit the form at the same time.
The Rails guides go on to suggest a solution:
To avoid that, you must create a unique index on that column in your database.
Unfortunately, Rails does nothing out of the box when the database’s unique index raises an error:
You can either choose to let this error propagate (which will result in the default Rails exception page being shown), or you can catch it and restart the transaction
So, even though Rails suggests using a unique index at the database level to ensure data integrity, we have to roll our own exception-catching and error-handling if we want a good experience for our users.
Ecto’s uniqueness constraint
Ecto also allows us to validate the uniqueness of an attribute through unique_constraint/3:
def changeset(account, params) do
|> cast(params, [:email])
But unlike Rails’ uniqueness validation, Ecto’s
we create a unique index in our database:
to use the uniqueness constraint, the first step is to define the unique index in a migration
Then, Ecto integrates with it, rescuing the exception and turning it into a nice error for our users:
The unique constraint works by relying on the database to check if the unique constraint has been violated or not and, if so, Ecto converts it into a changeset error.
So, both Rails and Ecto recommend creating a unique index in our database for data integrity. But only Ecto takes an extra step and integrates with the database, turning the exception into a nice error message for our users – blending the strengths of our application with those of our database.
Ecto’s unsafe validations
Of course, the downside of relying on a database constraint is that we do not know if the record is unique until we try to insert it into the database. And there are times when we want to validate a record’s uniqueness (subject to race conditions) before we have to persist it. For those situations, Ecto has a function called unsafe_validate_unique/4.
By explicitly labeling the function as “unsafe”, Ecto suggests that we shouldn’t
trust it for data integrity. The function can help as a first layer of errors
for our customers, but ultimately, we should rely on the
This function exists to provide quick feedback to users of your application. It should not be relied on for any data guarantee as it has race conditions and is inherently unsafe. For example, if this check happens twice in the same time interval (because the user submitted a form twice), both checks may pass and you may end-up with duplicate entries in the database. Therefore, a unique_constraint/3 should also be used to ensure your data won’t get corrupted
Thus, by integrating more closely with the database, Ecto offers the best of both worlds: data integrity as the recommended default, and an unsafe way to get quick feedback when needed.