Don’t be scared of using the same table for different schemas in Ecto
Back when phoenix 1.4 was released and contexts were introduced a lot of questions arose around where to put what. For example, if I have an authentication layer for a blogging engine, should the user schema be put in the authentication context or in the blog context?
When you think about it a user has to be in the authentication layer as it is the user that we’re authenticating, but it also has to be part of the blogging engine as users should be authors of articles.
This creates a bit of a problem as wherever we decide to put the user schema, it’ll depend on things in the other context. While this doesn’t seem to be such a big deal it will make it harder to separate if we ever want to extract the authentication layer to its own service. Unless…
Defining multiple schemas on the same database table
We often tend to think that one table in our database refers to one model, or one schema depending on the pattern of our choosing. If we were to talk about things like we do in privacy, we’d probably agree on the fact that we shouldn’t make more information available than the absolute minimum that is required to do a specific task.
If we would apply that to our codebase we’d pretty come to the conclusion that an authentication layer does not have to know about which articles a certain user has written. At the same time a blog shouldn’t have access to the encrypted password of our user.
Since an Ecto schema only operates on properties that are explicitly being
set in the
schema definition we can isolate the bare minimum of data in
different our different contexts bu simply defining them as separate schemas:
defmodule Authentication.User do use Ecto.Schema schema "users" do field :email field :password end end
defmodule Blog.Author do use Ecto.Schema schema "users" do field :first_name field :last_name has_many :articles end end
By doing this we can keep the different parts of our system fully isolated and layer our application in an onion similar API. This way we as developers won’t have to know anything about the internals of another context.