Why put ecto configuration in repo.ex

jmurphyweb · September 14, 2021, 2:36pm

This came up in our project and we weren’t sure why it’s done this way, maybe someone here can shed some light:

Why is it recommended to ‘inject’ ecto database configuration in &Repo.intit/2 ?

eg. hexpm project does so here:

hexpm/hexpm/blob/main/lib/hexpm/repo.ex#L89

    
      
                    cacerts: [decode_cert(ca_cert)],
                    key: decode_key(client_key),
                    cert: decode_cert(client_cert)
                  ]
                end
          
          
    opts =
                opts
                |> Keyword.put(:ssl_opts, ssl_opts)
                |> Keyword.put(:url, url)
                |> Keyword.put(:pool_size, pool_size)
          
          
    {:ok, opts}
            else
              {:ok, opts}
            end
          end
          
          
defp decode_cert(cert) do
            [{:Certificate, der, _}] = :public_key.pem_decode(cert)
            der

Why wouldn’t they look to use runtime.exs for this?

LostKobrakai · September 14, 2021, 2:46pm

Most of this code is 3 or even 4 years old, so older than support for runtime.exs.

jmurphyweb · September 14, 2021, 3:25pm

Thanks. But they do have a runtime.exs file: hexpm/runtime.exs at main · hexpm/hexpm · GitHub

So it seems somewhat intentional to leave DB configuration in repo.ex ?

My colleague also pointed out that it seems to be the suggested method in Ecto.Repo docs: Ecto.Repo — Ecto v3.7.1

Would you suggest just using the runtime.exs file for this then?

stefanchrobot · September 14, 2021, 4:17pm

I think this is mostly up to your preference. Repos and endpoints support passing the config manually so that you can have config in the same file as where it’s consumed. runtime.exs was created to cater to people who want a centralized configuration place which (unlike config.exs) supports runtime config.

I think the community will move towards runtime.exs over time.