If you mean with validate_change(changeset, field, validator_function) this also wouldn’t work because the validator is only invoked on changed fields.
03juan
0
dimitarvp
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.
1
03juan
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.
0
03juan
@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
valueis 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 tofalse
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>
2
dimitarvp
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!
1
jerdew
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.
1
03juan
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 
0