Changes not properly applied with Ecto.Changeset.apply_changes/1

The first sentence of the documentation states:

Provides a function executed by the repository on insert/update/delete.

For Ecto.Changeset.apply_changes there’s no repository involved and it’s neither of those mentioned actions either.

Usually prepare_changes is used to execute code within the same transaction as what the changeset applies to the database, which needs to be provided as a callback as that transaction is only started later (by the repo). If you don’t have a transaction you can directly apply the changes to the changeset in place. No need to delay that.

The docs show an interesting example, where the changeset isn’t modified at all and there are just side effects (updating the database). Most of my uses of prepare_changes do last minute modifications the changeset, and in that regard, I also found it a bit surprising that apply_changes doesn’t apply prepare_changes.

I also use Ecto.Changeset a lot to validate and prepare data for other databases (like Cassandra), so an apply_changes_with_prepare would be useful for me.

In addition to @cjbottaro’s comment, using changesets to validate Phoenix forms makes the use case for apply_changes_with_prepare even more obvious.

A form would have two event triggers validate and submit. You would only want to directly apply the modification in prepare_changes during the submit event and not the validate event. This has first class support if you insert your changeset into a DB but not if you simple need to run apply_changes/1 and store else where such as Cassandra.

I do not want to do my increment to the value after each validation step, only at the end step during apply_changes

You can always call the callback by yourself (acting as your own repository). But this is not a bug. Ecto.Changeset.apply_changes can easily be called in a context, which is not meant to execute those callbacks.

changeset = Enum.reduce(changeset.prepare, changeset, fn c, acc -> c.(acc) end)
Ecto.Changeset.apply_changes(changeset)

Per the docs prepare is not intended for public consumption. This also complicates matters when having nested changesets with embeds_many. Our use case has 5 levels of nesting which means I needed to create a recursive solution.

When doing this though I couldn’t help but feel that this should just be first class supported as this is already implemented when saving the changeset through Ecto.

Also just because the current functionality doesn’t exist doesn’t mean it shouldn’t and there isn’t a valid use case. There should be a separate function or an option on apply_changes to run the prepared changes.

For anyone that needs it, this is the solution I made

  @doc"""
  Runs all prepared functions and apply changes to a changeset. See implimentation of run/1 for more details
  """
  def apply_with_prepared_changes(%Ecto.Changeset{} = changeset) do
    run(changeset)
    |> Ecto.Changeset.apply_changes()
  end

  @doc """
  Runs all prepared functions on a changeset and its associated changesets.
  **WARNING** This should not called before saving a record through Ecto. This will result in
  duplicate prepared function calls and have bad consequences.
  """
  defp run(%Ecto.Changeset{} = changeset) do
    if changeset.changes != %{} do
      Enum.reduce(changeset.changes, changeset, fn {field, value}, acc ->
        new_changeset = run_prepared_fun(value)
        put_embed_or_change(acc, field, new_changeset)
      end)
    else
      changeset
    end
  end
  defp run(changeset), do: changeset

  defp run_prepared_fun(changesets) when is_list(changesets) do
    Enum.map(changesets, fn embeded_changeset ->
      run_prepared_fun(embeded_changeset)
    end)
  end
  defp run_prepared_fun(%Ecto.Changeset{} = changeset) do
    Enum.reduce(changeset.prepare, changeset, fn fun, acc ->
      fun.(acc)
    end)
    |> run()
  end
  defp run_prepared_fun(changeset), do: changeset

  defp put_embed_or_change(changeset, field, value) do
    schema = changeset.data.__struct__
    field_type = schema.__schema__(:type, field)

    case field_type do
      {_, {Ecto.Embedded, _}} -> Ecto.Changeset.put_embed(changeset, field, value)
      {_, {Ecto.Association, _}} -> Ecto.Changeset.put_assoc(changeset, field, value)
      _ -> Ecto.Changeset.put_change(changeset, field, value)
    end
  end

Ecto has quite a strict division between pure Ecto.Changeset apis and sideeffects, which run in Repo apis. prepare_changes is meant to allow for sideeffects to happen - hence the coupling to a repository, which provides the context for the sideeffects to succeed and happen in the same transaction. Take the example placed in the docs. You don’t want to run this when doing Ecto.Changeset.apply_changes. It would change your db in the process on an api, which is not meant to access the database.

I can see how it would be useful, but I’d argue that you’re using prepare_changes for something it’s not meant for.

Do you know if there is an easy way to traverse nested changesets? I.e. a way to use the technique you describe above, but traverse changesets that have several levels of cast_embed and cast_assoc?

There is not. Ecto internally uses Ecto.Embedded.prepare with embeds from schema.__schema__(:embeds) but that is private and requires a repo adapter. I’ll note that Ecto actually reduces over the reversed list of prepares, but with one function the order doesn’t matter.

The internals where Ecto calls these functions are private and very much in the context of a repo. I’ll concur with @LostKobrakai that this is using prepare_changes for something it isn’t meant for. You should just be making changes to your changeset directly before calling apply_changes.