msramos
Hello,
I want to create an umbrella app with the following apps:
- router: routes incoming requests to
weborweb_app - web: serves a REST api
- web_admin: serves a REST api, but only for admin
- repo: has an
ectorepo, shared bywebandweb_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!
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Bringing learning, work and compliance together since 1987.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
webdeb
@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/migrationsdirectory inside therepoapp, just to disable the warning..al2o3cr
@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.
webdeb
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.).
pggalaviz
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.