Explanatinos about `use Ecto.Type` and `@behaviour Ecto.Type`

Questions / Help
, , ,
1

Hi everybody,
I’m following along the Programming Phoenix 1.4 book and at a moment we are implementing a custom Ecto type.
According to the docs (here in the second line) it is also expected that 4 functions are also defined.

Here is the extract:

#---
# Excerpted from "Programming Phoenix 1.4",
# published by The Pragmatic Bookshelf.
# Copyrights apply to this code. It may not be used to create training material,
# courses, books, articles, and the like. Contact us if you are in doubt.
# We make no guarantees that this code is fit for any purpose.
# Visit http://www.pragmaticprogrammer.com/titles/phoenix14 for more book information.
#---
defmodule Rumbl.Multimedia.Permalink do
  @behaviour Ecto.Type

  def type, do: :id

  def cast(binary) when is_binary(binary) do
    case Integer.parse(binary) do
      {int, _} when int > 0 -> {:ok, int}
      _ -> :error
    end
  end

  def cast(integer) when is_integer(integer) do
    {:ok, integer}
  end

  def cast(_) do
    :error
  end

  def dump(integer) when is_integer(integer) do
    {:ok, integer}
  end

  def load(integer) when is_integer(integer) do
    {:ok, integer}
  end
end

As you can see the 4 functions (type, cast, dump and load) are defined and everything works as expected.

However in my case I got dialyzer warnings (I’m using ElixirLS) about two callback functions that are still not implemented: equal?/2 and embed_as/1

As my first question, what are the difference between functions and callbacks within elixir Modules (like here in Ecto.Type)?

I noticed that all the callbacks are also present in the functions (with the arity decremented by one) and so that they don’t receive the type.
Is it something comparable to static methods in OOP where there is no need to instantiate an object?

Also, I noticed that if I use Ecto.Type instead of @behaviour Ecto.Type, everything still work but I don’t have the warnings.
I took a look at the source code and it seems that using Ecto.Type automatically defines those two functions.

So my second questions is what are the difference between these two declarations:

  • @beviour Ecto.Type
  • use Ecto.Type

And why choose one over the other?

Thank you very much for any details…

2

The callbacks are functions other modules implementing the behaviour need to implement. That there are functions named the same in Ecto.Type itself is totally unrelated to the callbacks.

The two callbacks you were warned about are only recent additions to the Ecto.Type behaviour and only relevant to a subset of types. Therefore the simultaneous addition of use Ecto.Type so people can update their types without actually needing to add more code to existing Ecto.Type implementations. The macro basically adds the default implementation for those two callbacks, which constitute to the behaviour of the type before those additions. New implementations can chose to override those. When doing @behaviour Ecto.Type you’ll however need to implement all callbacks on your own, therefore the warning.

2 Likes
3

What is the right implementation for these two callbacks, given the aforementioned example?

Currently I have:

def embed_as(_format) do
  :self
end

def equal?(integer1, integer2) when is_integer(integer1) and is_integer(integer2) do
  integer1 == integer2
end

But perhaps equal?/2 does not need or even should not have is_integer guards?

4

If you want to treat entities the same despite slug you can use:

  def equal?(value1, value2) do
    with {:ok, integer1} <- cast(value1),
         {:ok, integer2} <- cast(value2) do
      integer1 == integer2
    else
      _ -> false
    end
  end

I am not sure about embedding, if you want a type to behave perfectly the same as id maybe you’ll need to use:

  def dump(binary) when is_binary(binary) do
    cast(binary)
  end

  def embed_as(_format) do
    :dump
  end