Multitenancy with Ecto

If you immitate the Ecto.Repo behaviour, just with a pid as first parameter everywhere needed this would be just as brittle as the MyApp.Repo api. Not sure why you’d feel one is more brittle than the other.

What I meant was that if the Ecto internal API changes (Ecto.Adapter.Schema and the sorts), it would break my app, which is different from the public API.

But is that the approach you would recommend? What issues are there with using put_dynamic_repo that I’m missing?

Why would you need to depend on ecto internal api? The public api of ecto doesn’t change without a major version bump and your wrapper could just manage the “dynamic repo” without making callers be concerned with it.

Ok, let me share some code to ensure we’re talking about the same thing:

defmodule MyApp.DynamicRepo do
  def insert(pid, struct, opts \\ []) do
    Ecto.Repo.Schema.insert(pid, pid, struct, opts)
  end

  def update(pid, struct, opts \\ []) do
    Ecto.Repo.Schema.update(pid, pid, struct, opts)
  end

  def delete(pid, struct, opts \\ []) do
    Ecto.Repo.Schema.delete(pid, pid, struct, opts)
  end
end

Something like this. is Ecto.Repo.Schema considered public? Also, it means that every call to Ecto needs to use this wrapper.

Regardless of the brittleness or not, is this the preferred approach for multitenancy with multiple databases?

Nope
https://github.com/elixir-ecto/ecto/blob/5ec093becad402903774aa5c28e17fdfff9d7f2a/lib/ecto/repo/schema.ex#L4

Therefore you should rather make it so that your wrapper sets a dynamic repo on each call, like this:

def insert(pid, struct, opts \\ []) do
  current = MyApp.Repo.get_dynamic_repo()
  MyApp.Repo.put_dynamic_repo(pid)
  MyApp.Repo.insert(struct, opts)
  MyApp.Repo.put_dynamic_repo(current)
end

Dynamic repo support was added for the usecase of multiple dynamically setup repos, so yes.

May I clarify what constitutes a database in this context? For example, a Postgres server can host multiple databases and therefore only one Repo would be necessary. But perhaps you are referring to different servers (rather than databases) which would require multiple Repos.

Ah, yes. It might need to run in different servers, yes.

Ah, I see. Why do you think this is best that put_dynamic_repo at the beginning of the request, which would affect all Ecto calls?

Because this will leave the current dynamic repo for processes intact. You could skip it if you’re not using Ecto directly anymore. Otherwise afaik this is all you can do using public api.

My clients are currently doing the same things. I did an initial sketch of this, and our current draft is to use a small wrapper around put_dynamic_repo at the top-level context functions. Basically each top-level context function would have to do something like Tenant.with(tenant_id, fn -> do_something end). Given their usage patterns, perhaps we end up setting a global default from some phoenix plug or absinthe middleware, b/c a single request handler doesn’t have to deal with multiple tenants, so there should be no risk in working with a wrong db.

As an aside, there was a small bug in EctoSandbox which didn’t honor the dynamic_repo setting. The fix has been merged and I think it will be included in the upcoming Ecto 3.5.0.