So, just to be clear, you’re saying it’s not a bug that validate_email_changed() is only executed in applications where the email should be unique?
In my head, these validate_[attribute] methods are simply validating that the value conforms to specific characteristics, like these:
- It’s required (or not)
- It has a certain minimum (and maximum?) length
- It conforms to a certain pattern
- It’s unique (based on the application)
- It’s one of a list of possible values
In my head (and based on my 34 years of programming experience), the fact that a value has to change from some other value in order to be valid, makes no sense. That’s not at all like the things listed above. To me, this check doesn’t belong inside the validation routine, it belongs alongside it. This way, I can reuse the validate_email() method in some other form, where a person’s email might change, but won’t be flagged if it’s not changed. But that’s just me. What do I know? Apparently, I need more training in this new form of logic.
Someone tell me why this wouldn’t work. I’m not in a position to test it myself.
def email_changeset(user, attrs, opts \\ []) do
user
|> cast(attrs, [:email])
|> validate_email(opts)
|> validate_email_changed()
end
