Schemaless changeset does not support inputs_for (GitHub Issue).

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

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

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])
…

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.

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