How to update a Struct without explicit Attributes

Questions / Help
,
1

Hey folks,

I wondered whether it is possible to update a struct without explicitly defining the attributes that were updated. So, something similar to Ruby where you can update fields on an object and then run:

user = User.find_by(name: 'David')
user.name = 'Dave'
user.save

Let me explain in code what I want to achieve:

# I have a struct that has only one field called "status"
defmodule Order do

  # The struct has a function that updates the status field based on some domain logic
  def refund(%{status: status} = order) when status != :refunded do
    {:ok, Map.merge(order, %{status: :refunded})}
  end
  
  def refund(_order), do: {:error, :order_already_refunded}

  # The struct/Ecto.Schema also has a changeset that does some casting and validating
  # I don't want to have to define which attributes should be updated here though.
  # The changeset (or the context below) should auto-magically find the fields that changed
  # OR simply update all fields except associations. This would work too because then
  # I'd simply overwrite all fields that didn't change with their current value.
  def changeset(order) do
    attrs = somehow_get_attrs_without_knowing_which_fields_changed(order)

    order
    |> cast(attrs, [:status])
    |> validate_required([:status])
  end
end

defmodule Orders do
  # I have a context with an update function that only uses the struct
  # This is different from the usual "update_order(order, attrs)" function.
  def update_order(order) do
    order
    |> Order.changeset()
    |> Repo.update()
  end
end

test "refunds an order" do
  order = %Order{status: :paid}

  {:ok, refunded_order} = Order.refund(order)
  assert refunded_order.status == :refunded

  {:ok, updated_order} = Orders.update_order(order)
  assert updated_order.status == :refunded
end

So, I want to update a struct without explicitly defining which attributes are updated. I still want to use the struct’s changeset to make sure that all required fields are set etc. Do you know a way I could achieve this?

I tried the following, but it didn’t pick up all changes:

defmodule Orders do
  def update_order(order) do
     attrs = order |> Map.from_struct() |> Map.drop([:id, :__meta__, :inserted_at, :updated_at])
    update_order(order, attrs)
  end

  def update_order(order, attrs) do
    order
    |> Order.changeset(attrs)
    |> Repo.update()
  end
end

The problem with the approach above was that the Order.changeset compares the order with the attrs and if they didn’t change, then it doesn’t update them. Since the attrs have the same values as the provided order, it never updated anything.

1 Like
2

I suppose you can always store an order’s last known state in the DB and when you receive a potentially updated Order struct you can look it up via ID in the cache and make a diff that way.

A cache library like Cachex should do the job. If the order isn’t in the cache it will simply fetch it first. Then after you update it in the DB you can update the cache as well.

Or you can also just load the order from the DB every time without using a cache. That would be the most reliable solution. Though it comes with the disadvantage of an extra request to the DB every time.

All that being said, I’d still inspect the call-site and do my best at composing the list of modified attributes there. What’s preventing you from doing it?

3

It is not possible because this will lead to inconsistencies.

Let’s check out all possible scenarios

  1. You update structure, use updated structure and then call changeset. With this approach, when you use the updated structure, you could’ve used incorrectly set values (because changeset check was not performed yet).
  2. You update structure, call changeset and then use updated changeset. With this approach you’d have to use get_field and family of functions to get the actual data from the structure. But this data may be incorrect too, since it is missing some autogenerated-in-the-database fields, database hooks and all this stuff

So I’d suggest using the approach dedicated by Ecto library: record is separate from it’s changes, changes can be verified and the version of the record with all the changes applied is visible only after interaction with the database (because DBs have hooks, autogenerated fields, etc)

1 Like
4

I don’t really recommend what you’re doing, but the closest thing I can think of would be to use postgres INSERT ON CONFLICT

order_struct
|> Repo.insert(on_conflict: :replace_all, conflict_target: :id)
1 Like
5

You generally want to create changesets for such actions. Something like this:

def refund_changeset(%{status: :refunded} = order) do
  order
  |> change()
  |> add_error(:status, "Order already refunded")
end

def refund_changeset(order) do
  order
  |> change(%{status: :refunded})
  |> validate_can_refund() # Custom validation of other criteria that may make a non-refunded order non-refundable
end

Then in your context have an explicit Orders.refund_order/1 function:

def refund_order(order) do
  order
  |> Order.refund_changeset()
  |> Order.update()
end

If you want to stay CRUDy like that, you’re going to have to get a little more creative in checking if it’s valid to refund. The simplest way off the top of my head would be to add another function head to Orders.update/2 context function:

def update_order(%{status: :refunded} = order, _attrs) do
  changeset =
    order
    |> Ecto.Changeset.change()
    |> Ecto.Changeset.add_error(:status, "Order already refunded")

  {:error, changeset}
end

def update_order(order, attrs) do
  # ...
end

There is probably (definitely) a better way to do the CRUD version but just trying to offer something as a starting point.

1 Like
6

The Ecto equivalent of returning an unsaved ActiveRecord object is returning an Ecto.Changeset, not a struct that’s only updated in-memory - then you can pass that directly to functions like Repo.update.

5 Likes
7

Yeah, updating data in place is imo a smell in ecto/elixir. Being explicit and returning a changeset is the way to go, as this cleanly communciates what is been dealt with: Not yet persisted changes.

1 Like