Laravel migration transaction

Question

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

Я создаю миграцию. Когда я заканчиваю его создание, на середине миграции возникает небольшая ошибка (скажем, ограничение внешнего ключа), которая приводит к сбою «php artisan migrate». Он говорит мне, где ошибка, действительно, но затем миграция переходит в несовместимое состояние, где сделаны все изменения в базе данных, сделанные до ошибки, а не следующие.

Это делает это, когда я исправляю ошибку и перезапускаю migrate, первый оператор терпит неудачу, поскольку столбец/таблица уже создан/изменен. Тогда единственное решение, которое я знаю, - это перейти в мою базу данных и «откат» вручную, что намного дольше.

migrate: rollback пытается откат предыдущих миграций, так как ток не был применен успешно.

Я также попытался обернуть весь свой код в DB :: transaction(), но он все еще не работает.

Есть ли решение для этого? Или мне просто нужно постоянно перекатывать вещи?



редактировать, добавив пример (не писать код схемы строителя, просто какое-то псевдо-код):
Migration1:

Create Table users (id, name, last_name, email) 

Migration1 выполняется OK. Через несколько дней мы делаем миграция 2:

Create Table items (id, user_id references users.id) 
Alter Table users make_some_error_here 

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

Если мы исправим make_some_error_here, мы не сможем выполнить миграцию, потому что созданная таблица «элементы». Мы не можем откатываться (ни обновлять, ни перезагружать), потому что мы не можем удалить пользователей таблицы, поскольку из элементов таблицы есть ограничение внешнего ключа.

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

Answer 1

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

Другим преимуществом использования этого подхода является то, что при обращении с БД у вас больше контроля и меньших шагов.

Надежда, что помогает: D

Answer 2

UPDATE: мое решение ниже фактически не работает (если вы используете Mysql, скорее всего), см комментарии. Он работает только для операторов delete/insert/update. Мой совет, как говорили другие, разделить ваши миграции на несколько миграций, которые не оставляют ничего позади, когда один не удается.

---

Я часто сталкивался с этой проблемой раньше.Решение состоит в том, чтобы начать транзакцию в начале вашей миграции, а также совершать все-таки работа сделана:

<?php 

use Illuminate\Database\Schema\Blueprint; 
use Illuminate\Database\Migrations\Migration; 

class UpdateUserTableAddColumnName extends Migration { 

    public function up() 
    { 
    DB::beginTransaction(); 

    Schema::table('user', function(Blueprint $table) { 
     // update your table here 
     $table->string('name') 
    }); 

    DB::commit(); 
    } 
} 

Если миграция не удается, база данных по-прежнему, как и до миграции. Даже таблица миграции не обновляется.

Answer 3

Это не ограничение Laravel, я уверен, вы используете MYSQL, верно?

В MYSQL документации говорит here

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

И у нас есть рекомендации самого Тейлора Otwell here говоря:

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

Answer 4

Как Евгений Афанасьев подчеркнул Тейлор Otwell, как говорят (но подход, который я уже взял себя): ваши миграции работают только на определенных таблиц или выполнить конкретную операцию, как добавление/удаление столбца или ключа. Таким образом, когда вы получаете неудачные миграции, которые вызывают несогласованные состояния, подобные этому, вы можете просто отбросить таблицу и снова выполнить миграцию.

Я испытал именно то, что вы описали, но пока не нашел пути вокруг него.

Answer 5

Я использую MySql, и у меня есть эта проблема.

Мое решение зависит от того, что ваш метод down() делает именно то, что вы делаете в up(), но в обратном направлении.

Это то, что я хожу:

try{ 
    Schema::create('table1', function (Blueprint $table) { 
     //... 
    }); 
    Schema::create('tabla2', function (Blueprint $table) { 
     //... 
    }); 
}catch(PDOException $ex){ 
    $this->down(); 
    throw $ex; 
} 

Так вот, если что-то не автоматически вызывает метод down() и снова бросает исключение.

Вместо того, чтобы использовать миграцию между transaction() сделать это между этим попробовать