Umbrella, repo app and migrations


I want to create an umbrella app with the following apps:

  • router: routes incoming requests to web or web_app
  • web: serves a REST api
  • web_admin: serves a REST api, but only for admin
  • repo: has an ecto repo, shared by web and web_admin

The idea is that both web and web_admin will use the repo app (that actually has an ecto repo) to access the database. Also, with time, more and more apps will be added to the umbrella.

I already configured the :ecto_repos in the config.exs for both web and web_admin, and the application is running.

My goal is to setup migrations inside the projects, not int the repo project.

However, when I try to create an ecto migration from web or web_admin apps, the migration is being created inside the repo app, not the original app. If I move the the priv/ folder from repo to the original application and then run mix ecto.migrate, ecto complains that the project doesn’t have any migrations.

So, now I have some questions:

  • Is this the expected behaviour? Can I configure it to do something different?
  • Should each app have its own repo?
  • If each app had a repo, can I at least share the connection pool and configs?

Thanks in advance!

1 Like

@msramos Have you found a solution?

I have a similar setup, the only solution I found so far, was to create an empty priv/repo/migrations directory inside the repo app, just to disable the warning…

1 Like

@webdeb I think I’m missing something about the setup here; I don’t understand why the two API apps would need different migrations if they’re sharing a single repo and database.

The apps are sharing the repo, yes… but they are serving different purposes. The Repo is just the DB-Connection. It’s not only the APIs, but imagine you are building an application for Chat only. So it maybe makes sense to put the migrations for the Chat there (Conversation, Message… etc.).

It doesn’t make sense to have migrations on each other app, migrations are tightly coupled to the DB schema (do not confuse with Ecto schemas), so they should be located where the Repo is (the repo app in this specific case).

If you need separate services (think microservices) then you should have different repos, migrations and DBs for each app.

I believe that 2 different apps declaring the BD shema is an error, you should handle all of that inside the app with the Ecto (and ecto_sql in this case) dependency.

Then from the other apps you can just consume your DB service. Other apps should not know about the implementation details behind it.