А как обеспечивать строгое соответствие состояний базы ревизиям клиентского кода? (тяжелые случаи типа split-brain рассматривать стоит отдельно) Имхо на текущий момент ничего лучше механизма rails-style обратимых миграций пока нет
Это все таки отдельная архитектура, а не обобщенный инструмент ведения всех изменений=) Посмотрел Ruby немножко, решение очень классное, не въехал в некоторые детали. Изменения в самой хранимой процедуре как они держат? Хранимки ведь могут быть ведь очень специфическими.
Суть в том, что напрямую в базе изменения запрещены, на каждое изменение создается "миграция" - по сути это пара любых действий над базой, упрощенно - одно из них приводит базу в состояние N из N-1, другое - обратно (если обратного нет - то миграция необратимая) Код миграций хранится в VCS вместе с кодом приложения, а в базе есть служебная таблица с данными о том, какие миграции над базой проводились. Соответственно можно легко приводить базу в нужное состояние для нужной версии кода. Причем это общее решение для схемы и данных (например вполне нормальными считаются миграции типа "перелить все данные с конвертацией формата в другую таблицу, а первую грохнуть"), покрывает не только хранимки.
Comments 4
(тяжелые случаи типа split-brain рассматривать стоит отдельно)
Имхо на текущий момент ничего лучше механизма rails-style обратимых миграций пока нет
Reply
Посмотрел Ruby немножко, решение очень классное, не въехал в некоторые детали. Изменения в самой хранимой процедуре как они держат? Хранимки ведь могут быть ведь очень специфическими.
Reply
Код миграций хранится в VCS вместе с кодом приложения, а в базе есть служебная таблица с данными о том, какие миграции над базой проводились.
Соответственно можно легко приводить базу в нужное состояние для нужной версии кода.
Причем это общее решение для схемы и данных (например вполне нормальными считаются миграции типа "перелить все данные с конвертацией формата в другую таблицу, а первую грохнуть"), покрывает не только хранимки.
Reply
Reply
Leave a comment