Обновить
Комментарии 44
Это называется database (schema) migrations и в гугле легко находится десяток готовых решений, как тривиальных так и весьма навороченных.
И в них решены некоторые проблемы, с которыми вам вероятно придётся столкнуться при столь прямолинейном подходе.
Одно из них — liquibase, которое здесь не раз уже упоминалось
возможно я не умею эффективно пользоваться гуглом, но поиск навскидку ничего годного не показал. ткните плиз носом? :-)
это уже гораздо лучше. спасибо :-)
если учесть, что операция отката не всегда возможна — то оптимальнее просто сохранить дамп до операции и если что вернуть его на место.
то есть как это не возможна? 0_0"
расскажите, как бы вы реализовали операцию отката удаления поля или таблицы.
я его не буду удалять до тех пор, пока откат не потеряет смысла
в чём тогда смысл миграций, если они не выполняются?
а в чём смысл миграций, если их нельзя откатить?
смысл миграций в переезде со старой схемы на новую.
нет, их смысл — обеспечить актуальность структуры бд
актуальность это и есть смена схемы.
угу, как в прямую сторону, так и в обратную при откате
совершенно верно. через минуту после того как вы совершите удаление («я его не буду удалять до тех пор, пока откат не потеряет смысла „) вам потребуется таки вернуть всё как было ибо найден страшный-страшный баг.
ваши действия? :-)
если он пережил несколько релизов, значит он афайк не критичен.
баг исключительно в текущей версии продукта. в которой как раз и изменилась схема. в прошлой версии — его не было.
ну вот и что ты тогда будешь делать со своими необратимыми изменениями?
как я и говорил — просто будет возврат на бэкап. а вот что вы-то будете делать?
и потерять все данные пользователей, занесённые пока ты решал стоит ли откатываться?

а я не делаю необратимых изменений при релизе :-Р
ну всё, фиаско :-)
моя антагонистическая точка зрения таки проиграла. в качестве утешительного приза: назовите плиз стоящую реализацию для осуществления миграций на mysql (и ms sql) ;-)
мы это в ручную делаем…
слишком рутинно и подвержено человеческим ошибкам, вон люди в первом комменте говорили о наличии клёвых инструментов, правда на коммент не ответили пока :-(

ps: как же мне дороги эти кружочки слева от постов, из-за которых мой ff просто по швам трещит при рендеринге страницы
да, эти деревянные обсуждения — такая гадость… тем более реализованные через вложенные списки +_+"
Не увидел в SQL коде транзакций… Процедура — атомарна?

ЗЫ: «Оперативно», говорите? А откуда тогда берутся топики про «как добавить колонку в много гигабайтную таблицу»?
ALTER TABLE в транзакции… мсье думает, что он — в сказке?
Мьсе думает что чтение+запись из таблицы dbversions должны быть атомарной операцией.
> дампы БД не нужны — приложение целиком находиться в репозитории
Это как? Или Вы про «начальное» состояние БД?
Чего только люди не придумают, чтобы не пользовать миграции.
это и есть миграции, только наколенные.
Вместо подобных решений я использую проверку существования изменяемых/добавляемых полей в 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…

Для того, чтобы обновлять все устаревшие сайты, я использую один постепенно растущий скрипт, в который добавляю подобные команды по мере каких-либо изменений в БД. В итоге никакими средствами автоматизации пользоваться не приходится вообще.
Для меня самое удобный инструмент по решению подобных задач — SqlYog с встроенной функцией Schema Synchronization Tool
Аналогично, очень удобно, т.к. можно выбрать что залить, а что нет.
это если внешние подключения разрешены
не только, в комплект программы входит замечательный туннель на PHP (SQLyogTunnel.php)
Если сайтов много и обновлений много, то это нереально. С одним — двумя проектами можно.
как и svn up на боевой копии — хороший способ отстрелить себе ногу в случае неаккуратного использования.
пункт два по нумерации невыполним, когда над проектом работает несколько разработчиков, собьётся очерёдность. дифф понадёжнее.
А как поступаете, если один разработчик шлет в репозиторий 0034.users_added_balance_column.sql, а второй 0034.users_added_saldo_column.sql?
Не вижу LOCK TABLES и UNLOCK TABLES.
Или не возникало такой необходимости?
НЛО прилетело и опубликовало эту надпись здесь
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.