Tenant makes it easier to write multi-tenant applications with Ecto.
It uses Ecto’s prefix support to create and separate tenant data. Tenant also provides migration helpers to allow one to migrate tenants, either en masse or one at a time. In addition to “offline” migrations, the migrator be used to check the migration status and if needed upgrade individual tenants at runtime, such as when a user first accesses a specific tenant’s data.
The following mix tasks are provided as part of the library:
mix tenant.gen.migration # Generates a new tenant migration for the repo
mix tenant.migrate # Runs the repository tenant migrations
mix tenant.migrations # Displays the repository migration status
mix tenant.mysql.install # Generates a migration for the tenant table in the default database
mix tenant.rollback # Rolls back the repository tenant migrations
Supports any database with Ecto prefix support, including PostgreSQL and MySQL/Mariadb.
This is a revival on the venerable Triplex library which stopped seeing updates in 2019. It was clear that there remained interest as PRs kept rolling in, and several were still using it in production. A fork and rename was necessitated as we were not able to get a hand-over of the Triplex package on hex.pm.
All the same, a big thank-you to ateliware for developing and releasing this library that so many of us have used, and everyone who contributed PRs over the years to keep it alive.
Porting from Triplex is as simple as possible: replace all instances of Triplex and triplex with Tenant and tenant in your code and configuration.
Earlier this year I also tried to take over an abandoned Hex package name and went through the recommended process of reaching out to the owner, cc-ing Hex in my email, and waiting 30 days for any response.
In my case, the name was arguably squatting as the code has been removed from GitHub and it only had ever had a hello/1 function that returned :world. It was a clear cut case according to Hex’s rules.
In your situation, did Hex disagree to the transfer? I guess I was expecting some kind of automated reply from Hex after 30 days and didn’t follow up directly with them about next steps.
Quote: “If the owners are unresponsive you will gain access to the name after 30 days if the Hex team agrees to your request.” Yeah, I guess I should have followed up again with support@hex.pm.
I’ve taken over a package through this protocol before (the previous maintainer passed). They did agree, but there was no automated reply and they did take longer than 30 days after I notified them—but within 60, and after follow-up, IIRC.
The author is still around and active elsewhere, but was in a strange situation where they were the package owner on hex.pm, but it was an ateliware project and they no longer work there. They weren’t sure if they should transfer ownership due to that … and when they reached out to ateliware on Whatsapp, I never heard back again.
So it is in a really strange sort of limbo situation: the author isn’t really gone, but they also aren’t fully sure what to do. We talked about this back and forth for a couple of weeks and while it isn’t the solution I was hoping for, they were responsive and transparent about the situation. Just one of those things.
It doesn’t have anything out of the box, but it would work well with it. This and a couple of other features (there’s a person working on SQLite support, for instance) were why I really wanted to revive development properly.
BTW, if you’d be interested in working on scopes support, even if it was simply documentation for “how to make it work”, I’d be happy to offer help and support, and would certainly review and test such a PR
