How to validate Ecto Associations properly?

Hello there, I’m getting some problems in validate associations in Ecto. I have two schemas, Video and Playlist (a playlist can have many videos). The Video schema has a following changeset:

def changeset(video, attrs \\ %{}) do
    |> cast(attrs, [:name, :url, :playlist_id])
    |> validate_required([:name, :url, :playlist_id])

And Playlist has the following changeset:

def changeset(playlist, attrs \\ %{}) do
    |> cast(attrs, [:name, :category])
    |> cast_assoc(:videos, required: true)
    |> validate_required([:name, :category])

What I want is when create a video, a playlist must be required, and when create a playlist, at least, one video has to be informed. This works for the video case, but when I try to create a playlist, there is a validation error on playlist_id of video. Anyone has some idea how to proceed with this? What I’m doing wrong? Thanks!

Sounds like you’re trying to build everything in one go? But since the playlist doesn’t exist yet, it doesn’t have an id, so it can it be given to the videos, so they fail their validation.

Confession: I can’t remember the last time I used cast_assoc personally, I set association ids manually. I also don’t like how IIRC you have to always give all the relationships in total which can be cumbersome.

I would do something like this, where its a two step transaction. You can also try ecto.multi.

### Writing this on my way out the door, so take it as a suggestion

def create_playlist_with_videos(name, category, videos) do
  # I normally have my own wrapper around transaction, so trying to remember
  # exactly without docs.
  Repo.transaction(fn ->
    with {:ok, playlist} <- create_playlist(name, category),
         # now playlist exists with an id so we can create videso
         {:ok, videos} <- create_playlist_videos(playlist, videos) do
      # transaction() wraps result in {:ok, _}
      %{playlist | videos: videos}
      # can write this nicer, ideally the {:error, _} could just fall
      # out and fail the transaction
      {:error, e} -> rollback(e)

defp create_playlist(name, category) do
  # its ok to have more than one changeset function, i find it useful to
  # have at least a create_ and update_ as often they want different
  # validations.
  |> Playlist.create_changeset(name, category)
  |> Repo.insert()

defp create_playlist_videos(%Playlist{} = p, videos) do
  |> v ->
    |>Video.create_changeset(,, v.url)
    |> Repo.insert()
  |> Enum.reduce({:ok, []}, fn
    # acc is error, perpetuate
    # you can use reduce_while to quit out
    _, {:error, e} -> {:error, e}
    # vid was ok, save and keep going
    {:ok, vid}, {:ok, vids} -> {:ok, [vids | vid]}
    # vid was error, return error (or collate all errors or ...?)
    # how you handle these errors is kind of application specific
    {:error, cs} _ -> {:error, :idk_lol}

e: you also probably want to put a null: false constraint in the database too if you haven’t.


Oh I meant to mention, you can of course still use cast_assoc if you want. Just you need to create the playlist first - or generate an ID that can be used if youre using uuids. You can still use a transaction/multi to ensure that the playlist creation worked before trying to create the videos.

If you look at the docs for cast_assoc you’ll see they all operate on something that was Repo.get’d.

Your changeset validations are run when called, so with that in mind it should make sense why the validation is failing.

@soup thanks for you anwser!

I thought initially in this case, but if remove the validation on playlist_id on Video, the creation occours without errors and the video is linked to playlist. But, if create a video without a playlist_id a not null constrait exception is raised because there is not validation. How I setup for this case?

cast_assoc combined with validate_required on the child schema’s foreign key will not work (see also a lot of the search results on this forum for cast_assoc). When you’re creating a Playlist, the related Video changesets need to be valid before the Playlist has an ID.

My suggestion to resolve this:

  • use a changeset function in cast_assoc(:videos, ...) that doesn’t cast or require playlist_id; that value will be set by the Ecto machinery automatically

  • if a video cannot be created without a playlist_id, enforce this at the database level with a null: false constraint on the column

A rule I find useful to help decide if something should be validated in a changeset function: is there a meaningful way to give feedback about a resulting error to the user? For instance, a blank name or category can show a “can’t be blank” message next to the UI for that value - what feedback could a missing playlist_id give?

If you indeed create videos standalone as well as part of a playlist then I’d suggest two changeset functions, one with validate_required for playlist_id and one without.

The error includes instructions,

or more generally

i’ve already setup this

For this case, the message error will be like: “must be select a playlist”

This was my current solution. I’ve created two changeset functions. The first I use when create a video standalone, with the playlist_id validation and the second, I use in cast_assoc of Playlist changeset function. I don’t know if it is a good practice and if there is better way to do this