проблема с транзакциями в миграции

[marsden]

Согласно документации

Самый простой способ реализации транзакций миграций это прописать код миграций в методы safeUp() и safeDown(). Эти два метода отличаются от методов up() и down() тем, что они неявно заключены в транзакции. В результате, если какая-либо операция в этих методах не удается, все предыдущие операции будут отменены автоматически.

Однако, уже не первый раз нарываюсь на примерно такое

Код: Выделить всё

    public function safeUp()
    {
        $this->addColumn('{{%zn_worker}}', 'work_guid', $this->string(36)->notNull());

        // creates index for column `guid`
        $this->createIndex(
            '{{%idx-zn_worker-work_guid}}',
            '{{%zn_worker}}',
            'work_guid'
        );

        // add foreign key for table `{{%zn_work}}`
        $this->addForeignKey(
            '{{%fk-zn_worker-work_guid}}',
            '{{%zn_worker}}',
            'work_guid',
            '{{%zn_work}}',
            'guid',
            'CASCADE'
        );
        

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

[ElisDN]

Это особенность транзакций в разных СУБД. Транзакции для запросов изменения схемы работают с откатом в PostgreSQL. В MySQL они работают только для данных, а при запросах на схему они автокоммитятся.

[marsden]

Спасибо за подсказку, печально, что об этом в документации ни слова.
Вообще, документация в последние годы во многих проектах умалчивает о многих нюансах, как в данном случае. В результате приходится тратить много времени на поиск решения, в данном случае у меня ушло полдня на отладку миграции по причине незнания такой особенности MySQL. Придется менять паттерн на try-catch

[ElisDN]

В документации в примечании указано:

Примечание: Не все СУБД поддерживают транзакции. И некоторые запросы к базам данных не могут быть введены в транзакции. Для различных примеров, пожалуйста, обратитесь к негласным обязательствам. В этом случае вместо этих методов вы должны реализовать методы up() и down().

А так обычно исходники документации инструмента выложены в репозитории. И вы можете сами её исправить, отправив Pull Request.

[marsden]

Да, сказано. Вместо того, чтобы в тех же примечаниях описать особенности MySQl как наиболее популярной субд на хостингах дается ссылка на тот же mysql. В этом и проблема современной документации - сплошные ссылки, из которых достаточно сложно собрать в единое целое. Когда я изучал паскаль в дремучем 87-м, таких проблем не было )))
Вообще, достаточно полистать форум, чтобы понять, что с докой что-то не так. Большинство вопросов так или иначе освещены в документации, но люди все равно не понимают, как сделать то или иное. Как говорит МихМих - может, в консерватории что-то подправить?

[samdark]

Мы только за если поправите. Документация полностью открытая, pull request приветствуются.