How does one implement Single Table Inheritance in Ecto?

You can use changeset functions for that:

defmodule Vehicle do
  schema "vehicles" do
    field :type, Ecto.Enum, values: [:car, :bus]
    # ...
  end

  def create_car_changeset(attrs) do
    %__MODULE__{}
    |> change(%{type: :car})
    # pipe through create_vehicle_changeset() if you want to extract common stuff
    |> cast(attrs, [:car_attr_1, :car_attr_1])
    # ...
  end

  def create_bus_changeset(attrs) do
    # ...
  end
end

Alternatively, you can create separate schemas on top of a single table:

defmodule Car do
  schema "vehicles" do
    field :type, Ecto.Enum, values: [:car, :bus]
    # shared and car fields only
  end
end

defmodule Bus do
  schema "vehicles" do
    field :type, Ecto.Enum, values: [:car, :bus]
    # shared and bus fields only
  end
end

If you don’t like changeset functions you can inline them in the context module.

Thanks a lot @stefanchrobot. On a lighter note, the answer came faster than the time I took to compose the question.

Happy to help! I’ve used STI just recently, so I’ve been looking into this lately

If you do not mind to share - which method you have gone in to? Changesets or Separate schemas?
At first thought, I felt like, Changesets looked good when there is a lot of common ground.

Can you explain why do you need a single table? How about having busses, cars and vehicles, where busses belongs_to vehicles and cars belongs_to vehicles?

This means that you have the following DB schema:

table vehicles(id, reg_no, ...)
table busses(id, vehicle_id, ...)

This means that on the database level, you can have a vehicle that’s not referenced by anything. Maybe that’s what you want, maybe it’s OK for your application. Personally, it makes me a bit uneasy.

You can reverse the reference:

table vehicles(id, bus_id, car_id, reg_no, ...)
table busses(id, ...)

But that’s not great either if you intend to add more vehicle types. But at least DELETE FROM busses WHERE id = ...; does what you would expect.

In my use case, I have two types of tokens: short-term sing-in PINs and non-expiring API keys. You can generalize them as a token, but from the product perspective, they are two separate things. I implemented them both on top of a single tokens table with two changeset functions.

What @stefanchrobot has suggested is a pretty good way to tackle this problem. We usually avoid creating different tables for this problem.
But we don’t use Ecto.Enum. We use postgres enum field for fixed values and also its much faster. @cvkmohan maybe you can take a look at that.

It’s not an either/or decision. Ecto.Enum is a runtime value, which can work with many db level setups including db level enums.

I would just use embedded schemas and slap polymorphic_embed on top.

We use a very similar mechanism to polymorphic_embed , but then you have some restrictions:

1. The “child records” can only use fields valid for use in embedded schemas, i.e. no Foreign keys.
2. When you query/aggregate against the embedded fields you will need to use postgreSql’s jsonb syntax in fragments.

So as always it’s a choice of compromises:

Using @stefanchrobot suggestion puts the mess in the schema but keeps things clean in the code and ecto expressions.
Or using @dimitarvp suggestion keeps the schema clean and can bring many of the nosql benefits to your design at the cost of query complexity, and possibly a performance hit and some restrictions to your design.
Either way good use of ecto’s changesets makes implementing choice much easier, interesting, safer and a lot of fun.

Finally there is the third choice: Use PostgreSQL inheritance, and when you are doing polymorphic querying use a case expression to prevent slicing the returned child objects.