Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 44
Это называется database (schema) migrations и в гугле легко находится десяток готовых решений, как тривиальных так и весьма навороченных.
И в них решены некоторые проблемы, с которыми вам вероятно придётся столкнуться при столь прямолинейном подходе.
И в них решены некоторые проблемы, с которыми вам вероятно придётся столкнуться при столь прямолинейном подходе.
а откат как делать?
если учесть, что операция отката не всегда возможна — то оптимальнее просто сохранить дамп до операции и если что вернуть его на место.
то есть как это не возможна? 0_0"
расскажите, как бы вы реализовали операцию отката удаления поля или таблицы.
я его не буду удалять до тех пор, пока откат не потеряет смысла
в чём тогда смысл миграций, если они не выполняются?
а в чём смысл миграций, если их нельзя откатить?
смысл миграций в переезде со старой схемы на новую.
нет, их смысл — обеспечить актуальность структуры бд
актуальность это и есть смена схемы.
угу, как в прямую сторону, так и в обратную при откате
совершенно верно. через минуту после того как вы совершите удаление («я его не буду удалять до тех пор, пока откат не потеряет смысла „) вам потребуется таки вернуть всё как было ибо найден страшный-страшный баг.
ваши действия? :-)
ваши действия? :-)
если он пережил несколько релизов, значит он афайк не критичен.
баг исключительно в текущей версии продукта. в которой как раз и изменилась схема. в прошлой версии — его не было.
ну вот и что ты тогда будешь делать со своими необратимыми изменениями?
как я и говорил — просто будет возврат на бэкап. а вот что вы-то будете делать?
и потерять все данные пользователей, занесённые пока ты решал стоит ли откатываться?
а я не делаю необратимых изменений при релизе :-Р
а я не делаю необратимых изменений при релизе :-Р
ну всё, фиаско :-)
моя антагонистическая точка зрения таки проиграла. в качестве утешительного приза: назовите плиз стоящую реализацию для осуществления миграций на mysql (и ms sql) ;-)
моя антагонистическая точка зрения таки проиграла. в качестве утешительного приза: назовите плиз стоящую реализацию для осуществления миграций на mysql (и ms sql) ;-)
Не увидел в SQL коде транзакций… Процедура — атомарна?
ЗЫ: «Оперативно», говорите? А откуда тогда берутся топики про «как добавить колонку в много гигабайтную таблицу»?
ЗЫ: «Оперативно», говорите? А откуда тогда берутся топики про «как добавить колонку в много гигабайтную таблицу»?
> дампы БД не нужны — приложение целиком находиться в репозитории
Это как? Или Вы про «начальное» состояние БД?
Это как? Или Вы про «начальное» состояние БД?
Вместо подобных решений я использую проверку существования изменяемых/добавляемых полей в ALTER TABLE. Пример:
$db->sql_query(«select nocashe from `config`;») or $db->sql_query(«ALTER TABLE `config` ADD `nocashe` text NOT NULL;»);
Т.е. если поля «nocashe» в таблице «config» нет, оно будет добавлено.
С проверкой таблиц итак все давно известно: CREATE TABLE IF NOT EXISTS…
Для того, чтобы обновлять все устаревшие сайты, я использую один постепенно растущий скрипт, в который добавляю подобные команды по мере каких-либо изменений в БД. В итоге никакими средствами автоматизации пользоваться не приходится вообще.
$db->sql_query(«select nocashe from `config`;») or $db->sql_query(«ALTER TABLE `config` ADD `nocashe` text NOT NULL;»);
Т.е. если поля «nocashe» в таблице «config» нет, оно будет добавлено.
С проверкой таблиц итак все давно известно: CREATE TABLE IF NOT EXISTS…
Для того, чтобы обновлять все устаревшие сайты, я использую один постепенно растущий скрипт, в который добавляю подобные команды по мере каких-либо изменений в БД. В итоге никакими средствами автоматизации пользоваться не приходится вообще.
Для меня самое удобный инструмент по решению подобных задач — SqlYog с встроенной функцией Schema Synchronization Tool
как и svn up на боевой копии — хороший способ отстрелить себе ногу в случае неаккуратного использования.
пункт два по нумерации невыполним, когда над проектом работает несколько разработчиков, собьётся очерёдность. дифф понадёжнее.
пункт два по нумерации невыполним, когда над проектом работает несколько разработчиков, собьётся очерёдность. дифф понадёжнее.
А как поступаете, если один разработчик шлет в репозиторий 0034.users_added_balance_column.sql, а второй 0034.users_added_saldo_column.sql?
почти что rake db:migrate
Не совсем, конечно, для PHP, но все же.
Не вижу LOCK TABLES и UNLOCK TABLES.
Или не возникало такой необходимости?
Или не возникало такой необходимости?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обновление сайта, обновление схемы БД (MySQL)