Ecto Association vs Foreign Key Constraints

Questions / Help
,
1

I’m having trouble understanding the difference between cast_assoc, assoc_constraint and foreign_key_constraint in a changeset. More specifically, I don’t seem to understand when you should build your associations explicitly (by putting foreign keys) versus letting Ecto build them with associations.

I have a schema like this:

schema "institution_codes" do # InstitutionCode
  field :code, :string
  belongs_to :source, Source
  belongs_to :institution, Institution
end

def changeset(struct, params \\ %{}) do
  struct
  |> cast(params, [:code])
  |> cast_assoc, assoc_constraint or foreign_key_constraint?
end

…and in my migration:

create table(:institution_codes) do
  add :code, :string
  add :source_id, references(:sources)
  add :institution_id, references(:institutions)
end
create unique_index(:institution_codes, [:source_id, :institution_id], 
                     name: :institution_codes_index)

If I want to insert a record into institution_codes, should I be looking up the foreign keys of the Source and Institution schema and explicitly putting them in source_id and institution_id in my InstitutionCode schema params then inserting the record, or putting associations?

The unique constraint on InstitutionCode doesn’t seem to work when putting associations. When I try to insert the record I get errors in my changeset that there are uniqueness violations in the Source and Institution schemas because Ecto is trying to insert the associations. I want it to put the keys of the associations as foreign keys in the InstitutionCode record, not insert the associations themselves.

I feel like I have a fundamental misunderstanding of how these should be used.

4 Likes
2

After some digging, I found this stackoverflow post which really helped explain the difference.

cast_assoc/3 is only used in the changesets of schemas that have has_one or has_many. It invokes the cast/3 validation in the changeset of the associated schema.

assoc_constraint/3 is used in the changesets of schemas that have belongs_to. It checks to make sure the parent schema is in the database so an orphaned record isn’t inserted.

foreign_key_constraint/3 is used similarly to assoc_constraint/3, except that it uses the database to validate the foreign key constraint, whereas assoc_constraint/3 uses the Ecto schema definition.

The reason I was having issues inserting records with associations was because of the way I defined the association. Ecto was trying to insert the parent record along with the child record. As noted in that linked article, the correct way to insert a child record with a parent association is to either build the the association using build_assoc/3 from the parent record, or, in more complex casts, put the parent foreign key in the parameters of the child record and pass that to the changeset.

See one, do one, teach one :wink:

32 Likes