Исправить нарушенные миграции путем «сброса» к текущей схеме - PullRequest
Новая
       23

Исправить нарушенные миграции путем «сброса» к текущей схеме

0 голосов
/ 03 марта 2020

Мы взяли на себя старый (3 года) проект Symfony 3.3, использующий пакет doctrine -migrations 1.0 для обработки миграций. К сожалению, сценарии миграции были сломаны в течение некоторого времени, и никто об этом не заметил, поэтому вы не можете сделать сборку fre sh из исходного кода без проверки существующей базы данных.

Я хотел бы исправить ситуацию, чтобы запуск composer doctrine:migrate, по сути, просто запускает фиктивный скрипт, который создает то, как выглядит текущая схема. Как бы я сделал это, чтобы при запуске на существующих схемах он не сломался?

Я думаю, что я бы сделал что-то вроде этого:

  1. Проверьте чистый проект (с ошибочными старыми миграциями)
  2. Получите дамп производственной базы данных
  3. Создайте дамп схемы производственной базы данных в файл SQL
  4. Удалить старые миграции
  5. Создайте файл миграции с тем же номером версии, что и «текущее» / наибольшее число в ошибочных миграциях
  6. Запустите миграцию

Как На последнем шаге убедитесь, что это действительно работает, удалив базу данных, импортировав дамп производственной базы данных и запустив migrate, чтобы убедиться, что ничего не сломалось. Я просто не уверен, как это сделать в контексте пакета Doctrine (я новичок в PHP), даже после ознакомления с документацией (которая, кажется, не покрывает эту ситуацию).

1 Ответ

0 голосов
/ 20 марта 2020

Я сделал точно так, как набросал выше, и это сработало отлично. Для контекста у меня был такой набор метаданных для сценариев миграции: 

"SELECT * FROM migration_versions" 
┌────────────────┐
│    version     │
├────────────────┤
│ 20161112122228 │
│ 20161113143631 │
│ 20161122223420 │
│ 20161124162611 │
│ 20161128151448 │
│ 20161207194257 │
│ 20161208114104 │
│ 20161208114105 │
│ 20170123074229 │
│ 20170125081729 │
│ 20170130080734 │
│ 20170130080820 │
│ 20170131082751 │
│ 20170201074705 │
│ 20170208092040 │
│ 20170208092917 │
│ 20170208103930 │
│ 20170608042313 │
│ 20170628044258 │
│ 20170930061118 │
└────────────────┘

Это означает, что у меня также будет соответствующий набор файлов в app/DoctrineMigrations/, называемый вещами типа app/DoctrineMigrations/Version20170930061118.php. Только последний файл будет иметь фактическое содержимое, остальные будут пустыми пустышками.

Git журнал моих изменений

Создать фиктивный шаблон для замены содержимого существующих миграций

В какой-то момент существующие миграции перестали работать. Это было обнаружено около 1 марта 2020 года.

Это означает, что невозможно начать разработку из источника fre sh, используя команду doctrine: migrations: migrate, так как она рано запускается.

В то же время существующие базы данных содержат метаданные о том, какие миграции выполнялись в прошлом, поэтому любое исправление должно будет сигнализировать пакету миграции, что они были / были выполнены.

Предлагаемый Исправление заключается в создании простых «классов маркеров», которые просто удовлетворяют потребность сигнализировать о том, что миграции были выполнены / существуют, а затем заменяют содержимое последнего класса миграций сценарием, который просто создает схему, соответствующую любому текущему состоянию производства. база данных.

Это шаг 1.

Заменить все содержимое сценария миграции на пустое содержимое

Это шаг 2 в исправлении. В основном сделайте al oop для каждого файла в app / DoctrineMigrations /*.php и замените его фиктивным шаблоном. Это полный скрипт 

$ git show 773ccebee20425d7025152b338282f0a0034556f:app/DoctrineMigrations/create-dummy-migrations.sh
#!/bin/bash

for file in Version*.php; do 
    CLASS=$(basename $file .php)
    sed -e "s/CLASSNAME/$CLASS/" template.php > $file
done

Это полный шаблон 

git show 773ccebee20425d7025152b338282f0a0034556f:app/DoctrineMigrations/template.php
<?php

namespace Application\Migrations;

use Doctrine\DBAL\Migrations\AbstractMigration;
use Doctrine\DBAL\Schema\Schema;

/**
 * Dummy migration to fix faulty migration scripts issue 
 * discovered in March 2020.
 */
class CLASSNAME extends AbstractMigration
{
    /**
     * @param Schema $schema
     */
    public function up(Schema $schema)
    {
         $this->addSql('COMMENT ON table migration_versions IS \'migrations from 2016-2017 are stubs\'');
    }

    /**
     * @param Schema $schema
     */
    public function down(Schema $schema)
    {
    }
}

Удаление помощников

Дамп схемы из продукта

Очистить схему с помощью скрипта 

grep -v -- '--' production-schema-2020.sql \ 
  | awk 1 ORS=' ' \
  | sed -r -e 's/;\s+/; /g' > cleaned.sql

Создать Doctrine PHP операторов из SQL script

Сценарий: sed -e "s/^(.*);/\$this->addSql('\1');/" cleaned.sql > cleaned-sql-to-php-statements.txt

Перемещение операторов схемы в последнюю миграцию В основном копирование и вставка содержимого из cleaned-sql-to-php-statements.txt в

Удаление временных файлов

Незначительные корректировки и исправления сгенерированных PHP SQL операторов

...