On 9 February 2020 12:18:05 pm AEDT, Greg Vaughn <gvau...@gmail.com> wrote:
>...
>The first step is to look for the equivalent of all the keys we care about and
>create a map with known key names. Then we go through an Ecto changeset for
>validation and further processing.
I think the problem is quite common and in my code every data type has a
'from_json' function which takes the data for the embedded struct and calls
that struct 'from_json' and so on.
With Ecto it is solved by just having a 'changeset' function in the struct
module which uses Ecto.Changeset.cast and Ecto.Changeset.cast_embed which in
turn loads the embedded struct.
>I look for, let's guess, about 15 fields from each of these json payloads. I'd
>have to pattern match 15 times with an if statement,
So do you have 15 different paths now to handle different payloads? Will it be
significantly better with nillable get_in?
All my code where I initially thought to use get_in/update_in, in the end I
switched to direct struct pattern-matching/construction (for compile-time
fields checks) and manual extraction of data using Map.get/3 (for more control).
I don't say that my way is any more convenient or better than any other. I'm
just trying to suggest to look at the problem from scratch and try to apply
some other solution -- maybe it will be reasonable without waiting for the
standard library to be extended.
>
>-Greg Vaughn
--
Kind regards,
Dmitry Belyaev
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/FC20D8D4-1DDF-4673-AFE1-C8452113CAAC%40gmail.com.
