I’ve not used it myself, but the tarams library looks like it might handle your use case if you want to go with a library instead of a custom solution GitHub - bluzky/tarams: Cast and validate external data and request parameters for Elixir and Phoenix · GitHub
riebeekn
fceruti
Thanks! This seems to be exactly what I was looking for. I’ll test it and possibly mark it as the solution. The quest of building/understanding this was an interesting one thou.
0
ityonemo
if you want to use something more standards-compliant, I have this library which does compile-time generation of strictly validation functions from Jsonschemas:
It doesn’t normalize your parameters, though, so if you need a translation layer between things with different “names” (e.g. camelCase → snake_case) you might have to cook up something on your own. We do this at work with a “Codec” module which I may do a webcast on sometime.
With Ecto, though, you can just peddle in strings and it figures out the pesky strings/atoms stuff for you.
0
sasajuric
Author of Elixir In Action
IMO, the thing we’re validating is the input itself. In the simplest case (which is in my experience also the most frequent one), we can do most of the validations before even hitting the database, so that’s simple. Occasionally I may need to hit the database to validate some constraint (most often uniqueness). In most cases I’ve had this is also simple, since the field being validated usually directly corresponds to the input field. Combining these two, in most cases all I needed was a single validation+store changeset where all possible field errors corresponded to the input fields.
I can’t recall a single situation where this didn’t fit the bill, but vaguely speaking the options I’d consider in such cases would be:
- Separate input validation changeset from db store, performing most of validations on the input.
- On db store error, take the errors, change the keys if needed (e.g. replace db field
:foowith input field:bar).
It would help if you had some specific situation in mind, then we could discuss it.
0
IvanR
If you are up to a declarative approach and dependency inversion towards your application core’s data types, you can use Domo library. That generates validators and constructor functions from a t() type spec of the struct, and the type spec is validated for syntax correctness by elixir during the compilation.
So the request can be accepted into the struct that looks like the following:
defmodule Request do
use Domo, ensure_struct_defaults: false
defstruct [:email, :password, :date_of_birth]
@type t :: %__MODULE__{
email: email(),
password: password(),
date_of_birth: Date.t() | nil
}
@type email :: String.t()
precond email: &String.match?(&1, ~r|.+\@.+\..+|)
@type password :: String.t()
precond password: &String.length(&1) > 7
# Domo adds new/1, new!/1, ensure_type/1, ensure_type!/1 here automatically
end
And the validation can be done like that:
iex(1)> Request.new(%{email: "user@test.com", password: "some_password"})
{:ok, %Request{date_of_birth: nil, email: "user@test.com", password: "some_password"}}
iex(2)> Request.new(%{email: "usertestcom", date_of_birth: "none"})
{:error,
[
password: "Invalid value nil for field :password of %Request{}. Expected the value matching the <<_::_*8>> type.",
email: "Invalid value \"usertestcom\" for field :email of %Request{}. Expected the value matching the <<_::_*8>> type. And a true value from the precondition function \"&String.match?(&1, ~r|.+\\\\@.+\\\\..+|)\" defined for Request.email() type.",
date_of_birth: "Invalid value \"none\" for field :date_of_birth of %Request{}. Expected the value matching the %Date{} | nil type."
]}
The dependency inversion can be done by sharing email() and password() in the shared module to have the same rules for emails and passwords across the whole app.
Domo plays nicely with Ecto schemas because they are structs too. See Domo.Changeset for this kind of integration.
0