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.

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.