I mean, where do I type Custom.DB.create_tables()? Inside here?
def start(_type, _args) do
end
I’ve tried putting it before and after Supervisor.start_link(children, opts), and in both cases, the program just crashes.
ohmyohmyohmy
LostKobrakai
So when start/2 is called your application is just beginning to start up. Your supervision tree is not yet started, which includes your repo. So calling Custom.DB.create_tables() will fail. You could run the function inside the supervision tree as well, after your repo is initialized (more flexible option) or you could run it after Supervisor.start_link, but you need to ensure to still return the result of that call from start/2. start/2 is expected to return a value according to the Application behaviour (Application — Elixir v1.20.2) and commonly that would be the result of starting a supervisor. This is to ensure the application (and often the whole vm) stops when the root process exits.
2
ohmyohmyohmy
Mmmkay. So, I don’t know if what I’m doing now is considered best practice, but this seems to get me the result I want:
def start(_type, _args) do
...
response = Supervisor.start_link(children, opts)
Custom.DB.create_tables()
response
end
1
LostKobrakai
It’s not necessarily best practice, but also not too out of the ordinary. The difference is mostly in the effects you get if your create_tables fails to work somewhere. How you want to handle that is a different question.
1
ohmyohmyohmy
Okay. Could you point me in the right direction so I can explore what NobbZ meant by the “owning process should be responsible”? I can understand that if the owning process fails, the database will be empty when it’s restarted with my current ‘solution’. What function must I write in Custom.DB to achieve that?
1
rhcarvalho
This piece of the Elixir docs talks about applications and their life cycle:
Worth knowing the underlying concept comes from Erlang, so to understand why things are the way they are you can also look into Erlang/OTP docs.
This explains the start callback:
For a custom Ecto.Repo, look at
This is the implementation of that callback when you write use Ecto.Repo in your custom module:
https://github.com/elixir-ecto/ecto/blob/v3.13.5/lib%2Fecto%2Frepo.ex#L281-L283
AFAIR there’s no “run this code on startup” hook out of the box in Ecto.Repo, but generally many possible entry points with different consequences as the other knowledgeable answers discuss.
I may be sending you off on the wrong direction as I don’t recall having to do it myself, but you can always wrap the Repo with a module you fully control and write the initialization code there, so that your supervision tree will be like MyApp -> MyApp.MyRepoInit -> MyApp.Repo.
8
ohmyohmyohmy
Thanks for that. I think my problem is my mind is stuck in my old way of thinking of programming. Obviously, Elixir, Erlang, BEAM, OTP, is a completely different tool that my mind isn’t accustomed to yet.
So, now this is my current solution:
defmodule Custom.DB do
use Ecto.Repo,
otp_app: :testing,
adapter: Ecto.Adapters.SQLite3
def create_tables do
:testing
|> :code.priv_dir()
|> Path.join("repo/testing.sql")
|> File.read!()
|> query()
end
def show_tables do
query("select * from sqlite_schema;")
end
end
defmodule Custom.DB.Init do
def start_link(opts \\ []) do
result = Custom.DB.start_link(opts)
Custom.DB.create_tables()
result
end
def child_spec(opts) do
%{
id: __MODULE__,
start: {__MODULE__, :start_link, [opts]},
type: :worker,
restart: :permanent,
shutdown: 500
}
end
end
and in application.ex:
children = [
...
{Custom.DB.Init, database: :memory, pool_size: 1}
...
]
That’s the best I’ve got. 
2
garrison
It’s not that it’s completely different. The application start is pretty analogous to a main() function in another language. The difference is just that OTP has a bunch of abstractions layered on top of that for supervising processes because that’s what it’s designed for.
You could imagine inventing a similar abstraction in Python. Creating a DBInit class that has a run() method which creates the database. And then having some code like
def main():
children = [
DBInit,
StartServer,
]
for child in children:
child().run()
It’s the same idea except we have process isolation, which is very powerful.
3
rhcarvalho
You demonstrate the curiosity to learn and figure out the new ways, you can do it!
If you’re into video content, there is a lot of videos on YouTube that can help you get a better sense of the mental model of Erlang and the BEAM, which trickle down to Elixir (and probably other BEAM languages as well).
In particular, I love the talks from Joe Armstrong, one of Erlang’s creators.
Funny thing is that Python doesn’t have a specific entry point like C or Go (func main), but will interpret all files passed to the interpreter, so it’s up to you to do something like:
if __name__ == "__main__":
main() # or any other code here
Where __main__ is a magic variable provided by the interpreter that will have the name of the current module when imported, or the string __main__for the top-level module (so the same code can observe different values for that variable depending how it was run)… but maybe that’s material for a Python forum 
4
garrison
lol I had typed up the same thing about Python but I deleted it because I figured it was too much of a distraction from my point.
Of course we can have Python in Elixir too. Just create a .exs file!
1