Начните с допустимого состояния данных
В нашем вымышленном приложении новая заявка обязательно должна иметь стартовую задачу. Значит, допустимы два исхода: обе записи появились или не появилась ни одна. Состояние заявка есть, задачи нет считается ошибкой, даже если первая операция технически выполнилась успешно. Это правило нужно сформулировать до написания обработчика. Оно объясняет, зачем объединять запросы. Если же действия независимы, общая транзакция может быть лишней. Не стоит включать в неё весь длинный пользовательский сценарий только потому, что операции расположены рядом в одном файле.
Разберитесь с управлением PDO
При обычном подключении PDO работает в режиме автоматической фиксации: запросы не объединяются сами собой в одну общую операцию. Для явной транзакции вызывают beginTransaction. Успешное завершение обозначают commit, отмену ещё не зафиксированных изменений — rollBack. При этом база и используемые таблицы должны поддерживать транзакции. Проверка возможностей драйвера не заменяет проверку реального окружения. Отдельно настройте и проверьте обработку ошибок: исключение должно приводить к понятному пути завершения, а сообщение об успехе нельзя выдавать до успешной фиксации. В журнале ошибки должно быть достаточно сведений для диагностики, без публикации секретов подключения.
Не путайте данные, структуру и внешние действия
Изменение структуры базы требует отдельного внимания. Некоторые СУБД, включая MySQL, могут выполнять неявную фиксацию при командах создания или удаления таблиц. Поэтому обещание откатить всё после произвольной миграции неверно. Поведение нужно проверять для конкретной СУБД и конкретных команд. Есть и другая граница: откат базы не забирает уже отправленное письмо и не отменяет автоматически действие стороннего сервиса. На бумажной схеме полезно выделить изменения в базе и внешние действия разными группами. Для их согласования требуется отдельное проектное решение. Простого добавления rollBack к обработчику недостаточно.
Проверяйте специально созданный сбой
Проверка только успешного пути почти ничего не говорит о защите от половинчатого результата. На изолированных тестовых данных создайте управляемую ошибку между первой и второй записью. Затем проверьте базу отдельным чтением после завершения обработчика. Важно увидеть отсутствие обеих записей, а не только сообщение об исключении. Повторите обычный успешный сценарий: должны появиться обе связанные записи. Не смешивайте такую проверку с экспериментами на рабочей базе. И не считайте транзакцию полной защитой от повторной отправки формы или конфликтов одновременных запросов: эти ситуации требуют собственных правил и проверок.
Попробуйте на практике
Спроектируйте проверку транзакции для создания заявки и стартовой задачи. Задание можно выполнить на бумаге; запуск допустим только в отдельной тестовой базе.
- Опишите две связанные записи и правило, которое запрещает существование одной без другой в этом сценарии.
- Отметьте начало транзакции, место успешной фиксации и путь обработки ошибки до фиксации.
- Добавьте управляемую ошибку после первой записи и сформулируйте ожидаемое состояние базы после отката.
- Предусмотрите независимое чтение результатов для ошибочного и успешного сценариев.
- Вынесите изменения структуры, письма и сторонние запросы в отдельный список, чтобы не приписывать им действие отката базы.
Как проверить результат. Для успешного запуска ожидаются две связанные записи, для сбоя до фиксации — ни одной. В плане указаны СУБД, поддержка транзакций и способ проверки фактических данных.
Частые вопросы
Можно ли откатить изменения после commit?
Обычный rollBack не отменяет уже зафиксированную транзакцию. Для исправления потребуется отдельная операция с собственными правилами и проверкой последствий.
Почему исключение ещё не доказывает правильный откат?
Оно сообщает о сбое выполнения. Правильность результата подтверждает проверка состояния данных с учётом поддержки транзакций и возможных неявных фиксаций.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.