I’ve written custom types before, but this specific case gives me pause, and I wonder if you could explain your reasoning here when deciding how to split this logic between cast and dump.
I have a list of base-3 integers that I store in the database as a :binary (postgres bytea).
The value that I assign looks like this (up to 127 digits):
What part of this goes into cast, and what goes into dump?
Here’s what I think, correct me if I’m wrong:
Cast runs the above 3 checks, but keeps it a list.
Dump ALSO runs the 3 checks (in case value was assigned without cast) but converts it into a binary.
However, those 3 things are quite a bit of code. Between 2 guards and an Enum.any? they traverse the whole list a couple of times. If this is correct, am I supposed ignore the fact that I’m running the same logic twice, once for cast and once for dump?
I’m not sure where to put the checks, but at least I can tell you that you only need to iterate once, roughly like this:
def valid_custom_type?(list) do
list
|> Enum.reduce_while(0, fn
_d, l when l > 127 ->
{:halt, :invalid}
d, _l when d not in 0..2 ->
{:halt, :invalid}
_d, l ->
{:cont, l + 1}
end)
|> is_integer()
end
This will iterate not more than once and not more than the first 128 digits of the list.
Due to the early return it should not become a bottleneck that soon.
Ecto.Types handle 3 different data representations. Outside data (most often from form inputs, or json fields in the db), runtime data (how your data is put into your structs by ecto and used at runtime) and the database representations as db column.
cast goes from outside data -> runtime data
dump goes from anything (outside data or runtime data) -> database column data
load goes from database column data -> runtime data
For json (map) fields there’s also
json encoding from anything -> database json value
cast from database json value -> runtime value
The reason why cast/json encoding need to deal with “anything” is because there’s nobody stopping you from inserting data via Repo.insert_all or manipulating a struct manually and there’s no casting involved. So any validation of correct data needs to be done in both cast and dump, where one converts to runtime data and the other to database column data.
That’s a great explanation, and from what I gather, for the question of “Should we be ok with doing the same work twice, once in cast and once in dump” the answer is “yes”.
And since outside data can also be formatted consistently with runtime data, would it be more correct to say that
cast goes from anything to runtime data
dump goes from anything to database column data
With this in mind, it’s almost always ok to actually call cast function from your dump function, does this sound right? (I know it depends, but I’ve noticed I could do that in most custom types I wrote).
And one thing that sometimes confuses (me at least) is that sometimes the “Outside data” and “Runtime data” have the same representation, for example for Ecto.UUID. Seeing it in this visual form makes the reason behind that easier for me to understand/remember:
