I’ve found myself implementing a similar function for forms that require multiple constraints, especially when a database transaction is needed to insert data across more than one table. The requirements were that the forms need to work without JavaScript, so using AJAX wasn’t an option. I’d like to share my experiences with it.
For a practical example, let’s take a look at the use case in @josevalim’s schemaless query blog post under the Schemas are Mappers section. We have a Registration form that splits data between a Profile and an Account. Let’s say that the profile schema also has a username that needs to be unique. If the email and the username turned out to be taken already, it would be nice to show the user both errors at once instead of making them submit the form twice.
I’m making the following function up off the top of my head, so please excuse any errors or inefficiency in it, but the idea for a function that validates uniqueness would be along the lines of the following:
defp validate_unique_email(%Ecto.Changeset{} = changeset, options \\ [])
when is_list(options) do
if changeset.errors[:email] do
changeset
else
if is_email_unique?(changeset.changes.email) do
changeset
else
put_unique_validation_error(changeset, :email, options)
end
end
end
Keep in mind, the changeset has already been validated before entering this function; it is local to the registration module. If there is already an existing error on the email field, the database call is bypassed. If there is no pre-existing error, the is_email_unique? function hits the database returns a boolean about whether or not the email already exists. If the email is unique, the changeset is simply passed along. If the email already exists, the utility function put_unique_validation_error adds the validation error to the changeset (passing along the options, such as options[:message]). The username would go through a similar process.
Since there are a couple times uniqueness is validated, the put_unique_constraint_error function is generalized to allow developers to easily add unique constraint violations to the changeset. (Speaking of, there is no error information added to unique constraints in Ecto outside of the messages at the moment. For example, a length validation error adds [validation: :length] to the error. It might be a good idea to add something like [constraint: :unique] or [constraint: :foreign_key] for when the constraints fail.)
After that, when the data is actually inserted into the database, both fields still have the unique_constraint placed on both of them before being inserted. This prevents any sort of race from happening.
This is a rare use case, but one I found myself needing. It would be nice to have it built into Ecto, but I agree that it should stay outside of Changeset. If there’s only a single constraint, the normal constraints more than suffice.
Edit: I do want to say that adding this functionality to my application was trivial. There were only two separate cases where it was needed, and the context was bound within the module responsible for that particular form. Because of that, it was very clear that this check was hitting the database to do the validation. The ease of implementation and clarity of action could be used to argue that the functionality doesn’t really need to be added since it’s such an edge case. If it were to be added, I see Jose’s recommendation of adding it as something called unsafe_validate_unique as a good middle ground.
