I would rather not leave myself a crime scene in my code that I have to figure out before I can do my work (especially when debugging!). I bounce around way too

I would rather not leave myself a crime scene in my code that I have to figure out before I can do my work (especially when debugging!). I bounce around way too many systems in way too many languages to keep all the rules of every ORM and framework in my head.There's always a balance, but you can do really expressive things in the explicit. In the authors example of the Person, Ecto from Elxir doesn't favor magic happening for the has_many; you have to call out the validation AND relationships yourself. I think that's a good thing schema "people" do field :first, :string, null: false field :last, :string, null: false belongs_to: :company, App.Company has_many: :assignments, App.Assignment, foreign_key: :person_id end def create_changeset(attrs) do %Person{} |> Ecto.Changeset.cast(attrs, [:first, :last, :company_id]) |> Ecto.Changeset.validate_required([:first, :last, :company_id]) |> Ecto.Changeset.foreign_key_constraint(:company_id) end And in the Assignment changesets you'd do the reverse for making sure the other sides' entities exist, or in the join table for many to manies. I think the win readability wins later FAR outweigh the few validations I have to explicitly type out. A new person or someone under a deadline can quickly open one of the Ecto schemas, see all the relationships, see the validation being done, and see why stuff fails. And by turning it into a function you must explicitly call, it makes the data the most important thing and not the ORM itself. I could have called that function "parent_changeset" or "lawyer_changeset" if those made sense for what those functions did; they're not specially named. And then when you get that, you still need to actually apply the changes to have any effect.