Hi, I’m implementing a system that implements multitenancy via multiple databases. For business reasons I cannot do away with prefixes, which I’d prefer. In any case, I was able to make it work by using put_dynamic_repo, but am concerned it might be a bit too “magic”. I’m doing this with a Phoenix…

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_somet…

[image] zamith: 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. Why would you need to depend on ecto internal api? The public api of ecto doesn’t change without a major version bump and …

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) …

[image] zamith: is Ecto.Repo.Schema considered public? 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, str…

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.

Exactly, that was my thought process. My main concern is the fact that any sub process does not use the dynamic_repo. That’s why the wrapper you mention might be a good option, even though it’s more code to write every time.

[image] zamith: My main concern is the fact that any sub process does not use the dynamic_repo This is a bit annoying but I’m not particularly worried about it, because there’s no global default, so failing to set the repo will raise an exception, and this should be caught by tests.

How do you ensure that there is no global default? At the supervisor level?

Multitenancy with Ecto

Questions & Help Questions

DidactMacros April 8, 2025, 6:21am 23