Hmmm… at first I though I understood what you were asking, but looking deeper I’m less convinced I understand the issue.
I’m chiming in because I’m using dynamic repos for what may be similar purposes. I also have no default and the setup is working well for me. I’ll start from the beginning with my use case and maybe you can see how it aligns with yours. I’m also working on a multi-tenant application, but only targeting PostgreSQL. The nature of my application and its use cases/usage patterns allow me to use a database per tenant instance of the application. In addition I have a management database which controls things, but I don’t want that (or any one tenant) to be considered the “default” database or repo within the application. If a dynamic repo has not been set for the process via put_dynamic_repo, I want any attempted uses to fail. There simply is no default.
Now having said that, there are bits of the Repo I need running. So for example I do have an Ecto configuration setup in config.exs, but it’s very simple:
(assume that the
MsbmsSystDatastore.Runtime.Datastore module above is just the repo module, with
use Ecto.Repo because that’s what it is with just a different name).
The top of
MsbmsSystDatastore.Runtime.Datastore looks like:
defmodule MsbmsSystDatastore.Runtime.Datastore do
And that’s all that’s there related to Ecto.Repo. I do identify the adapter for the repo.
I believe, but am not sure, that having that configuration is sufficient for Ecto to start up things like it’s process registry and it’s own necessary components. Note that there is no database configuration beyond identifying the adaptor to use. Just the enumeration of the repo module existing. In fact, that’s the whole of my
This particular application has no “MyApp.Application” module nor does it start anything up special.
Are you configuring anything at compile time?