Summer Sale! All accounts are 50% off this week.
Hi! We are using TenancyforLaravel for a multitenant application. I have set up a separate test db for testing, with seeders, and so on. I have some problem with cleaning up the db. This is my tearDown:
public function tearDown(): void
{
config([
'tenancy.queue_database_deletion' => false,
'tenancy.delete_database_after_tenant_deletion' => true,
]);
$this->tenant->delete();
parent::tearDown();
}
My problem is: I use DatabaseMigrations trait, so the teardown is looking for the migrations table of the deleted tenant db. If i do not use migrations and wanna solve it myself by calling: Artisan::call('migrate:rollback');
at the tearDown, The first tests passes ok, but then at the second one I get an error saying that the tables are already created. What is the proper way of running migrations, seeding, and then deleting tenant db and tables?
First of all you really should rethink the use of one database per tenant since it over complicates things and is totally unnecessary. It's much better to use only one database and add tenent_id to the necessary tables.
As for your problem one way is to but the deletion of the tenant in the DatabaseMigration trait
$this->beforeApplicationDestroyed(function () {
$this->artisan('migrate:rollback');
//Drop the database here
@Tray2 Thanks for your response, it just led me to the solution. Yes, I use one central db, and a separate tenant db is generated. I removed the DatabaseMigration trait and used migrate:fresh at the setup, this way it work now, thank you!!
@Y-collective Then please mark my reply as best.
Hi @tray2
I noticed on a couple of your responses that you strongly advocate for single-database architecture. Would this still be the case if each client already has their own database and we're trying to merge multiple installs of the same app into one multi-tenant application?
@marcus_sugarcoated This is a really good question.
It is always harder to merge several databases into one, than split one into multiple.
I would strive towards a single database, but it all depends on the database model and it's data. If it's a pretty straight forward database where only have a couple of relationships, then it wouldn't be too hard to keep the integrity of your users data, but if it's a more complex model, well then it will be much trickier.
If it is a rewrite of the application, including the database model, then I would merge them, but if you are only thinking of merging the data, and make it multi-tenant then it would depend more on the timeframe, the sensitivity of the data, and the complexity of the data-model.
If you have the time and knowledge to merge, then it's a good option, if you don't have it, I would suggest sticking with seperate databases (schemas) on the same database server.
Merging data and keeping the integrity is a tricky business, and it needs to be perfromed in individual steps, and every step needs to include a backup.
Sorry to not being able to give you a straight answer, it just depends on the level of complexity in the data, and your knowledge about SQL.
Please or to participate in this conversation.