Fl4m3Ph03n1x
Background
I created a default Phoenix application with Ecto using PSQL as a database. In this basic project I noticed there is a file under my_app called MyApp.Repo, which is basically empty:
defmodule MyApp.Repo do
use Ecto.Repo,
otp_app: :my_app,
adapter: Ecto.Adapters.Postgres
end
Problem
My first reaction was, “this is the file where I will place all my CRUD operations”.
But after some thinking, I realized this was not a great idea.
Simple as this project may be, I will have different flows that will do different things. I will have some functionality to create reserves, other to update clients, other for the products they buy …
Putting it all in one place would only create a big ball of mud.
Questions
So this led me to a couple of questions regarding Elixir and its standards:
- What are we supposed to put on this file?
- Is there a community standard for how you organize a project in regards to how you access the database?
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Elixir, Erlang & messaging conferences from Code Sync. Next up: ElixirConf US (10–11 Sep) & Code BEAM Europe (21–22 Oct), Haarlem + online.
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.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
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 8- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
D4no0
I would generally advice to not put anything in this file.
The main scope of this file is to simply generate the necessary repo functions based on the features provided by your underlying database engine, hence why it’s defined here and not in the application config. For example if you are using a database that doesn’t support transactions, calling
Repo.transactor similar functions will raise a compile-time warning, making it easier to make sense of it.The only exception I can see where it would make sense is if you are planning on adding additional core functionality for your repo that is not supported out of the box and requires you manually calling the adapter functions.
sodapopcan
Furthermore, there are also callbacks which go in this module.
APB9785
jam
Looks like this may be coming soon to Ecto Add Repo.transaction_with/2 by wojtekmach · Pull Request #4577 · elixir-ecto/ecto · GitHub
garrison
You can put repo-related utility functions in there like the above
transact(). In one of my projects I put anexplain_all()function in there (which simply callsexplain(:all, ...)) just to make it easier to quickly debug a query.See the contexts guide.
Eiji
At first time it looks empty and useless as “nothing fits there” at least better than in other places. However that’s because we don’t see many things.
As mentioned by others lots of the code is generated, so in fact
Repomodules brings lots of useful features out-of-the-box with almost no code.Secondly
Repo-specific functionality (of course except said generated functions) is rare. For example one of the things you can put there is a logic forsoft_delete. However many projects does not use this and other potential features that fit well inRepomodule.For those reasons
Repomodules may be a bit confusing, but the deeper you go the more you find. It’s like an untouched mountain full of gold that’s just waiting to be discovered.sodapopcan
I have some stuff like this but like to wrap in
if Mix.env() != :prod doto ensure they don’t leak into production code.Repo.firstis another one I usually throw in there (for dev/test only).sbuttgereit
Remember that innocent line,
use Ecto.Repo, is itself bringing a large amount of functionality into the module filling out much of the typical purpose of the module. For many, that’s going to be sufficient on its own without needing to go further.In an application I’m working on, I’ve actually got a fair amount of code there… but I’m also a bit off the standard Ecto implementation. My application uses dynamically defined and started datastores (meaning at runtime), so the Repo doesn’t really represent a single database in my application, but rather is the means by which to start, stop, and manage multiple repositories. So putting this management code in the Repo module makes sense with this broader definition. But again, most won’t have that.
In the end, I’d just leave you with… if you don’t have any specific, clear need of anything that’s best represented as being part of your “datastore”… don’t sweat it: those few lines are just fine and will take you far. Once there’s a real reason to put something there, you’ll likely be feeling it.