Where to write custom changeset validation functions which rely on current database values / records?

acrolink

Here is an example of a custom validation:

@our_url "https://our-bucket.s3.amazon.com"
def changeset(struct, params \\ %{}) do
  struct
  |> cast(params, @required_fields)
  |> validate_required(@required_fields)
  |> validate_from_s3_bucket(:url)
end
def validate_from_s3_bucket(changeset, field, options \\ []) do
  validate_change(changeset, field, fn _, url ->
    case String.starts_with?(url, @our_url) do
      true -> []
      false -> [{field, options[:message] || "Unexpected URL"}]
    end
  end)
end

This can be written in the schema definition file. But where to write custom changeset validation functions which test database tables (of other models) for certain values and based on that data flag the transaction as valid or not? I guess making Ecto queries for B inside schema definition of A is not the correct way to do it. Any ideas? Thank you.

Example / Clarification

I have this in my schema definition:

  def changeset(record, attrs) do
    record
    |> cast(attrs, [:issued_at, :due_for_return, :returned_at, :fee, :fee_paid_at, :book_id])
    |> validate_required([])
    |> validate_book(:book_id)
  end


  defp validate_book(changeset, field) do
    case changeset.valid? do
      true ->
        book_id = get_field(changeset, field)
        case  Repo.get(Mango.Books.Book, book_id) do
          nil -> add_error(changeset, :book_id, "Book not found..")
          book -> {:ok, book}
            case book.status do
              :available -> changeset
              _ -> add_error(changeset, :book_id, "Book is already out..")
            end
        end
      _ ->
        changeset
    end
  end

As you can see I am doing some Repo query validation against some other model (books). My question is this the place do this or should I move all of this outside of my schema definition?

4 comments

/phoenix #ecto #changesets #validation

1 7010 4

2019-04-08 14:35:53 UTC

Showing Posts 1 to 4

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

idi527

I usually avoid making request to a database inside changesets. Instead, I use more explicit multis or transactions. So your second example I would write as:

  def changeset(record, attrs) do
    cast(record, attrs, [:issued_at, :due_for_return, :returned_at, :fee, :fee_paid_at])
  end

  defp valid_book_multi(multi, book_id) do
    alias Ecto.Multi
     
    Multi.run(multi, :book, fn _changes -> 
       case Book.get(book_id) do
          %Book{status: :available} = available_book -> {:ok, available_book}
          %Book{status: status} = not_available_book -> {:error, Book.error_msg(:status, status)}
          nil -> {:error, :not_found}
       end
    end)
  end

  @spec create_record(%{(String.t | atom) => term}, book_id: pos_integer) :: {:ok, %Record{}} | {:error, Ecto.Changeset.t}
  def create_record(attrs, book_id: book_id) do
    alias Ecto.Multi

   record_changeset = changeset(%Record{book_id: book_id}, attrs)

    Multi.new()
    |> valid_book_multi(book_id)
    |> Multi.insert(:record, record_changeset)
    |> Repo.transaction()
    |> case do
      {:ok, %{record: record}} -> {:ok, record}
      {:error, :book, reason, _changes} -> # collect errors into record changesets
    end
  end

Post #1

jeremyjh

Changeset validation functions should be limited to pure functions that use the data available to them in the Changeset and arguments you pass. They are not “models”. Business rules that require data access, messaging etc should be implemented in another module - if you are using Phoenix it would be a context module - but regardless its just a module with functions.

Post #2

Laetitia

What about using Ecto.Changeset.prepare_changes ?

Provides a function to run before emitting changes to the repository.

Such function receives the changeset and must return a changeset, allowing developers to do final adjustments to the changeset or to issue data consistency commands.

The given function is guaranteed to run inside the same transaction as the changeset operation for databases that do support transactions.

I will run some validation and returns an invalid changeset if it failed.

Post #3

pierreabreup

@Laetitia Changeset.prepare_changes works exactly you said, but I guess the @acrolink point is more about the right way to design this code for validation. There is no strict boundary about where the code must be written (in the same module or another module).

In my projects, I always prefer to place business rules inside another module. For me and my team, it sounds an organized way to split responsibilities, works very well to us.

Of course, this strategy comes a side effect: you will have data validation in two different places for the same entity (post, user, comment, question, etc). You have to feel comfortable with it.

Post #5

— All posts loaded —