@dimitarvp Something just came to mind… change may be the wrong function for this use case if we want the most idiomatic way to error for a dynamic test of new < old when new could be == old.

The docs also say about change:

Note the value is directly stored in the changeset with no validation whatsoever. For this reason, this function is meant for working with data internal to the application.

This function is useful for:

• wrapping a struct inside a changeset
• directly changing a struct without performing castings nor validations
• directly bulk-adding changes to a changeset

But as we’ve seen the issue is that the change is not added when the values are the same.

I haven’t gone through the “Programming Phoenix LiveView” book in detail but I assume this is an exercise? All their changeset examples use cast instead of change and this is the most idiomatic approach to solve this problem, with an extra option.

• :force_changes - a boolean indicating whether to include values that don’t alter the current data in :changes. Defaults to false

The reason to use cast is that if this changeset will be called with params from a form, it will attempt to cast the string value from the client into float, and return a cast error if that fails.

In which case we’d want to pass the params as an attribute to cast

def lower_price_changeset(%Product{unit_price: old_price} = product, params) do
  product
  |> cast(params, [:unit_price], force_changes: true)
  |> validate_number(:unit_price, less_than: old_price)
end

iex> Pento.Catalog.Product.lower_price_changeset(p, %{"unit_price" => "9.0"}) 
#Ecto.Changeset<action: nil,
 changes: %{unit_price: 9.0},
 errors: [
   unit_price: {"must be less than %{number}",
     [validation: :number, kind: :less_than, number: 9.0]}
 ],
 data: #Pento.Catalog.Product<>,
 valid?: false>

Actually put_change also says If the change has the same value as in the changeset data, it is not added to the list of changes.

I’ve checked the source for validate_number and it uses validate_change internally, which also states

It invokes the validator function to perform the validation only if a change for the given field exists and the change value is not nil .

I really depends on your use case. What I’m assuming is you want the changeset to throw an error when new >= old.

It will throw an error when new > old because change(unit_price: new_price) marks unit_price as changed and therefore validate_number(:unit_price, less_than: old_price) runs against the changed value.

But change won’t mark the attribute as changed if new = old and therefore it won’t ever run validate_number.

This is probably your best bet

because ecto not seeing the change is a feature to prevent unnecessary db writes when the value wouldn’t change, but you can still force it with force_change.

Otherwise you could add a custom error when the prices are equal and let the normal validation take care of the less_than case. (this is what I actually meant by custom validation, sorry for the confusion)

def lower_price_changeset(product, new_price) do
  old_price = product.unit_price
  product
  |> change(unit_price: new_price)
  |> error_on_equal_or_less_than(old_price, new_price)
end

defp error_on_equal_or_less_than(changeset, old_price, old_price) do
  add_error(changeset, :unit_price, "is equal to old price", old_price: old_price)
end

defp error_on_equal_or_less_than(changeset, old_price, _) do
  validate_number(changeset, :unit_price, less_than: old_price)
end

The changeset won’t show the price changed in the changes: key, but it will have it in the error and the changeset won’t be valid, so you can adapt your business and application logic to match on it.

#Ecto.Changeset<action: nil,
 changes: %{},
 errors: [unit_price: {"is equal to old price", [old_price: 9.0]}],
 data: #Pento.Catalog.Product<>,
 valid?: false>