Best practice for association changesets

sglyon

I am an experienced dev, but pretty new to elixir. I keep finding myself going back and forth between a couple options for how to construct a changeset that will create a new record with one or more associations.

The following small ecto schema module presents the two options

defmodule MyProject.Quizzes.QuizQuestion do
  use Ecto.Schema
  import Ecto.Changeset

  schema "quiz_questions" do
    belongs_to :quiz, MyProject.Quizzes.Quiz
    belongs_to :question, MyProject.Questions.Question

    timestamps()
  end

  @doc false
  def changeset(quiz_question, attrs) do
    quiz_question
    |> cast(attrs, [:quiz_id, :question_id])
    |> validate_required([:quiz_id, :question_id])
    |> foreign_key_constraint(:quiz_id)
    |> foreign_key_constraint(:question_id)
  end

  def create(%MyProject.Quizzes.Quiz{} = quiz, %MyProject.Questions.Question{} = question) do
    %__MODULE__{}
    |> change()
    |> put_assoc(:quiz, quiz)
    |> put_assoc(:question, question)
    |> foreign_key_constraint(:quiz_id)
    |> foreign_key_constraint(:question_id)
  end
end

In this example I have three models: Quiz, Question, and a join table QuizQuestions that combines them. I have two functions in the module:

change: this takes in an attrs map, casts the foreign key id, requires them, and adds foreign key constraints
create: takes in instances of the related schemas (Question and Quiz), uses put_assoc to build the association, then adds foreign key constraints

Both of these approaches let me create the new QuizQuestion struct that is Repo.insertable, but I still have some questions.

Is one approach more idiomatic and why?
Should I prefer one case to the other?
What are the tradeoffs?
Is it bad practice to use structs defined in other core modules as arguments to functions (like I did in create when I accept Quiz and Question structs)?

4 comments

#ecto #ecto-changeset

0 1254 4

2025-02-13 09:41:39 UTC

First 4 of 4 Posts

al2o3cr

I’m going to give you the less-than-entirely-helpful “it depends”

Both approaches can be useful, depending on exactly where quiz and question are coming from:

if both are coming from the user, an approach that casts them could be useful to make sure they’re converted to the ID type etc
if neither are coming from the user, the full put_assoc approach is fine
it’s also possible to have a mix - maybe the function is being called from a URL like /quiz/1234/questions where the Quiz to associate is known but the question_id to use is from the user

In the “neither from the user” case, you might even shorten things further if you don’t want / need to display foreign key errors as changeset errors:

def just_create_already(quiz, question) do
  %__MODULE__{quiz: quiz, question: question}
end

This can be passed to Repo.insert directly, no changeset required.

Two general things to think about:

where is the input coming from? Does it need to be type-cast?
where should errors appear? Are they meaningful?

For instance on the second point, a field that a user could leave blank might have validate_required on it so they could be told they’re making a mistake. OTOH a field that the program fills in that shouldn’t ever be blank might just have a bare NOT NULL in the DB so failing to fill it in crashes / fails.

Post #1

lucavenir

I hope I don’t startle anyone asking this 2 years later.

it’s also possible to have a mix - maybe the function is being called from a URL like /quiz/1234/questions where the Quiz to associate is known

But in reality 1234 comes as a binary, doesn’t it?

So, related to this, given that we need to cast "1234" to 1234, how would one code the changeset function, here?

Post #2

garrison

The implication here is that if you are on /quiz/1234 then you have already done a Repo.get(Quiz, id) and you have a %Quiz{id: 1234} to work with.

Personally, in that situation I often do something like this:

def create_question(%Quiz{} = quiz, params) do
  %Question{quiz_id: quiz.id}
  |> Question.changeset(params)
  |> Repo.insert()
end

But it would be just as valid to work with associations or use put_change() for the quiz_id. The point is that you don’t need to cast quiz_id because it comes right from a real %Quiz{} and it’s already an integer.

Post #3