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?
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.transact or 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.
You can put repo-related utility functions in there like the above transact(). In one of my projects I put an explain_all() function in there (which simply calls explain(:all, ...)) just to make it easier to quickly debug a query.
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 Repo modules 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 for soft_delete. However many projects does not use this and other potential features that fit well in Repo module.
For those reasons Repo modules 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.
I have some stuff like this but like to wrap in if Mix.env() != :prod do to ensure they don’t leak into production code. Repo.first is another one I usually throw in there (for dev/test only).
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.
