Validating constructor pattern?

mbuhot

Is there a convention/idiom for defining structs that require validation on construction?

I notice the standard library types Date and Time define a new function that returns an error tuple when the inputs are invalid:

iex> Date.new(0,0,0)
{:error, :invalid_date}

Is there any downside to declaring structs as ecto embedded_schema with a new/1 function that returns an error tuple? eg:

defmodule MyStruct do
  use Ecto.Schema
  alias Ecto.Changeset

  @primary_key false
  embedded_schema do 
    field :a, :integer
    field :b, :string
  end

  def new(attrs) do
    case cs = changeset(%MyStruct{}, attrs) do
      %{valid?: true} -> {:ok, Changeset.apply_changes(cs)}
      _ -> {:error, changeset_errors(cs)}
    end
  end

  defp changeset(data = %MyStruct{}, attrs) do
    data
    |> Changeset.cast(attrs, [:a, :b])
    |> Changset.validate_required([:a, :b])
    |> Changeset.validate_format(:b, ~r/@/)
  end

  defp changeset_errors(changeset) do
    Changeset.traverse_errors(changeset, fn {msg, opts} ->
      Enum.reduce(opts, msg, fn {key, value}, acc ->
        String.replace(acc, "%{#{key}}", to_string(value))
      end)
    end)
  end
end

5 comments

#ecto #structs #validation

0 2500 5

2017-05-20 11:34:54 UTC

Showing Posts 1 to 5

Show Best Posts
Show All (oldest first)
Show All (newest first)

Qqwy

TypeCheck Core Team

Indeed, using a new function, combined with declaring the struct’s type as @opaque (as hint that people should not construct it directly and in many cases not pattern match on it directly either) is the convention that is used for this. As for the return value in case of an error, there is no convention for this, (I have seen all of %MyStruct{} | nil, %MyStruct{} | {:error, reason} and {:ok, %MyStruct{}} | {:error, reason}; I like the third the most myself, but it depends on the situation).

As for the example with the Ecto changeset: I am not sure this is the proper way. It feels like you are partially re-inventing the logic that changesets themselves provide, but I am not immediately sure how to improve on it.

It feels more natural to me to have MyStruct.new() return a version of the struct with sensible default values (without any filled in ‘attrs’) and explicitly fill in the changeset with attrs at the place where you use it, i.e:

defmodule MyStructContext do
  def create_mystruct(attrs) do
    MyStruct.new
    |> creation_changeset(attrs)
    |> Repo.insert()
  end

  def creation_changeset(mystruct = %MyStruct, attrs) do
    mystruct
    |> MyStruct.common_changeset(attrs) # Ensures that invariants of MyStruct are never invalidated.
    |> Changeset.cast(attrs, [:someting, :only_applicable_on_creation])
    |> Changeset.validate_required([:something, :only_applicable_on_creation])
  end
end

Post #1

mbuhot

Thanks @Qqwy !

I’m not so much concerned with structs that will be used with a Repo, as %Changeset{} or %Multi{} works really well in those cases.

But for cases where you might otherwise use defstruct, is embedded_schema a suitable alternative, for the convenience of Changeset.cast and Changeset.validate_* functions?

Post #2

ashneyderman

you can use straight maps with Changeset. If you need to validate you can always validate a map and create struct from the map afterwards.

Post #3

mbuhot

Thats neat!

However I like the idea of making structs composable with embeds_one / embeds_many which I don’t think is supported with schemaless changesets?

Post #4

ashneyderman

I use validate_change for the embedded maps, which takes function as validator. This way you can compose validations pretty much for any imaginable structure.

Post #5

— All posts loaded —