axelson
What goes in changeset params vs the struct
I’m not clear on what the best practice is for deciding what can be set from a changeset’s params vs what should be directly set in the struct. I’ve been leaning towards not allowing “important” fields, such as a user’s role (i.e. admin or member) to be set from the params since the params sometimes come directly from the client application. But this sometimes makes different parts of the application need to know how to set the user’s role before calling the changeset. Are there any established best practices (or just plain advice) that anyone can give me?
Marked As Solved
sergio
Anything from params can be user set. So you’re correct, don’t let the user set role to anything they typed into params.
In your specific example, I would create a function that uses the put_change function to set the role and transform the changeset using pipes.
changeset =
|> changeset(%User{}, params)
|> set_user_role("admin")
Repo.insert! changeset
...
def set_user_role(changeset, role) do
put_change(changeset, :role, role)
end
Also Liked
LostKobrakai
You could expose multiple changeset handling functions. One which allows (a.k.a. casts) the roles, one which doesn’t. Schema.changeset/2 is only special in that it’s used as default changeset function for cast_assoc / cast_embed, but even these can be changed.
Another option would be using custom changesets for your UI layer (embed schema or even schemaless) and convert the validated data of that changeset into the actual params to pass further down into your system.







