История изменений
Исправление paddlewan, (текущая версия) :
Пойду, почитаю.
Смотри, как это работает. Создаем файл, который накатывает разом все необходимое. Скажем,
0001-add-columns.sql
В нем пишем изменения:
-- +goose Up
-- +goose StatementBegin
alter table1 add column col(id serial, data text);
add or replace function x .... ;
-- +goose StatementEnd
-- +goose Down
-- +goose StatementBegin
drop function x;
alter table1 drop column col;
-- +goose StatementEnd
Соответственно, запускаем утилиту для миграции схемы вверх - накатываем новую версию - применяются первые два стейтмента и утилита делает в слeжебной таблице пометку, что этот файл она накатила (с таймстемпом, когда это произошло).
Запускаем миграцию вниз - применяются вторые два стейтмента и в служебной таблице делается пометка, что откачено.
Можно совсем атомарно применять: например, меняете одну функцию, но лучше, конечно, согласованно, чтобы из одного рабочего стостояния схемы получать другое рабочее состояние (т.е. чтобы не было такого, что один шаг откатили и оставили систему в неработоспособном состоянии. Это, впрочем, ИМХО.
Соответственно, следующие изменения можно сделать в файле 0002 и он может быть атомарно применен и откачен точно так же.
Таким образом вы можете атомарно накатывать и откатывать изменения, ведь они, в конечном итоге, все делается sql запросами не более того. И иметь понятную историю. Как согласовать изменения в разных БД? Тут уже, наверное, надо подумать, если такой вопрос стоит.
ИМХО, если вы таким не пользуетесь, то надо начать прямо завтра, честно.
Есть еще куча подобного. Я гошник, поэтому знаю, в основном, написанное на Go. Есть еще вот такой вариант (используем в проде в моей компании). https://github.com/golang-migrate/migrate
Но из этих двух goose мне нравится больше (в одном файле миграция вверх и вниз потому что) и goose многие крупные комании используют в проде.
Наверняка, можно найти еще с десяток решений со своими плюсами и минусами.
Рад, что информация пригодилась :) Я думал, это общее место и все знают :)
Исходная версия paddlewan, :
Пойду, почитаю.
Смотри, как это работает. Создаем файл, который накатывает разом все необходимое. Скажем,
0001-add-columns.sql
В нем пишем изменения: – +goose Up – +goose StatementBegin alter table1 add column col(id serial, data text); add or replace function x …. ; – +goose StatementEnd
– +goose Down – +goose StatementBegin drop function x; alter table1 drop column col; – +goose StatementEnd
Соответственно, запускаем утилиту для миграции схемы вверх - накатываем новую версию - применяются первые два стейтмента и утилита делает в слeжебной таблице пометку, что этот файл она накатила (с таймстемпом, когда это произошло).
Запускаем миграцию вниз - применяются вторые два стейтмента и в служебной таблице делается пометка, что откачено.
Можно совсем атомарно применять: например, меняете одну функцию, но лучше, конечно, согласованно, чтобы из одного рабочего стостояния схемы получать другое рабочее состояние (т.е. чтобы не было такого, что один шаг откатили и оставили систему в неработоспособном состоянии. Это, впрочем, ИМХО.
Соответственно, следующие изменения можно сделать в файле 0002 и он может быть атомарно применен и откачен точно так же.
Таким образом вы можете атомарно накатывать и откатывать изменения, ведь они, в конечном итоге, все делается sql запросами не более того. И иметь понятную историю. Как согласовать изменения в разных БД? Тут уже, наверное, надо подумать, если такой вопрос стоит.
ИМХО, если вы таким не пользуетесь, то надо начать прямо завтра, честно.
Есть еще куча подобного. Я гошник, поэтому знаю, в основном, написанное на Go. Есть еще вот такой вариант (используем в проде в моей компании). https://github.com/golang-migrate/migrate
Но из этих двух goose мне нравится больше (в одном файле миграция вверх и вниз потому что) и goose многие крупные комании используют в проде.
Наверняка, можно найти еще с десяток решений со своими плюсами и минусами.
Рад, что информация пригодилась :) Я думал, это общее место и все знают :)