Comments 20
я думал, что без боли, это когда миграции абстрагированы от вендора, чтобы можно было развернуться на любой SQL-БД.
если будете писать на вендоро-независимом SQL, то почему бы и нет
там, где у posgres CREATE OR REPLACE FUNCTION, у ms sql ALTER PROCEDURE. у ms sql параметры к процедуре начинаются с символа "@", который postgres в префиксе параметра использовать запрещает, поэтому абстрагироваться от вендора не получится.
безболезненные инкрементные патчи, которые учитывают зависимости – уже благо. хотя интересно, как этот инструмент поступает с перегруженными функциями (одинаковое имя, разное количество или тип входных параметров).
безболезненные инкрементные патчи, которые учитывают зависимости – уже благо. хотя интересно, как этот инструмент поступает с перегруженными функциями (одинаковое имя, разное количество или тип входных параметров).
вы просто погуглите — найдете во всех ЯП подобные миграции. Ну а фолбэки на голос sql всегда тоже можно.
гуглил, и что уж там, пытался мигрировать с ms sql, на, как раз postgres. если в БД хранимые процедуры измеряются тысячами, это малореальная задача. и мне кажется, что в более-менее больших проектах, лучше использовать особенности каждого вендора по максимуму, чтобы не было ситуации «работает везде, но не очень».
то есть в вашем случае бибилиотека, предоставляющая абстракцию над миграциями, не работала? issue написали на гитхабе?
или мы вообще не о библиотеках, а о миграции с одной СУБД на другую без миграций, описанных в статье?
или мы вообще не о библиотеках, а о миграции с одной СУБД на другую без миграций, описанных в статье?
Я имел в виду не миграции с движка на движок. Sqlibrist решает задачу изменений структуры БД при, скажем, разработке и переносе этих изменений с девелоперской на другие экземпляры базы: тестовую, продакшен. Когда нужно написать патч, меняющий/добавляющий объекты базы.
именно, миграция с одной СУБД на другую.
ну так а это уже вопрос другой. Мы тут про библиотеки, позволяющие безболезненно мигрировать. Описываешь абстрактным языком все изменения в схеме, переносишь на другую СУБД, вводишь команду миграции и вуаля. Без библиотек миграции миграция на другую субд — это боль конечно.
Да, есть специфические вещи, не поддающиеся вендор-абстракции.
Да, есть специфические вещи, не поддающиеся вендор-абстракции.
Поступает, как следует. Например, есть две перегруженные функции: test(a integer) и test(b text). Описываем каждую в отдельном файле:
test_int.sql:
test_text.sql:
Теперь, если вы меняете одну из них, скажем, первую, то она сначала удалится инструкцией из раздела --DOWN, а потом пересоздастся. При этом DROP FUNCTION отличаются типами аргументов, поэтому путаницы не будет.
test_int.sql:
--UP
create function test(a integer)
returns boolean
as $$
return true;
$$
language plpgsql;
--DOWN
drop function test(integer);
test_text.sql:
--UP
create function test(b text)
returns boolean
as $$
return false;
$$
language plpgsql;
--DOWN
drop function test(text);
Теперь, если вы меняете одну из них, скажем, первую, то она сначала удалится инструкцией из раздела --DOWN, а потом пересоздастся. При этом DROP FUNCTION отличаются типами аргументов, поэтому путаницы не будет.
UFO just landed and posted this here
Думал ли над тем, чтоб обернуть код в up/down.sql в транзакцию, если там нет «необратимых» инструкций?
stackoverflow.com/questions/13462475/is-it-possible-to-wrap-ddl-changes-in-a-transaction-in-postgresql
stackoverflow.com/questions/13462475/is-it-possible-to-wrap-ddl-changes-in-a-transaction-in-postgresql
Sign up to leave a comment.
Управление структурой базы данных без боли