How can I use dynamic repo without default repo?

I’m trying to apply dynamic repo to my SaaS project.
This project reads the customer’s database to retrieve data.

I followed Replicas and dynamic repositories — Ecto v3.8.4.

defmodule MyApp.Dynamic.Repo do
  use Ecto.Repo, ...

  def with_dynamic_repo(credentials, callback) do
    default_dynamic_repo = get_dynamic_repo()
    start_opts = [name: nil, pool_size: 1] ++ credentials
    {:ok, repo} = MyApp.Repo.start_link(start_opts)

    try do
      MyApp.Repo.put_dynamic_repo(repo)
      callback.()
    after
      MyApp.Repo.put_dynamic_repo(default_dynamic_repo)
      Supervisor.stop(repo)
    end
  end
end

But it throws errors without starting the repo on the application.

defmodule MyApp.Application do
  use Application

  @impl true
  def start(_type, _args) do
    children = [
      # MyApp.Dynamic.Repo
    ]

    Supervisor.start_link(children, strategy: :one_for_one, name: MyApp.Supervisor)
  end
end

But I don’t have a default database for that repo, so I can’t start the repo on application.
Should I run a database to use dynamic repo?

1 Like

What errors does it throw?

1 Like

It throws repo not started error.

** (RuntimeError) could not lookup Ecto repo MyApp.Dynamic.Repo because it was not started or it does not exist

The reason why the application doesn’t have a default repo is that it will supports many kinds of RDBMS like MySQL, MSSQL.
I think it’s not a good solution that makes dummy databases for each RDBMS.

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:

import Config

config :msbms_syst_datastore,
  ecto_repos: [MsbmsSystDatastore.Runtime.Datastore]

(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
  @moduledoc false

  use Ecto.Repo,
    otp_app: :msbms_syst_datastore,
    adapter: Ecto.Adapters.Postgres

[CLIP]

end 

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 config.exs file.

This particular application has no “MyApp.Application” module nor does it start anything up special.

Are you configuring anything at compile time?

1 Like

Full disclosure, I’m drunk and didn’t read this entire thread, but…

Should I run a database to use dynamic repo?

Yes. We have a multi-tenant app. We have one Postgres database that has a clients table which basically has a mapping of {client_name: database_instance}. This database is a “normal” Ecto.Repo.

Each “shard” (aka client specific database) is also a normal Ecto.Repo, and all of them have to be started up on application boot.

defmodule Datastores.Shard.Supervisor do
  @moduledoc false

  def child_spec(config) do
    %{
      id: __MODULE__,
      start: {__MODULE__, :start_link, [config]},
      type: :supervisor
    }
  end

  def start_link(config \\ []) do
    Datastores.Shard.dynamic_repos()
    |> Enum.map(fn name ->
      config = Keyword.merge(Datastores.Shard.config(name), config)
      %{
        id: {Datastores.Shard, name},
        start: {Datastores.Shard, :start_link, [config]}
      }
    end)
    |> Supervisor.start_link(strategy: :one_for_one, name: __MODULE__)
  end

  def stop do
    Supervisor.stop(__MODULE__)
  end

end

So once all the “shards” are started, then you can use get_dynamic_repo to reference them.

Happy to help more once I’m more sober. I really really like put_dynamic_repo, get_dynamic_repo, and c:default_options. Between those functions/callbacks, it’s pretty easy to make a multi-tenanted Ecto application… until you get to migrations… :wink:

1 Like