Keep in mind, the struct’s original state is available in changeset.data.
sodapopcan
7rans
Keep in mind, the struct’s original state is available in
changeset.data.
I’m aware. My thought is that it would be much more convenient if the “working” data was the structure itself and the rest of the changeset structure were in an special metadata field, akin to __meta__. That way you just work with the structure in normal fashion, and the Changeset functions take care of “diffing” after the fact.
Btw, I ran into a snag with using the changeset rather than the structure for my calculate procedure – it’s a lot more complex than I recalled. It has to calculate for each record in an assoc_many relation and each one of those actually gets delegated to a different module based on a “shape” field. it looks like this:
def perimeter(%Feature{} = feature) do
case feature.shape do
:custom -> Shape.Custom.perimeter(feature)
:square -> Shape.Square.perimeter(feature)
:round -> Shape.Round.perimeter(feature)
:fourbar -> Shape.Fourbar.perimeter(feature)
:triangle -> Shape.Triangle.perimeter(feature)
_ -> 0.0 # should never happen
end
end
Having to redo all of these (and more) to handle the changeset instead of the actual struct gives me pause.
I’m thinking now, that since a Map and a Struct are essentially polymorphic, then perhaps I can write a routine that can extract the data from the changeset and convert it to a map. and I can pass that into my calculate function.
0
sodapopcan
Ecto is very purposefully designed this way. Again, it’s hard to know without seeing more code what you need to do, but I promise you there is an elegant FP solution here. I do understand your problem from a high-level but I’ve never actually run into this myself so it’s hard to offer any further advice without getting speculative and rambling, lol.
1
7rans
I did find a reasonably elegant solution. Basically, I realized, where it actually matters, when accessing a struct vs a changeset, was just getting the data via the field names. So I added the following to my struct/schema modules.
def get(%__MODULE__{} = record, field) do
record
|> Map.get(field)
end
def get(%Ecto.Changeset{} = changeset, field) do
changeset
|> Ecto.Changeset.get_field(field)
end
I can just use get() and it will work in either case. That works well for the occasional use case.
For my calculations though, there is so much data access going on at various call depths, get() isn’t that helpful, so I took a different approach, similar to the one’s suggested by you (@sodapopcan), @cmo and @D4no0.
Elixir being a functional language I realized I can apply the changeset and get the record and work with it without effecting the original changeset. So in my calculations I just return the changes made and apply those to the changeset or the struct depending on which I started with…
def calculate(%__MODULE__{} = record) do
changes = calculate_changes(record)
struct(record, changes)
end
def calculate(%Ecto.Changeset{} = record) do
if record.valid? do
record_struct = Ecto.Changeset.apply_changes(record)
changes = calculate_changes(record_struct)
Ecto.Changeset.change(record, changes)
else
record # changeset has errors
end
end
And with a little extra work (to pass along the parent data too) I was able to add the calculate call to the struct’s changeset function as @D4no0 suggested.
One last thing, I realized I made a mistake with this post. I originally thought structs had access behavior b/c of their Map underpinnings. So my original idea of Access behavior for Changeset isn’t at all useful. However, the conversation turned out to be very useful. Much Thanks.
1