✨ Двойные миграции (Оракл+Постгрес)
У нас идёт замена в наших продуктах сильно платного «Оракла» (это база данных) на бесплатный «Постргес». Несмотря на ударные темпы, продолжаться это ещё будет долго. Продуктов много, несмотря на то, что начали мы ещё в прошлом году, весь этот год будем жить сразу на двух базах.
В этой связи, когда есть различия, приходится миграции писать в двух комплектах — под каждый диалект. Я придумал как писать их так, чтобы каждая БД видела куски кода, предназначенные только ей.
Например:
CREATE UNIQUE INDEX dn_part_num_org_n_cat ON document_n(/*/**/
CASE WHEN d_deleted = 0 AND num IS NULL AND n=0 AND category=0 THEN id END,
CASE WHEN d_deleted = 0 AND num IS NULL AND n=0 AND category=0 THEN org_id END);
--*/ id, org_id) WHERE d_deleted=0 AND num IS NULL AND n=0 AND category = 0;Часть с /*/**/ и до —*/ видит только «Оракл» — для него это выглядит так: комментарий открывается, сразу закрывается, идёт код, который он и воспринимает, а последняя строка закоментирована при помощи двух минусов — это стандартный коментарий в эскуэле.
«Постгрес» эту часть не видит — он поддерживает вложенные коментарии, поэтому его интерпретация другая: открываются два комментария, первый закрывается сразу, а второй — на последней строке, остаток которой «Постгрес» воспринимает как часть кода.
Комментарии 30
Старого воробья, обстрелянного браузерными несовместимостями, на мякине не проведешь!
Это для продакшна, да. Миграция. В чём именно заключается ужас?
Просто на месте убью любого, кто посмеет закоммитить подобный код в любом из проектов, где я участвую… Впрочем, спасибо за выпуклый пример как не надо делать — на следующем разборе полётов
В этом месте было бы неплохо показать как надо делать.
— Нужную миграцию сложно найти в каталоге.
— Пара миграций нужны не всегда.
— Что если нужна миграция для разных версий одной СУБД?
— Что если вам потребуется добавить поддержку mysql в проект?
— Что если безопасники
— Что с миграциями со вюхами и хранимками? Как отличать, что для psql, что для oracle?
— Как разработчикам писать это не ошибаясь?
Я бы сделал скриптик, который в специальной дериктории создаёт новые миграции с таймстаспом в названии и расширениями
Если же, вдруг, такой переезд
Мы не делаем поддержку нескольких версий СУБД, у нас не сайтик для
Отличать ничего не нужно, есть определённая обвязка, информационная и диагностическая. Так же как и
Про безопасников агрумент не понял вообще. Как это вообще связано с безопасностью?
Твой простой скрипт требует изменения кучи кода обвязки вокруг миграций, пока нам не до этого, а скоро уже и не понадобится — когда переход состоится.
Ну и я про явность и неявность я даже объяснять не хочу. Правила Пайтона замечательны, но и сам Пайтон не может им следовать, потому что абстракции не бывают явными, а Пайтон — это очень высокоуровневая абстракция от железа. Нет ничего явного в этом мире. Есть привычное.
На всё ответил?
А вот эти пропустил.
Ок. И что? Тогда просто пишем миграцию на универсальном эскуэле.
А что с ними?
А вы делаете одномоментный переход на другую СУБД? СЭД — это же несколько проектов (или речь идёт только об одном проекте?). Их тоже переводить одномоментно? Это я к тому, что вкакой-то момент у Вас всё равно будет поддержка сразу двух СУБД.
Сейчас такой необходимости нет, но что если покаким-либо причинам Postgres будет использовать нельзя?
Не согласен. Сложно, но можно. Конечно, просто адаптировать запросы — да, скорее всего не получится, в силу того что MySQL просто беднее по функциональности.
А что тут искать? Скрипт make_migration.sh который создаёт в папке ./sql/migrations/ два файла TIMESTAMP_shortname.postgre.sql и TIMESTAMP_shortname.oracle.sql с одинаковыми TIMESTAMP? Чем такое решение хуже, чем предложенное Вами?
Даже просмотр через «ls -la» покажет всё отсортированно по дате. Кроме того вSQL-файле миграции удобно держать заголовок с описанием этой самой миграции.
Что если сторонняя организация будет проводить аудит безопасности системы? Они разрешат использовать такие миграции?
Возможно. Я не знаю, как у вас теперь устроен механизм применения миграций и их отслеживания. Предположил самый простой вариант.
А причём тут python? Явное лучше чем неявное, не только в python. Там это просто акцентируется.
Нет.
— Как разработчикам писать это не ошибаясь?
— Почему не такое простое и явное решение?
Комментарий для Евгения Степанищева:
К счастью, мне не доводилось переводить продукта с полумиллионом строк (имеется в виду на SQL?) с Oracle на Postgre. Мне доводилось поддерживать продукты, которые изначально должны бытьdatabase-agnostic в широких пределах. В частности, использовал пары Postgre и H2 (для серверной и толстого клиента), или Postgre и MySQL (для разных хостингов), или MSSQL и Postgre (для облачного и локального сервера), или даже MySQL и SQLite. Причём, во всех случаях с точки зрения кода было вообще неважно, какая из БД используется в данный момент.
что-то самописное, сводящее все запросы до уровня SQL:1999, с которым уже давно всё полностью совместимо.
чего-либо нужно использовать готовые решения, типа LiquiBase, Flyway, и им подобных — тысячи их, всегда можно выбрать подходящее под целевую платформу, либо взять полуфабрикат и допилить самостоятельно. Делал такое для одного из проектов Сбера, там основной базой была DB2, она экзотическая и плохо поддерживается всеми.
ETL-решением. С выгрузкой базы в сериализованный формат и импортом в новую с переделкой на лету. Полезно, если продукт должен обеспечивать загрузку данных из старой версии себя самого, либо давать возможность нативного бэкапа, а не средствами самой СУБД.
как-то так:
Это решается применением слоя ORM. Hibernate, JPA, либо вообще
Теперь про миграции. Их не нужно писать руками. В большинстве своём ORM уже поддерживают рудиментарные миграции на добавление полей, таблиц, и индексов. Для более сложных случаев с изменениями типов или удалениями
Наконец, в особо тяжёлых случаях — заморочиться полноценным
Что касается ниндзюцу, то в нормальном промышленном энтерпрайзе оно запрещено. Если твой код потом будет читать и поддерживать чувак из другого часового пояса, ты не имеешь права заставлять его разгадывать ребусы, и повышать возможность ошибки для всего твоего проекта. Ну, не все, конечно, делают такой энтерпрайз. Но с нашей точки зрения это
http://fotki.yandex.ru/next/users/pastorgl … iew/476650
Комментарий для Pavelpat:
Так же как они пишут что угодно другое.
На этот вопрос я уже ответил выше, довольно подробно.
Комментарий для PastorGL:
какой-то другой задачи.
Описано решение
У нас высоконагруженный продукт, ORM с нашими запросами на справится. Мы широко используем практически все возможности СУБД, плюс нередко хинтуем запросы.
Не будет. У нас нет чуваков из другого часового пояса. И разгадывать ему нечего. В нормальном промышленном интерпрайзе используется документирование. И это не код, это разовая миграция.
http://img-fotki.yandex.ru/get/25541/16986 … 50#404x258
Ну, это всё забавно и всё такое, только почему вы вообще решили, что вы меня можете учить как делать
Когда я занимался восточными единоборствами, я узнал интересную штуку: в самом начале вас учат бить только кулаком, представляя всё так, будто ударов прочими частями руки не существует — так бить прямо запрещают и такие удары считаются грубой ошибкой.
Позже когда достигнута нужна физическая и умственная форма, учат бить ладонью, пальцами и т.д. Удар не кулаком больше не является ошибкой, мастер совершенно свободен в выборе инструмента — он знает когда его применить и умеет это делать.
Так вот, господа. Вы, ребята, либо перепутали меня с учеником, которому разрешено бить только кулаком, либо не продвинусь дальше уровня «кулака». Считаете, что ваши заученные приёмы и есть то, чем надлежит пользоваться.
Думаю, в моей ситуации вы бы не выдержали сроки и не справились теми ресурсами, которые есть, искренне, скорее всего считая, что вы правильно всё делаете и недоумевая почему никто не пребывает в восторге от ваших усилий, которые хоть и не привели к успеху, зато были правильными и «по науке». Такие специалисты не редкость.
Ужас же в том, что вы, по всей видимости, не видите, что надо двигаться дальше.
В следующий раз, прежде чем ужасаться, неплохо бы выяснить почему выбрано такое решение, особенно, если его автор — человек с опытом. А если уж автор начал объяснять, надо бы либо попытаться разобраться в ситуации, либо честно признаться, что такого желания у вас нет.
http://pastebin.com/KBFxmgLt
Кроме того, есть несколько билдеров, которые в универсальном виде принимают параметры, а на выходе отдают адаптированный запрос. Билдеры сейчас есть для:
— иерархических запросов (так же известных как «рекурсивные»)
— для массовой вставки (bulk insert)
— для вызова функций/процедур
— для запросов MERGE
— для запросов UPSERT
А так же небольшой хелпер, который умеет делать универсальный OFFSET/LIMIT (в случае нашего
Комментарий для Евгения Степанищева:
А теперь ещё и обижается.
Ну ваше право. Если ваш продукт неотчуждаемый, существует в единственном экземпляре, и никогда не будет передан на сопровождение никому другому, ради бога, хоть на головах там ходите. Упарывайтесь родниковой водой и горным воздухом, пишите любую жуть. Хаки в полный рост используйте. В собственной
Только будьте готовы, что если вы решите это безобразие показать
Комментарий для Евгения Степанищева:
Меряться опытом — это вообще последнее дело. Вот у меня его, например, 17 лет. Из которых больше десяти на сеньорских позициях, включая проекты, которые годами пилили командами, раскиданными по трём часовым поясам. Только кто сказал, что мой опыт лучше вашего? Я лично так не считаю, потом что он, очевидно, совсем разный. Мой лишь говорит мне, что хаки любого рода — это плохо для проекта.
Комментарий для PastorGL:
Вы опять ничего не поняли. Я не говорю плохо о вашем опыте. Мне непонятно с чего вы решили, что у меня не хватает опыта, чтобы принимать такие решения взвешенно. В хорошо документированных хаках или хаках, которые решают разовые задачи быстро, нет ничего плохого.
Нувсё-таки вы решили померятся. Ну ок. Опыт у меня — 27 лет программирования, включая три ассемблера. 19 лет на позициях руководителей разработчиков. Занимался всем — играми, бизнес-приложениями, взломами программ, заказными программами для взломов, вебом, работал со всем миром, включая Европу, США, арабский мир. В основном известен тем, что способен решить любую задачу, если она в пределах возможного. Это мой основной скилл.
Я вот что тут не понял.
Это скрипты миграции? Т.е. они запускаются только при обновлении версии?
Если так, что чтобы не сделать просто два скрипта и выполнятся будет только нужный. Будет два каталога «миграция оракла», «миграция постгреса».
Небольшой оверхед на копирование (разработчик явно будет делать на
Никто никогда не правит миграционные скрипты (после того, как он попал в релиз), так что проблемы «один поправил, второй забыл» никогда не будет.
Выше уже разобрана эта ситуация.
Занимался лет 15 назад, точно такой же задачей, только софт был на C/Motif. На момент этой задачи в проекте было 1.5кк LOC и 15 лет говнокода.
Многого уже не вспомню (разве что цирк с ROWID), но до сих пор с грустной улыбкой вспоминаю, как из костылей, грязи и палок делалась
До Slony оставалось три года.
P.S: а миграции мы с год отдельно поддерживали для обеих веток.