Set tenant connection when using make:migration-tenant command

[alaincodes24]

closes: #1207

Pull Request checklist

Please confirm you have completed any of the necessary steps below.

• Meaningful Pull Request title and description
• Changes tested as described above
• Added appropriate documentation for the change.
• Created GitHub issues for any relevant followup/future enhancements if appropriate.

[beesaferoot]

Hi @alaincodes24, Can you explain how this works? Because I'm a little confused. make:migration-tenant doesn't auto-create the migration script content i.e the content of the up and down functions; it just creates an empty migration script that you have to manually write the actually migration that uses the connections.

I don't see how this fixes the problem from the issue.

[alaincodes24]

Hi @alaincodes24, Can you explain how this works? Because I'm a little confused. make:migration-tenant doesn't auto-create the migration script content i.e the content of the up and down functions; it just creates an empty migration script that you have to manually write the actually migration that uses the connections.

I don't see how this fixes the problem from the issue.

Hey @beesaferoot the issue is that when you run php artisan make:migration-tenant... it creates the skeleton of a migration file as you mentioned but the connection inside that skeleton is set to micropowermanager which is misleading since if you forget to update it to be tenant connection, when the migration is ran, it will not use the right connection. Let me know if you have a better approach to this or if keeping it the way it is working is preferred. 🙏

[beesaferoot]

Hi @alaincodes24, Can you explain how this works? Because I'm a little confused. make:migration-tenant doesn't auto-create the migration script content i.e the content of the up and down functions; it just creates an empty migration script that you have to manually write the actually migration that uses the connections.
I don't see how this fixes the problem from the issue.

Hey @beesaferoot the issue is that when you run php artisan make:migration-tenant... it creates the skeleton of a migration file as you mentioned but the connection inside that skeleton is set to micropowermanager which is misleading since if you forget to update it to be tenant connection, when the migration is ran, it will not use the right connection. Let me know if you have a better approach to this or if keeping it the way it is working is preferred. 🙏

I understand it now. Thanks for the explanation.

Your current solution makes assumptions about the file name using a timestamp. Can we guarantee this to always be correct?

I was considering other possible solutions and landed with this one below. I don't fully like it, but we can guarantee it will work correctly in all scenarios.

<?php

namespace App\Console\Commands;

use Illuminate\Console\Command;
use Illuminate\Support\Facades\File;

class MakeMigrationTenant extends Command {
    protected $signature = 'make:migration-tenant {migration-name}';
    protected $description = 'Create new migration file for tenant database(s)';

    public function handle(): int {
        $stubPath = base_path('stubs/migration.create.stub');

        // Backup original stub content
        $originalStub = File::get($stubPath);

        try {
            $this->modifyStub($stubPath, $originalStub);

            $migrationName = $this->argument('migration-name');
            $this->call('make:migration', [
                'name' => $migrationName,
                '--path' => '/database/migrations/tenant',
            ]);
        } finally {
            File::put($stubPath, $originalStub);
        }

        return 0;
    }

    protected function modifyStub(string $stubPath, string $originalStub): void {
        // Replace micropowermanager connection reference to tenant connection 
        $stub = str_replace(
            'micropowermanager',
            'tenant',
            $originalStub
        );

        File::put($stubPath, $stub);
    }
}

[alaincodes24]

Hi @alaincodes24, Can you explain how this works? Because I'm a little confused. make:migration-tenant doesn't auto-create the migration script content i.e the content of the up and down functions; it just creates an empty migration script that you have to manually write the actually migration that uses the connections.
I don't see how this fixes the problem from the issue.

Hey @beesaferoot the issue is that when you run php artisan make:migration-tenant... it creates the skeleton of a migration file as you mentioned but the connection inside that skeleton is set to micropowermanager which is misleading since if you forget to update it to be tenant connection, when the migration is ran, it will not use the right connection. Let me know if you have a better approach to this or if keeping it the way it is working is preferred. 🙏

I understand it now. Thanks for the explanation.

Your current solution makes assumptions about the file name using a timestamp. Can we guarantee this to always be correct?

I was considering other possible solutions and landed with this one below. I don't fully like it, but we can guarantee it will work correctly in all scenarios.

<?php

namespace App\Console\Commands;

use Illuminate\Console\Command;
use Illuminate\Support\Facades\File;

class MakeMigrationTenant extends Command {
    protected $signature = 'make:migration-tenant {migration-name}';
    protected $description = 'Create new migration file for tenant database(s)';

    public function handle(): int {
        $stubPath = base_path('stubs/migration.create.stub');

        // Backup original stub content
        $originalStub = File::get($stubPath);

        try {
            $this->modifyStub($stubPath, $originalStub);

            $migrationName = $this->argument('migration-name');
            $this->call('make:migration', [
                'name' => $migrationName,
                '--path' => '/database/migrations/tenant',
            ]);
        } finally {
            File::put($stubPath, $originalStub);
        }

        return 0;
    }

    protected function modifyStub(string $stubPath, string $originalStub): void {
        // Replace micropowermanager connection reference to tenant connection 
        $stub = str_replace(
            'micropowermanager',
            'tenant',
            $originalStub
        );

        File::put($stubPath, $stub);
    }
}

I get where you are coming from, especially with the timestamp, but this code will produce this kind of migration below where the connection is stripped out, yet we want it to be set by default to tenant.

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return  new class extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        //
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        //
    }
}; 

[dmohns]

Hey @alaincodes24 and @beesaferoot

So the way this works is, that we provide "custom" stubs, here: https://github.com/EnAccess/micropowermanager/blob/main/src/backend/stubs/migration.create.stub

If the migration detects, that it's a "create" migration (i.e. the migrate name contains create) it will use this stub (which has hardcoded to Schema to micropowermanager.

Maybe, we can instead inherit from https://github.com/laravel/framework/blob/12.x/src/Illuminate/Database/Console/Migrations/MigrateMakeCommand.php#L12 and create our own command here?

[beesaferoot]

Hey @alaincodes24 and @beesaferoot

So the way this works is, that we provide "custom" stubs, here: https://github.com/EnAccess/micropowermanager/blob/main/src/backend/stubs/migration.create.stub

If the migration detects, that it's a "create" migration (i.e. the migrate name contains create) it will use this stub (which has hardcoded to Schema to micropowermanager.

Maybe, we can instead inherit from https://github.com/laravel/framework/blob/12.x/src/Illuminate/Database/Console/Migrations/MigrateMakeCommand.php#L12 and create our own command here?

I like the idea, has some major upsides; like customizing MigrationCreator to replace connection we can add to our stubs i.e {{ connection }}.

@alaincodes24 Do you want to look into this?