Можно ли переносить данные базы данных через phinx?

Question

[kiddle]

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

Comments

[tukreb]

У любого популярного фреймворка есть свои поддержки миграций. Зачем вам этот?
И да ни кто не предоставляет 100% миграцию туда или назад, всё равно ручками придётся доправлять.

[Akina]

Посмотрел доки. По-моему, ему вообще похрен что выполнять. Не зря поддерживается pure SQL.
Да и настоящих откатов там не видать, если они не поддержаны SQL-сервером. Вернее, есть rollback, по-видимому, организованный как обычный timeline. Можно просто вернуться к старой структуре на определённый момент времени, грохнув имеющуюся. То же и с данными - опять же ему похрен что выполнять. Есть бэкап на заданную точку - вернётся, восстановив состояние и структуры, и данных, нет - значит нет.

[kiddle]

tukreb, на работе сижу за двумя проектами, один на ларавел, другой на неткат, вот для последнего посоветовали phinx

[v3shin]

Да, phinx и другие инструменты миграций нужны для изменения структуры БД. А для дампа данных используйте обычный советский... mysqldump.

[kiddle]

v3shin, спасибо большое за ответ)

[tukreb]

kiddle, ну если неткат какой само-писный CMS без симфони под капотом (что уже странно, почти все CMS уже переехали на симфони или ларку), то тогда прикрутить phinx может быть полезно, но чудес не ждите, руками придётся работать много :)

Answer 1

[mayton2019]

Типа можно накатить изменения и также безопасно откатить.

По поводу безопасного отката. Это на 99% зависит от SQL кода который вы напишете. Это никак не связано с фреймворком поддержки миграций. Берите какой угодно фреймворк. Например liquibase или flyway.

И даже в них если во время alter table rename column вы столкнетесь с активными сессиями в БД - то ваша транзакция переименования упадет и вы будете вручную решать ситуацию отката или наката.

Безопасность наката и отката также зависит от грамотности описания ваших чендж-сетов. Бывает так что в 1 чендж-сет запихивают 2 DDL команды и одна из них проходит а вторая не проходит и фреймворк повисает навсегда в клинче. Двигаться назад он не может т.к. Не был применен чендж-сет. И двигаться вперет тоже не может т.к. первая DDL команда уже выполнена и повторо ее вызывает ошибку типа "table/index already exists".

Выводы - грамотность описания чендж-сетов. И все.

Ваш фреймворк phinx выглядит ужасно с точки зрения кода. Как по мне он не делает главной задачи а именно - не является DSL для upgrade/rollback. Он - прибит гвоздями к PHP и следовательно его можно рассматривать только под углом вашего PHP-удобства. Удобен он вам? Используйте.