Understanding changesets... is it better to have one or multiple changesets?

Phoenix Forum Questions / Help
, ,
1

Hi,
this is probably a silly question, but I’m an Elixir and Phoenix beginner, learning new things every day.

Let’s say I have a project schema with couple of fields like title, description and status.

schema "projects" do
    field :title, :string
    field :description, :string
    field :status, :string
end

I want to be able to update title and description from one function and I want to have completely different function to update just status. Would it be better to use one changeset for both of those functions or would it be better to split it into two changeset?

def changeset(%Project{} = project, attrs) do
    project
    |> cast(attrs, [:title, :description, :status])
end

vs

def base_changeset(%Project{} = project, attrs) do
    project
    |> cast(attrs, [:title, :description])
end

def status_changeset(%Project{} = project, attrs) do
    project
    |> cast(attrs, [:status])
end

I hope someone will be able to help me understand this.

1 Like
2

You will probably want two changesets. Especially if you are using Phoenix, because when you construct the forms, it will use the changeset for validation. So if you have a form with inputs for title and description, and then another form with a dropdown menu to change the status, you want the appropriate changeset for each use case.

3 Likes
3

This is one of those things where there is probably more than one way valid way to proceed so long as you’re consistent within the project that you’re working. I’ll give you my take on it. Also, I’m assuming that the changeset will ultimately be used to update a database somewhere. This is not the only use case for changesets, but its the one I’m most familiar with and for which I’ve formed some opinions so will be my focus here.

I use the changeset mostly for whole record validation. Does the data I’m about to persist meet the criteria for a record to be valid or not, and if not how does it fail? I do use specialized functions like you are thinking about for isolated data changes like only performing status changes. These specialized functions are effectively a layer above the changeset and are closer to an internal API; they will ultimately call a generalized changeset function for validation, after they’ve performed any special operation or validation that pertains to the specialized operation (i.e. the status change).

There are a couple reasons for this. First, I want a single place to express what constitutes a valid data record (that’s a lie, I do a lot of in database constraint management as well which also acts as data validation, but view that as last resort at the point of information truth.) If I start specializing the changesets to for a given data operation I lose some of that simplicity of having an in application definition for validation; the idea of ‘valid’ for a single record starts to get spread around between functions and I expect would become more difficult to manage or track down problems. Next, it gives me that extra level of abstraction that allows me to separate some of the persistence related concerns from the business logic concerns; by expecting to manage things like statuses and data in the API, how it’s persisted becomes less important to the business logic and to me the changeset feels much closer to that persistence layer.

I do have multiple changeset functions for records, but I vary based on coarse grained data operation: insert vs. update. Aside from pure validation, I will allow some defaulting on insert operations whereas update operations assume the record is whole with only changes to otherwise valid data being made. But that’s pretty limited with about 75% of my changeset use being about just validation of passed data.

Anyway, that’s my perspective.

4 Likes