Float comparision in ecto

In the docs for change it says Changed attributes will only be added if the change does not have the same value as the field in the data.

So in this case I don’t think the validation is run because the unit price hasn’t changed.

I don’t often use change/2 so I went to the docs and noticed this:

Changed attributes will only be added if the change does not have the same value as the field in the data

9.0 == 9.0 so there is no change. maybe try:

product
|> change() # make a changeset
|> put_change(:unit_price, new_price)

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 .

The best bet would probably be writing your own validator that adds a changeset error if the values match, or then invokes the validate_number(... less_than: old_priced)

Thanks for the answers, good to know that this is the intended functionality at least. Do you think it’d be the “correct” solution to implement my own validator or to simply return an empty changeset? I feel that the code would become worse if I were to implement an essentially identical version of a library function but on the other hand it is inefficient to keep the execution going knowing that no changes will be made. I’m not entirely sure how Ecto translates this to the database level but I can imagine that it is handled in an efficient manner and that the performance penalty is not that big.

I am not sure what else should Ecto be doing, can you specify your expected behavior?

But if you really really want to flag a field as changed there’s always Ecto.Changeset.force_change.

I expected an invalid changeset yo be generated, as it does when I give set the new_price parameter to a number which is greater than old_price. Intuitively it doesn’t make sense to me why the cases new_price > old_price and new_price = old_price would yield different given the validate_number call in my original post.

Ah yes, I thought there was also an equal sign there. Did you try with force_change and see if the validator gets tripped then?

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>

Oh right, maybe it would have helped if I paid a little more attention. You are 100% correct.

I’d also advise for a custom validator function in this case. It’s no big deal and I don’t know why people are so averse to it; it’s just a pipe of functions as all others in Elixir. But I do get it, some get cold feet because previous frameworks gave them PTSD. Can relate!

Though in this case I’d make a custom validator that replaces Ecto’s validate_number + less_than in one fell swoop, i.e. makes the check and either adds an error or just returns the original changeset.