When you generate a new schema in a Phoenix project, you will get something like this:

defmodule MyApp.Accounts.User do
  use Ecto.Schema
  import Ecto.Changeset
  schema "users" do
    field :email, :string
    field :favorite_color, :string
    field :name, :string
    field :total_pets, :integer
    timestamps()
  end
  @doc false
  def changeset(user, attrs) do
    user
    |> cast(attrs, [:email, :name, :favorite_color, :total_pets])
    |> validate_required([:email, :name])
    |> unique_constraint(:email)
  end
end

The fields favorite_color and total_pets have been removed from validate_required because our users can sign up without divulging that information. They are optional fields. In this fictional application, all we require is their email and name.

This code is fine, but there’s a little redundancy in the changeset function. The email and name fields are repeated in cast and validate_required. Usually, you need to cast a field before it can be required. Also, it’s not immediately obvious that favorite_color and total_pets are optional. You need to compare the casted fields with the required fields.

That isn’t a problem when you only have 4 fields, but in a schema with 20 fields, it’s a mess.

I like to write schemas like this:

defmodule MyApp.Accounts.User do
  use Ecto.Schema
  import Ecto.Changeset
  @required_fields ~w(email name)a
  @optional_fields ~w(favorite_color total_pets)a
  schema "users" do
    field :email, :string
    field :favorite_color, :string
    field :name, :string
    field :total_pets, :integer
    timestamps()
  end
  @doc false
  def changeset(user, attrs) do
    user
    |> cast(attrs, @required_fields ++ @optional_fields)
    |> validate_required(@required_fields)
    |> unique_constraint(:email)
  end
end

Now it’s explicit which fields are optional vs required and they’re listed clearly at the top of the module.