|
| 1.2, Аноним (-), 10:22, 15/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Вот только даунгрейд миграций flyway не поддерживает. Модно только дропнуть базу через clean и затем снова накатить через migrate
| | |
| |
| 2.5, Аноним (-), 10:42, 15/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Миграции ещё и на SQL пишутся. Тот же liquidbase поддерживает YAML, что гораздо удобней.
| | |
|
| |
| |
| 3.39, Аноним (-), 23:42, 19/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Очень сильно удивился в своё время что оракл не может такое, а постгрес без проблем.
Проприетарщики мучались и вручную писали скрипты для отката в liquidbase.
| | |
|
|
| |
| 2.6, A.Stahl (ok), 10:59, 15/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
 Вполне схожие логотипы по трудозатратам. У Микрософта нелепо раскрашенные квадратики, у этих ребят коряво нарисованная бочка с крылышками.
| | |
| |
| |
| 4.20, Аноним (-), 16:29, 15/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
> А, так это крылья? Долго не мог понять, что не так с
> ногами
Это много каблуков
| | |
|
| 3.36, б.б. (?), 07:09, 17/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– | |
у perl6 на логотипе бабочка, чтобы заинтересовать семилетних девочек
а это - кого заинтересовать?
| | |
|
|
| 1.7, Аноним (-), 11:03, 15/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
Так а что оно умеет то? Просканить папку, посмотреть - выполнены ли все миграции в базе (зуб даю - с помощью сервисной таблички) и затем выполнить недостающие? И это вынесено в отдельный проект? там 20 строчек кода от силы, я такой функционал в своем фреймворке реализовал за пол часа...
Еще у них версия базы, как я понял, зависит от имени файла. Т.е. что-то типа V1_****, V2_*** и т.д. А что будет если будет несколько файлов с именем VN_**** ??? Ошибка или типа одна версия базы? А если эти файлы добавлены в одно время разными людьми, которые работают над непересекающимися фичами? Версии то разные должны быть.
Есть тут те, кто этим реально пользуется? Есть ли у данного продукта какие-то киллeр-фичи?
| | |
| |
| 2.9, A (?), 12:25, 15/02/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Неюзабельно. Как выше заметили: downgrade не поддерживается, разработка в команде очень проблематична в силу версионности через имя файла (ад для релиз-инженера).
Тот же alembic пусть и на коленке написан и, если я правильно понимаю, почти не поддерживается уже: работает в обе стороны, версионность через спец. переменную в файле, поддерживает даже собственными средствами мердж при расхождении веток фикстур, все как во взрослых xVCS.
| | |
| 2.14, VoDA (ok), 14:06, 15/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
 > там 20 строчек кода от силы, я такой функционал в своем фреймворке
> реализовал за пол часа...
Там несколько больше. И самому еще написать нужно. А так взял и получил результат.
> Еще у них версия базы, как я понял, зависит от имени файла.
> Т.е. что-то типа V1_****, V2_*** и т.д. А что будет если
> будет несколько файлов с именем VN_**** ??? Ошибка или типа одна
> версия базы? А если эти файлы добавлены в одно время разными
> людьми, которые работают над непересекающимися фичами? Версии то разные должны быть.
Если правильно помню (юзал лет 5 назад), то там запоминается какие ФАЙЛЫ накатили на БД. Так что все ок. Когда смержат в мастер и выкатят на прод - применяться оба файла.
Важно знать эту особенность и сделать naming convention на имена файлов. 100+ миграций все ок.
> Есть тут те, кто этим реально пользуется? Есть ли у данного продукта
> какие-то килл*р-фичи?
Основная килл*р фича - Just works. Самописные костыли из старых проектов менее удобны. Проще перейти на флайвей, чем поддерживать старье.
Из удобных лично мне - работа с pure-SQL. Ликвибейс умеет то же самое. Вопрос пристрастий.
| | |
| |
| 3.21, Аноним (-), 16:29, 15/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Там несколько больше. И самому еще написать нужно. А так взял и получил результат.
я про основной код. понятно, что там и обвязка для maven-плагина, и некоторый набор классов для встраивания в приложение, возможно что-то еще. Но основная задача решается в ~20 строчек (условно)
> Если правильно помню (юзал лет 5 назад), то там запоминается какие ФАЙЛЫ накатили на БД. > Так что все ок. Когда смержат в мастер и выкатят на прод - применяться оба файла.
> Важно знать эту особенность и сделать naming convention на имена файлов. 100+ миграций все ок.
Не, понятно что оба применятся. Вопрос в другом. У нас есть уже некоторое количество миграций. Допустим, самая последняя - V20_***
Я и другой человек, работающие над проектом, делаем независимо друг от друга разные фичи. Естественно, мы оба выбираем себе имя файлов миграций как V21_***. Имена файлов не пересекутся, но тем не менее мы какбэ оба делаем 21 версию базы, что неправильно - наши изменения никак между собой не связаны. И зачем вообще эта версия мне непонятно - например на прод сначала может уйти 30 версия, потом 25, а 22 например вообще ближайшее время туда не попадет, т.к. фичу по какой-то причине заморозили.
> Основная килл*р фича - Just works. Самописные костыли из старых проектов менее удобны.
> Проще перейти на флайвей, чем поддерживать старье.
какбэ так себе фича... свое решение возможно будет менее гибким, зато лучше подходить под те процессы, которые выстроены в компании. Переделывать же устоявшиеся процессы под каждую либу никто не будет.
| | |
|
| 2.32, Led (ok), 23:31, 15/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > Так а что оно умеет то? Просканить папку
Почему только папку? Мамку тоже.
| | |
|
| |
| 2.13, VoDA (ok), 13:59, 15/02/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Удобная либа которая проверит текущую версию БД и накатит нужные обновления. Проще взять готовое чем писать на коленке свое.
По сравнению с ликвидом - проще и удобнее работой через SQL. Ликвид тоже умеет pure-SQL, но тогда теряются плюшки rollback.
Плюс флайвей позволяет для сложных преобразований делать java migrations. Иногда это проще, чем писать тонну Sql.
| | |
| |
| 3.22, Аноним (-), 16:30, 15/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Плюс флайвей позволяет для сложных преобразований делать java migrations. Иногда это проще,
> чем писать тонну Sql.
А можно поподробнее про java migrations? Ну или хотя бы ссылочку - что это вообще за зверь в данном случае?
| | |
| |
| 4.27, qsdg (ok), 20:50, 15/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
 Я так понимаю товарищ про то, что flyway не обязательно вызывать из командной строки, можно писать свою логику на любимой java, дёргая flyway либу как вздумается.
| | |
| |
| 5.31, Аноним (-), 23:11, 15/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Я так понимаю товарищ про то, что flyway не обязательно вызывать из
> командной строки, можно писать свою логику на любимой java, дёргая flyway
> либу как вздумается.
я пробежался по примерам... чтобы сделать нормальную интеграцию под мои требования - нужно примерно столько же кода, сколько и самому всё реализовать...
| | |
| 5.34, VoDA (ok), 16:01, 16/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Я так понимаю товарищ про то, что flyway не обязательно вызывать из
> командной строки, можно писать свою логику на любимой java, дёргая flyway
> либу как вздумается.
Наоборот. Flyway может дергать кастомный java который будет выполнять эпические преобразования. К примеру, инвалидирует Elastic cache или пересчитает данные новым алгоритмом.
| | |
|
|
|
|
| |
| 2.28, qsdg (ok), 20:54, 15/02/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> А есть аналоги этой флайвей?
MyBatis migrations http://www.mybatis.org/migrations/ наверно самая простая.
Liquibase -- xml синтаксис, умеет делать diff между реальной базой и твоим XML скриптом.
Также поддерживает scope (там это называется context), когда можно указать что вот эти вот нужно накатывать только на прод, некоторые -- только на тестовую бд. При вызове указываешь какой context хочешь накатить.
| | |
|
| 1.18, Шкурка_от_головки (ok), 15:19, 15/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Мой личный опыт с этой программой.
Понравилось:
1. именование файлов как версию миграции
2. чистый SQL
3. гибкая конфигурация
Не понравилось:
1. отсутствие транзакций. например, если пишите запрос в несколько строк, и одна из них ушла в fail, то откатить исполнившиеся строки нельзя.
2. Никакая работа с несколькими схемами. Вполне логично было бы разделить миграции для разных схем на разные директории, а работать с ними через одну программу.
3. отсутствие downgrade
| | |
| |
| 2.23, Аноним (-), 16:32, 15/02/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> 1. именование файлов как версию миграции
как по мне - очень спорно
> 3. гибкая конфигурация
в чем это проявляется?
> 1. отсутствие транзакций. например, если пишите запрос в несколько строк, и одна
> из них ушла в fail, то откатить исполнившиеся строки нельзя.
не все БД умеют транзакционность DDL (тот же mysql - не умеет)
> 2. Никакая работа с несколькими схемами. Вполне логично было бы разделить миграции
> для разных схем на разные директории, а работать с ними через
> одну программу.
а как же гибкая конфигурация?
> 3. отсутствие downgrade
насколько реально это нужно и как часто востребовано?
| | |
| |
| 3.24, Шкурка_от_головки (ok), 17:26, 15/02/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> как по мне - очень спорно
Помимо версии указывается еще описание миграции. По мне, так это лучше, чем тyпой таймстамп.
> в чем это проявляется?
Различные префиксы, суффиксы, разделители для именования файлов и т.д. Подробности в комментариях файла конфигурации.
> не все БД умеют транзакционность DDL (тот же mysql - не умеет)
Если программа берет на себя версионность БД, то как-то на уровне ПО можно это реализовать.
> а как же гибкая конфигурация?
Да, не все в ней гладко
> насколько реально это нужно и как часто востребовано?
Ну, это уже у каждого по-разному. Downgrade удобно использовать для отмены миграции, что приводит, соответственно, к уменьшению количества upgrade'ов.
| | |
| |
| 4.25, Аноним (-), 17:32, 15/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
>> как по мне - очень спорно
> Помимо версии указывается еще описание миграции. По мне, так это лучше, чем
> тyпой таймстамп.
Чем это лучше чем например тyпой таймстамп (для сортировки) и краткое описание миграции? ПОтенциальную проблему с версией я уже выше описал - как по мне это достаточно частый use-case
>> в чем это проявляется?
> Различные префиксы, суффиксы, разделители для именования файлов и т.д. Подробности в комментариях
> файла конфигурации.
хотелось бы услышать про фичи, которые реально нужны и востребованы.
>> не все БД умеют транзакционность DDL (тот же mysql - не умеет)
> Если программа берет на себя версионность БД, то как-то на уровне ПО
> можно это реализовать.
каким способом в данном случае? возможности rollback нет (не уверен, что эта задача в случае pure SQL вообще решается, даже для одной БД). Как по мне - в данном случае претензия не по адресу.
>> насколько реально это нужно и как часто востребовано?
> Ну, это уже у каждого по-разному. Downgrade удобно использовать для отмены миграции,
> что приводит, соответственно, к уменьшению количества upgrade'ов.
Не понимаю. Допустим я добавил миграцию и через пару месяцев решил ее зачем-то откатить. Да, было бы удобно, если бы я просто написал в файле миграции что-то типа "purge migration VXX_****" вместо пачки "ALTER TABLE....", но как это уменьшит количество upgrade'ов? Все равно ведь по сути нужно сформировать эту пачку и провести ее...
| | |
| |
| 5.29, Шкурка_от_головки (ok), 22:33, 15/02/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> Чем это лучше чем например тyпой таймстамп (для сортировки) и краткое описание миграции? ПОтенциальную проблему с версией я уже выше описал - как по мне это достаточно частый use-case
Да, при наличии двух и более файлов с одной версией он ругается. Но как часто Вы меняете базу, что не можете угнаться за версиями? Поэтому я и говорю о downgrad'е, что если необходимо внести изменения в миграцию, можно было ее downgrade'нуть изменить и upgrade'нуть измененную. А так получается, что при дальнейших изменениях, которые можно было бы объединить в один файл, приходится плодить маленькие миграции, тем самым увеличивая номер версии типи V1_2_45.
> каким способом в данном случае? возможности rollback нет (не уверен, что эта задача в случае pure SQL вообще решается, даже для одной БД). Как по мне - в данном случае претензия не по адресу.
Считаю, что если программа взялась работать с версионностью БД, то нужно это делать намного продуманней. С pure SQL, мне кажется, решается, если ограничить запросы только касающиеся структуры БД, и хранением для каждой миграции состояние структуры изменяемых таблиц. Все-таки на каждое действие должно быть обратное действие, даже если оно будет несколько сложнее начального действия.
> Не понимаю. Допустим я добавил...
Описал в начале, что я имел в виду говоря об уменьшении upgrade'ов.
| | |
| |
| 6.30, Аноним (-), 23:09, 15/02/2017 [^] [^^] [^^^] [ответить] | +/– | в активной фазе разработки проекта база меняется очень часто потом пилятся фичи... большой текст свёрнут, показать | | |
|
|
|
|
|
|
