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.
zamith
sasajuric
Author of Elixir In Action
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.
0
zamith
sasajuric
Author of Elixir In Action
We set name: nil repo option, and yeah there’s no global tenant repo instance running. The set of current tenants are read from some place (in the current draft it’s the “main” database powered by a different repo which is global) and corresponding instances are started during the boot, but they are nameless so they won’t be used by default.
0
zamith
Right, that was what I was thinking. Do have any “smart” way of handling migrations so that you can have tenant only migrations, and “main” database migrations that run separately?
0
LostKobrakai
That sounds like something you could have a look at Triplex for inspiration, which handles multi-tenancy using schemas.
1
sasajuric
Author of Elixir In Action
We have some helper functions, basically wrappers around Ecto.Migrator, which first migrate the main db, then all known tenants. It’s hard to say yet if that will suffice for production, but they seem to be good enough for local dev. We defined a couple of mix aliases, such as “ecto.reset” and “ecto.migrate” to make it fit with the flow of other projects.
For tests, we precreate a single tenant db in test_helper.exs (or migrate it if the db already exists). That way, most of the tests can work on that single tenant db, and so they can run in a sandbox with async: true. There is one test module which tests dynamic addition and removal of repos, and that one has to be async: false b/c afaik db creation & migration can’t run on a sandbox.
There seems to be enough material here for a blog post, I only need to find some time to write it up 
4
zamith
When testing, where do you clean up that tenant db, since you don’t have the on_exit callback available on test_helper.exs, or am I missing something?
You can just leave it there, is that the idea?
0
sasajuric
Author of Elixir In Action
Yeah, we leave it there, which is actually good b/c we don’t have to recreate it on every test run.
1
zamith
How do you manage the connections to the DB with this approach? Each dynamic repo will create it’s own connection pool, so the connections per tenant will grow with the number of tenants. If those tenants are databases in the same database server, this can become an issue.
Do you close the connections after each call? Is there a smarter way to manage these connections?
0