You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please add an option to purge the database before restoring a backup: drop all tables, views, stored procedures etc. but NOT user permissions for the database (i.e. NOT drop database and recreate!).
Rationale: the "backup, migration FAIL, restore" work cycle. Laravel migrations, with their DREADED AND CURSED inability to recover from failures properly, eventually force every laravel programmer to employ some kind of database backup/restore solution so that the database can be backed up before every attempt at artisan migrate and restored when the migration fails due to a stupid coding mistake in the newest migration file. The whole point is to be able to restore the database to the EXACT same state as before the attempted migration. Currently if the migration creates some tables then these tables will still be there after restoring the backup, and a subsequent attempt at migration will fail because those tables already exist. The whole point is to avoid this DREADED AND CURSED scenario.
The text was updated successfully, but these errors were encountered:
Please add an option to purge the database before restoring a backup: drop all tables, views, stored procedures etc. but NOT user permissions for the database (i.e. NOT drop database and recreate!).
Rationale: the "backup, migration FAIL, restore" work cycle. Laravel migrations, with their DREADED AND CURSED inability to recover from failures properly, eventually force every laravel programmer to employ some kind of database backup/restore solution so that the database can be backed up before every attempt at artisan migrate and restored when the migration fails due to a stupid coding mistake in the newest migration file. The whole point is to be able to restore the database to the EXACT same state as before the attempted migration. Currently if the migration creates some tables then these tables will still be there after restoring the backup, and a subsequent attempt at migration will fail because those tables already exist. The whole point is to avoid this DREADED AND CURSED scenario.
The text was updated successfully, but these errors were encountered: