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)?
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.
