Float comparision in ecto

It certainly does make them feel that way, and I’m also glad that we can discuss such things in these forums. At least the dev team is always open to contributions to improve the docs so I may give this a shot unless someone else gets inspired. If so ping me and we can work on it together

The many options for changeset functions have made them feel intractable in exactly this way.. ‘what’s the right way to tackle my edge case that’s not spelled out in the docs’. Just wanted to post that I’m very glad I was corrected and that @acke’s original question was talked this far out as this has helped me.

You made me realize that I have mistaken force_change(...) with cast(..., force_changes: true). That’s why I was confused at the start of the thread that it’s not working.

Thank you!

@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>

Hard agree. But here we’re already presenting 4 different ways to do things, so I can see why some would be averse! The beauty of the functional approach does make it easier to swap things out and see what works best.

No, I mean our own function that accepts a changeset + args and returns a changeset. Here:

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

  def validate_price(%Changeset{} = changeset, old_price) do
    new_price = get_change(changeset, :unit_price)

    cond do
      new_price > old_price ->
        add_error(changeset, :unit_price, "is bigger than the old price", old_price: old_price)

      new_price == old_price ->
        add_error(changeset, :unit_price, "is equal to the old price", old_price: old_price)

      true ->
        changeset
    end
  end

An even better option would be to merge both change(unit_price: new_price) and the function above into something like maybe_put_new_price. The benefit being slightly more readable code + not having to pull out the new price via get_change.

If you mean with validate_change(changeset, field, validator_function) this also wouldn’t work because the validator is only invoked on changed fields.

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.

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>

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?