EQSP 11/20: Автоматизация изменений в базе данных | Liquibase [software quality crash course]

[@aleksfrolov9250]

я разработчик простой, вижу новый видос Егора - ставлю лайк)

[@nikitazinoviev1724]

Насчет того, зачем нужен индекс, созданный в файле *004*.xml (1:16:26) тут может помочь git, если посмотреть на git annotate на строку, содержащую CREATE INDEX, то можно найти какой код менялся одновременно с добавлением этого индекса и понять логику. Так что может быть, комментарий не так уж обязателен или по крайней мере, ситуация с его отсутствием не безнадежная.

[@kali_256]

Слышал от вас, Егор, что в начале пути разрабатывали базы данных. Круто, что есть такой контент на ютюбе. Ждём всей командой чёрно-белые айти)

[@yegor256]

Начал когда-то вот с этого: www.yegor256.com/pdf/1998/KRDB98-article.pdf

[@kali_256]

@@yegor256 это очень круто, прям впечатлен, серьёзно). а я начал с того, что отец привёз на новый год 486, в классе 4, много лет назад.. Жил в деревне, где компьютер был только у меня и в школе. Если бы рядом был человек, который показал ассемблер с си, а не дум и вольфенштейн с варкрафт, не потерял бы года на майонез). Огромная благодарнось вам, Егор, что не забываете подрастающее поколение) вот кроме Пайтона подучу раст с джавой и приду к вам с просьбой о сотрудничестве.

[@yegor256]

@@kali_256 буду ждать :)

[@titaniumhocker]

Может я чего-то не понимаю, но мне кажется, что миграции бд это не такой сложный вопрос чтоб так его раздувать. Я работаю в основном на питоне и там alembic решает для меня проблему миграций уже давно и довольно успешно. Файлы миграций лежат в репе рядом с исходным кодом, на каждый коммит или PR миграции прогоняются в CI. В случае если разные разработчики сделали разные миграции в своих ветках, то CI попросту сломается. UPD: Сорр, не заметил, что это лекция для универа. В таком контексте лекция норм, мне в колледже вообще втирали, что все в проде используют MS SQL, а изображения всегда нужно хранить в СУБД как бинари, и ни в коем случае не складывать их на диск или, еще хуже, в S3. Если бы у меня был такой препод, может я бы и ходил туда почаще.

[@VictorSudakovTomsk]

Как философская и идеологическая - лекция хороша, спасибо. На практике при сложных базах вряд ли получится такого идеала достигнуть, хотя стремиться к полному управлению проектом из VCS - нужно.

[@yegor256]

Да, Вы правы, на практике все обычно получается не так красиво.

[@codingfox]

Вначале подумал, что Егор заново изобретает миграции, но потом понял - это учебная лекция 😁

[@ДмитрийЛавров-ж7м]

После просмотра видео остался вопрос, что делать с инсертом тестовых данных в продовую таблицу. За видео спасибо, очень полезно и понятно

[@borinhood]

Для больших и сложных баз такой метод не подойдёт. Не получится каждый раз создавать всю базу с нуля. Вероятно, система должна быть посложнее. Чтобы скрипты позволяли не только монотонно инкрементить состояние базы, но и назад откатывать. Путь даже не очень далеко. Хотя бы до той точки, которая в продакшене.

[@kali_256]

И, если будет возможность, в черно-белом айти, хотелось бы послушать про мёрдж, бранч, гит и альтернативы ему, типо нотебаг, особенно во времена, когда гитхабный опер сорс под Майкрософт становится постепенно цензурируемым большим братом)

[@codingfox]

Когда будут новые выпуски Черно-белого айти? Ждём 🙂

[@yegor256]

Я тоже жду!

[@dieff_automation]

Егор сниимите пожалуйста видео почему вы уехали из США

[@dieff_automation]

Мы не понимаем просто щас туда народ нелегалами идёт а вы самостоятельно уехали в голове не укладывается

[@yegor256]

потому что там качество жизни ниже, еда невкусная, а женщины некрасивые :)

[@dieff_automation]

@@yegor256 как же ниже когда они там вон в каких домах живут и причём это обычные люди не программисты не какие

[@yegor256]

@@dieff_automation изучите: realty.rbc.ru/news/5ddad8359a79476313d8d084

[@andrey7829]

Я только не понял как же отлаживать все запросы, если даже тестовой базы нет?

[@yegor256]

Тестовая база нужна, но только на время тестов

[@user-QesOrwuMqN]

Так а почему это не разбирается на существующих инструментах для миграций? зачем писать велосипед, который оторван от текущих практик по этому вопросу. Я бы понял если бы использовался устаревшая тулза, но которая раньше использовалась …

[@kselnaag2482]

Дропать таблицы это, конечно, весело, особенно прямо на проде, но с данными то что делать ? Я бы их куда то сохранил, передропал всё, изменил структуру и залил обратно, но как ?

[@dimkafn]

Ну по сути ты можешь сделать дамп бд с ддл и инсертами (условно через pg_dump), потом залить измененный ддл и инсерты меняющие данные под этот ддл (ну т.е. фактически сделать дифф старого ддл и нового + залить инсерты с старого дампа). Т.е. по сути это можно даже в ликвибейз скл скрипты запихнуть.

[@AlekseyV82]

Лучше наоборот. Обновить структуру (добавить новые таблицы, столбцы), записать данные в новые столбцы, потом уже дропать старые.

[@nikitazinoviev1724]

А нет смысла squash'ить схему базы данных хотя бы раз в год? Скажем, раз в major release. Я понимаю, что Liquibase хранит md5 и так просто не даст это сделать в продакшн. Но получается, как будто мы код храним в git не в виде целых файлов, а в виде diff'ов и через год разработки неудобно, что нет места, где можно посмотреть полную или почти полную схему. Плюс, возможно, запуск тестов будет существенно замедлен, если перед ним нужно будет применить все changesets к БД с начала истории проекта. В идеале, мы могли бы хранить схему и миграции, а по изменениям схемы в git liquibase строил бы ALTER TABLES.. Или хранить схему, плюс то, что отличает ее от предыдущей ревизии, чтобы liquibase накатывал изменения, двигаясь по истории в git.