Ecto Custom types and casting issue - (Ecto.ChangeError) value “127.0.0.1” for Schema.ip_addr in insert does not match type EctoNetwork.INET

dbaer · February 1, 2021, 5:22am

I’m attempting to track down a problem with custom ecto types that I just realized I’ve been having for years.

I’ve used the EctoNetwork library to support inserting :inet data, but had since worked around an IP string not matching the custom type.

From everything I’ve read about custom types i’m lead to believe if I set a schema’s field type to a custom type, the custom type cast functions should be called. Even the readme for EctoNetwork states, add the library as the dep, set the schema field to EctoNetwork.INET, and set the migration to :inet. Period.

Now i’ve been casting inet manually for years because if I pass in a string (“127.0.0.1”) I get ** (Ecto.ChangeError) value “127.0.0.1” for Schema.ip_addr in insert does not match type EctoNetwork.INET`.

What gives? The custom type has a cast function that specifically handles binary data. It’s not called at all. I’ve even tried writing a custom type manually and cast is never called.

Am I misunderstanding the purpose of cast? Why is it required if it’s not called?

Eiji · February 1, 2021, 5:52am

For me this library works as expected. Can you please share a minimal example code to reproduce your problem?

Laetitia · February 1, 2021, 6:15am

Hi,
there is here a great code from dashbitco doing the job:

github.com

dashbitco/bytepack_archive/blob/main/apps/bytepack/lib/bytepack/extensions/ecto/ip_address.ex

defmodule Bytepack.Extensions.Ecto.IPAddress do
  use Ecto.Type

  @impl true
  def type(), do: :inet

  @impl true
  def cast(string) when is_binary(string) do
    parts = String.split(string, ".")

    case Enum.map(parts, &Integer.parse/1) do
      [{a, ""}, {b, ""}, {c, ""}, {d, ""}]
      when a in 0..255 and b in 0..255 and c in 0..255 and d in 0..255 ->
        {:ok, {a, b, c, d}}

      _ ->
        :error
    end
  end

This file has been truncated. show original

dimitarvp · February 1, 2021, 11:13am

Interesting project, thanks for linking to it.

dbaer · February 1, 2021, 8:36pm

Okay I see the issue now. The field in question was getting piped in via put_change/3 after the fact, so it was bypassing cast altogether.

I’ll have to play around a bit more to see if I can’t pipe it in before, I was attempting to avoid sending it to cast directly since it’s not user supplied and i’m trying to keep those concerns separate.

I may just have to live with casting it manually!

TL:DR I was putting the square block in the circular hole.

Thanks guys!