Schemaless Changesets vs Embedded Schemas for Phoenix Forms

Questions / Help
, , ,
1

While reading Programming Phoenix LiveView, I came across a section (Model Change with Schemaless Changesets - Chapter 5) which goes through setting up schemaless changesets for forms that you do not have a database table for.

I am very familiar with this method (I do it all the time), however instead of creating a Schemaless Changeset, I usually opt to just make an Embedded Schema. To me it seems simpler/cleaner to be able to define the struct and the type at the same time instead of maintaining two things (defstruct and types).

Schemaless

defmodule MyApp.Accounts.User do
  defstruct [:first_name, :email]
  @types %{first_name: :string, email: :string}
end

Embedded

defmodule MyApp.Accounts.User do
  @primary_key false  
  embedded_schema do
    field :first_name, :string
    field :email, :string
  end
end

Question:

Are there any reasons to choose schemaless changesets over embedded schemas?

9 Likes
2

Schemaless changesets can be defined at runtime/by code. So itā€˜s useful when you donā€˜t have a fixed schema.

1 Like
3

Iā€™ve always used ā€œembeddedā€ schemas. I donā€™t think Iā€™ve ever seen the official docs endorse ā€œschemalessā€, where as they do the former.

Schemaless feels like itā€™s dipping into some private APIā€™s with that @types module varā€¦ :stuck_out_tongue:

4

Thereā€˜s no need for it to be a module attribute though. The data can come from wherever:

{%{field: nil}, %{field: :integer}}
|> Ecto.Changeset.cast(params, [:field])
ā€¦
2 Likes
5

I also found the distinction between using a schemaless changeset and an embedded schema confusing at times.

Part of that confusion stems from the name of ā€œembedded schemaā€, I think. Using them stand-alone does not require them to be embedded in any way. But I see where the name comes from (using them in combination with a database).

6

You can use schemaless changesets without a struct. Ä° do that when I want to implement lightweight validation for user input that doesnā€™t pertain directly to an existing schema.

7

Schemaless changeset does not support inputs_for (GitHub Issue).

Please, use embedded schemas. This cost me 3 weeks of work.

7 Likes
8

For Phoenix Forms, no. I always opt for the embedded schema. I have experimented with a kind of Django-like form module where I define, for example, WebWeb.Forms.OnboardingForm and use an embedded schema. Then the save function can run a Multi or just regular stuff from the application modules inside a transaction. Itā€™s kind of nice, but I havenā€™t decided if itā€™s the best solution. The idea is that the form is really a web-side concept that just needs to call a few backend functions.

For me, schemaless changesets work well for bulk imports where you want to run data validation and massaging before an insert_all/3. This is mostly for internal use, but I can imagine using it for an API and telling the user which record failed to validate for a better user experience.

Hereā€™s an example, right inside my schema module:

  def schemaless_changeset(attrs) do
    types = Enum.into(__MODULE__.__schema__(:fields), %{}, fn field ->
      {field, __MODULE__.__schema__(:type, field)}
    end)

    {%{}, types}
    |> cast(attrs, Map.keys(types))
  end

Now of course you can just use the actual schema, but it feels ā€œdirtyā€ because you canā€™t use insert_all/3 on a schema or changeset. So, rather than having apply_changes/1 (or apply_action/2) turn the changeset into a schema then back into a map or keyword list (and forgetting to remove the additional struct fields in the schema ;), I like this approach. As with anything, your mileage may vary.

2 Likes
9

We should probably move Programming Phoenix LiveView to embedded, and talk about the tradeoffs.

5 Likes