How to keep migrations table up to date?

[secondmanveran]

Hello, thanks for the great package.

I see you've talked about running this after every change etc., which seems like a great idea to keep the migrations up to date, but how would my production website, (or any migration table) not see these as all new migrations since the timestamp in the filename will be new each time they run, and won't be found in the migrations table.

I thought maybe just remove the IndexedTimestamp in LMG_TABLE_NAMING_SCHEME but then the files won't run in order. It seems untenable to manually update the migration table everytime code is deployed.

How would one manage this?

[bennett-treptow]

The goal with this package is to run this on your local environment, not a production environment, to be able to get an existing database down into migrations.

To do this, it would be expected that you've either exported the database structure (and maybe data) from production, and have it on your local environment as a starting point for further development.
It would make sense then to yes, not include the timestamp in the field naming scheme; something like this would suffice and would make sure order is guaranteed: LMG_TABLE_NAMING_SCHEME=[Index]_create_[TableName]_table.php

To get these migrations to not be picked up by your production deployments (aka php artisan migrate), you would need to manually insert each of the generated migration files into the migrations table on the production environment.

OR, you can update your migration file stub to only create if the table doesn't already exist, and then you can just run php artisan migrate to get those migration files into production without any tables being created that already exist.

stubs/vendor/laravel-migration-generator/table-create.stub:

if (Schema::hasTable('[TableName]')) {
    return;
}
Schema::create('[TableName]', function (Blueprint $table) {
    [Schema]
});

[secondmanveran]

The goal with this package is to run this on your local environment, not a production environment, to be able to get an existing database down into migrations.

No intention of running in production, but new files created locally will be under version control and shipped with the app.

something like this would suffice and would make sure order is guaranteed: LMG_TABLE_NAMING_SCHEME=[Index]create[TableName]_table.php

I'll give that a try.

OR, you can update your migration file stub to only create if the table doesn't already exist, and then you can just run php artisan migrate to get those migration files into production without any tables being created that already exist.

This seems like a reasonable solution to be able to update after and new migration files.

I appreciate your prompt response mate.