Php artisan schema dump

Laravel Schema Dump: how to speed up your migrations?

Large or long-lived applications can have this issue, a huge list of migration files that were created more than a few years ago. These will never change again and are slowing down your tests. How can you improve this?

In Laravel 8, which will be released later this year (planned on 8 September 2020), Taylor Otwell added a new feature called «Schema Dump». This creates a dump of the current schema state using mysqldump or pgdump.

Why should you use Schema Dump

First of all, speed. When you have a lot of different migrations it takes a long to time run all those migrations for the tests. When you only have to execute one file it will save you a lot of setup time.

Also, developers want to have a clear overview of the files, folders, controllers, etc. Why wouldn’t you clean up the database migrations that already have been deployed to production? You probably don’t want to change them again, especially when it’s more than a year ago.

How to use Schema Dump

The command can be called using:

// Dump the current database schema and prune all existing migrations. php artisan schema:dump --prune

Please note, at this moment it is only available for the MySQL, PostgreSQL, and SQLite databases.

Interested in how this feature works behind the scenes? Check out the pull request on Github via https://github.com/laravel/framework/pull/32275.

Migration Squashing

In the upgrade guide to Laravel 8 it’s referenced as «Migration Squashing».

Taylor Otwell created this pull request and wrote this about the feature:

This PR adds support for a new php artisan schema:dump command which uses mysqldump or pgdump to dump the current state of your schema to a database/schema/-schema.mysql file.

When this file exists and php artisan migrate or php artisan migrate:fresh is run AND no migrations have run against the database yet (migrations table is empty), this schema file will be loaded into the database first and then any outstanding migrations will be run. This means that effectively this schema file would typically only ever be used during local development or during CI testing. In production, you would typically already have migrations that have run in the past so this schema file would never be triggered.

The official documentation for Laravel 8 Squashing Migrations, this can be found on https://laravel.com/docs/8.x/migrations#squashing-migrations.

Follow me on Twitter, there I post web-related content, tips/tricks, and other interesting things.

On my blog, you can find articles that I’ve found useful or wanted to share with anyone else.

If you want to know more about this article or just want to talk to me, don’t hesitate to reach out.

Источник

Восстановление базы (миграции и сидеры) из файла .sql

Со временем папка с миграциями в Ларавел разрастается. Особенно, если проект переведен в продакшн, и изменения в базе делаются не в одной миграции, а добавлением новых миграций, чтобы не попортить работающую версию.

Для того, чтобы сделать «отбивку», и убрать из папки миграций все старые миграции, в Ларавел придумали специальную команду:

php artisan schema:dump --prune

В первом случае будет создан дамп всех миграций, во втором — после создания дампа все использованные миграции будут удалены, и можно продолжать писать новые.

Обычная команда php artisan migrate или php artisan migrate:fresh сначала восстановит дамп, а потом перейдет к обработке файлов миграций в папке \database\migrations.

Также, в частном случае, при создании дампа миграций можно указать, какую базу мы используем:

php artisan schema:dump --database=pgsql

С миграциями разобрались, все отлично. Но что делать, если хочется, чтобы из дампа восстанавливались не только миграции, но и какие-то демо-данные, уже занесенные в базу. Например, через административный интерфейс, а не через сидер.

При стандартном восстановлении такие данные пропадут, и восстановятся только те, что заносятся в базу через сидер.

Но выход, естественно, есть.

Во-первых, кто-то скармливает сидеру файлы .sql. Это полезно, если вы где-то на гитхабе надыбали базу городов, например, и хотите ее занести в свою базу. Делается это просто (в сидере), но я сейчас не об этом (может, напишу отдельно как это сделать).

Сейчас я хочу именно восстановить всю свою базу в полном объеме вместе с данными, используя простую стандартную команду php artisan migrate:fresh.

Для этого давайте посмотрим, что получается в результате отработки команды по созданию дампа миграций.

1. Формируется папка \database\schema, если ее еще нет.
2. В этой папке создается файл mysql-schema.dump, в котором содержится обычный мускульный дамп.

Т.о., если мы хотим «отбиться» с сохранением как структуры, так и данных базы, то мы делаем следующее:

1. Создаем папку \database\schema.
2. Создаем в этой папке файл mysql-schema.dump.
3. Экспортируем (делаем дамп) нужную базу, например через PhpMyAdmin.
4. Открываем сформированный экспорт в текстовом редакторе и копируем все его содержание.
5. Открываем в текстовом редакторе файл \database\schema\mysql-schema.dump и вставляем в него все, что мы скопировали в буфер.
6. Сохраняем файл mysql-schema.dump.
7. Из папки \database\migrations удаляем все миграции, поскольку они у нас все содержатся в дампе, дальше будем писать только новые, не вошедшие в дамп.
8. Из файла \database\seeders\DatabaseSeeder.php, удаляем строки ранее использованных сидеров (потому что данные из них уже содержатся в базе, в сидер будем добавлять только те, что сформируем после «отбивки»).

Теперь осталось восстановить структуру базы данных со всеми находившимися в ней до этого данными простой стандартной командой Ларавел

В идеале, все должно сработать, если возникнут синтаксические ошибки, вызванные тем, как конкретная используемая версия PhpMyAdmin делает экспорт, правим их в файле дампа.

Вот и все дела. В любой момент можно сделать «отбивку», и переходить на следующий этап работ, как «с чистого листа».

Всем красивого кода и удачных разработок,
Сэр Эндрю Готэм

Источник