The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  вход/выход  слежка  RSS
"Выпуск Flyway 4.1.0, инструмента для контроля версий БД"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от opennews (??) on 15-Фев-17, 10:19 
Представлен (https://flywaydb.org/blog/flyway-4.1.0.html) новый выпуск проекта  Flyway (https://flywaydb.org/), в рамках которого развивается инструментарий для сопровождения баз данных и синхронизации их структуры со связанным программным обеспечением.  Flyway можно рассматривать как аналог системы контроля версий для БД, который выполняет задачу автоматизации отражения изменений в структуре базы данных для соответствия версии БД и версии программного обеспечения, работающего с этой БД.


Иными словами,  Flyway позволяет привязать состояние структуры БД к версией приложения и изменять данную структуру в зависимости от выбранной версии программы. Например, при переходе на новую версию приложения Flyway позволяет на всех серверах привести схему хранения данных к новой версии, а в случае отката на прошлую версию ПО - откатить изменение схемы в БД. Flyway также даёт возможность быстро узнать какой версии ПО соответствует имеющаяся БД, проверить целостность схемы и  в случае нарушения структуры (например, ручного добавления/удаления поля) исправить схему.

Код проекта написан на языке Java и распространяется (https://github.com/flyway/flyway) под лицензией Apache 2.0. Flyway может работать с СУБД PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, SQL Azure, DB2, DB2 z/OS,  Google Cloud SQL Redshift, Vertica, EnterpriseDB, H2, Hsql, Derby и SQLite. Имеются встроенные средства для интеграции с системами сборки Maven, Gradle, Ant и SBT, а также плагины для  Spring Boot, Dropwizard, Grails, Play, Griffon, Grunt и Ninja. Применение Flyway возможно на любых системах для которых доступен язык Java, в том числе Windows, macOS, Linux и Android.


В новой версии добавлена поддержка EnterpriseDB, возможность использования в PostgreSQL  не работающих внутри транзакций конструкций (CREATE INDEX CONCURRENTLY, ALTER TYPE, VACUUM ), улучшена поддержка репликации MySQL, увеличена производительность массовых миграций.


URL: https://flywaydb.org/blog/flyway-4.1.0.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=46050

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +5 +/
Сообщение от Аноним (??) on 15-Фев-17, 10:19 
Очень круто.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +3 +/
Сообщение от Аноним (??) on 15-Фев-17, 10:22 
Вот только даунгрейд миграций flyway не поддерживает. Модно только дропнуть базу через clean и затем снова накатить через migrate
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  –1 +/
Сообщение от Аноним (??) on 15-Фев-17, 10:42 
Миграции ещё и на SQL пишутся. Тот же liquidbase поддерживает YAML, что гораздо удобней.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

17. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от Аноним (??) on 15-Фев-17, 14:27 
Хотите чтобы flyway сам все дропал вместов вас?
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

26. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от аноним_ on 15-Фев-17, 20:50 
это и на обычном sql невозможно
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  –2 +/
Сообщение от _pochtynet_ on 15-Фев-17, 10:26 
Лучше бы добавили роллбэки.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

19. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +1 +/
Сообщение от Аноним (??) on 15-Фев-17, 16:28 
Для Oracle на DDL
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

39. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от Аноним (??) on 19-Фев-17, 23:42 
Очень сильно удивился в своё время что оракл не может такое, а постгрес без проблем.
Проприетарщики мучались и вручную писали скрипты для отката в liquidbase.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

38. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от Dmitry (??) on 19-Фев-17, 23:36 
Это работа базы данных
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от Пользователь Debian on 15-Фев-17, 10:31 
Лого у проекта отличное.

Майкрософту бы поучиться!

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от A.Stahl (ok) on 15-Фев-17, 10:59 
Вполне схожие логотипы по трудозатратам. У Микрософта нелепо раскрашенные квадратики, у этих ребят коряво нарисованная бочка с крылышками.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

11. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +3 +/
Сообщение от Аноним (??) on 15-Фев-17, 13:10 
А, так это крылья? Долго не мог понять, что не так с ногами
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

20. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от Аноним (??) on 15-Фев-17, 16:29 
> А, так это крылья? Долго не мог понять, что не так с
> ногами

Это много каблуков

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

36. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  –1 +/
Сообщение от б.б. on 17-Фев-17, 07:09 
у perl6 на логотипе бабочка, чтобы заинтересовать семилетних девочек

а это - кого заинтересовать?

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

37. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от Dmitry77 (ok) on 19-Фев-17, 23:32 
а мне нравится логотип logstash - чурбан с усами
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

7. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  –1 +/
Сообщение от Аноним (??) on 15-Фев-17, 11:03 
Так а что оно умеет то? Просканить папку, посмотреть - выполнены ли все миграции в базе (зуб даю - с помощью сервисной таблички) и затем выполнить недостающие? И это вынесено в отдельный проект? там 20 строчек кода от силы, я такой функционал в своем фреймворке реализовал за пол часа...

Еще у них версия базы, как я понял, зависит от имени файла. Т.е. что-то типа V1_****, V2_*** и т.д. А что будет если будет несколько файлов с именем VN_**** ??? Ошибка или типа одна версия базы? А если эти файлы добавлены в одно время разными людьми, которые работают над непересекающимися фичами? Версии то разные должны быть.

Есть тут те, кто этим реально пользуется? Есть ли у данного продукта какие-то киллeр-фичи?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от A on 15-Фев-17, 12:25 
Неюзабельно. Как выше заметили: downgrade не поддерживается, разработка в команде очень проблематична в силу версионности через имя файла (ад для релиз-инженера).

Тот же alembic пусть и на коленке написан и, если я правильно понимаю, почти не поддерживается уже: работает в обе стороны, версионность через спец. переменную в файле, поддерживает даже собственными средствами мердж при расхождении веток фикстур, все как во взрослых xVCS.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

14. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от VoDA (ok) on 15-Фев-17, 14:06 
> там 20 строчек кода от силы, я такой функционал в своем фреймворке
> реализовал за пол часа...

Там несколько больше. И самому еще написать нужно. А так взял и получил результат.

> Еще у них версия базы, как я понял, зависит от имени файла.
> Т.е. что-то типа V1_****, V2_*** и т.д. А что будет если
> будет несколько файлов с именем VN_**** ??? Ошибка или типа одна
> версия базы? А если эти файлы добавлены в одно время разными
> людьми, которые работают над непересекающимися фичами? Версии то разные должны быть.

Если правильно помню (юзал лет 5 назад), то там запоминается какие ФАЙЛЫ накатили на БД. Так что все ок. Когда смержат в мастер и выкатят на прод - применяться оба файла.

Важно знать эту особенность и сделать naming convention на имена файлов. 100+ миграций все ок.

> Есть тут те, кто этим реально пользуется? Есть ли у данного продукта
> какие-то килл*р-фичи?

Основная килл*р фича - Just works. Самописные костыли из старых проектов менее удобны. Проще перейти на флайвей, чем поддерживать старье.

Из удобных лично мне - работа с pure-SQL. Ликвибейс умеет то же самое. Вопрос пристрастий.


Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

21. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +1 +/
Сообщение от Аноним (??) on 15-Фев-17, 16:29 
> Там несколько больше. И самому еще написать нужно. А так взял и получил результат.

я про основной код. понятно, что там и обвязка для maven-плагина, и некоторый набор классов для встраивания в приложение, возможно что-то еще. Но основная задача решается в ~20 строчек (условно)

> Если правильно помню (юзал лет 5 назад), то там запоминается какие ФАЙЛЫ накатили на БД. > Так что все ок. Когда смержат в мастер и выкатят на прод - применяться оба файла.
> Важно знать эту особенность и сделать naming convention на имена файлов. 100+ миграций все ок.

Не, понятно что оба применятся. Вопрос в другом. У нас есть уже некоторое количество миграций. Допустим, самая последняя - V20_***

Я и другой человек, работающие над проектом, делаем независимо друг от друга разные фичи. Естественно, мы оба выбираем себе имя файлов миграций как V21_***. Имена файлов не пересекутся, но тем не менее мы какбэ оба делаем 21 версию базы, что неправильно - наши изменения никак между собой не связаны. И зачем вообще эта версия мне непонятно - например на прод сначала может уйти 30 версия, потом 25, а 22 например вообще ближайшее время туда не попадет, т.к. фичу по какой-то причине заморозили.

> Основная килл*р фича - Just works. Самописные костыли из старых проектов менее удобны.
> Проще перейти на флайвей, чем поддерживать старье.

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

32. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  –1 +/
Сообщение от Led (ok) on 15-Фев-17, 23:31 
> Так а что оно умеет то? Просканить папку

Почему только папку? Мамку тоже.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

8. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +1 +/
Сообщение от LinuxID (ok) on 15-Фев-17, 11:07 
Ага! Летающая 200 литровая бочка с няшками ))
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от Аноним (??) on 15-Фев-17, 13:38 
Я не совсем понял, запросы же все равно писать придется, какой профит?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от VoDA (ok) on 15-Фев-17, 13:59 
Удобная либа которая проверит текущую версию БД и накатит нужные обновления. Проще взять готовое чем писать на коленке свое.

По сравнению с ликвидом - проще и удобнее работой через SQL. Ликвид тоже умеет pure-SQL, но тогда теряются плюшки rollback.

Плюс флайвей позволяет для сложных преобразований делать java migrations. Иногда это проще, чем писать тонну Sql.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

22. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от Аноним (??) on 15-Фев-17, 16:30 
> Плюс флайвей позволяет для сложных преобразований делать java migrations. Иногда это проще,
> чем писать тонну Sql.

А можно поподробнее про java migrations? Ну или хотя бы ссылочку - что это вообще за зверь в данном случае?

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

27. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от qsdg (ok) on 15-Фев-17, 20:50 
Я так понимаю товарищ про то, что flyway не обязательно вызывать из командной строки, можно писать свою логику на любимой java, дёргая flyway либу как вздумается.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

31. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от Аноним (??) on 15-Фев-17, 23:11 
> Я так понимаю товарищ про то, что flyway не обязательно вызывать из
> командной строки, можно писать свою логику на любимой java, дёргая flyway
> либу как вздумается.

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

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

34. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от VoDA (ok) on 16-Фев-17, 16:01 
> Я так понимаю товарищ про то, что flyway не обязательно вызывать из
> командной строки, можно писать свою логику на любимой java, дёргая flyway
> либу как вздумается.

Наоборот. Flyway может дергать кастомный java который будет выполнять эпические преобразования. К примеру, инвалидирует Elastic cache или пересчитает данные новым алгоритмом.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

33. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от VoDA (ok) on 16-Фев-17, 15:59 
Лови :)

https://flywaydb.org/documentation/migration/java

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

35. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от Аноним (??) on 16-Фев-17, 17:05 
> Лови :)
> https://flywaydb.org/documentation/migration/java

как интересно... и кто-то этим реально пользуется?

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

15. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +1 +/
Сообщение от Аноним (??) on 15-Фев-17, 14:20 
А есть аналоги этой флайвей?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

28. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от qsdg (ok) on 15-Фев-17, 20:54 
> А есть аналоги этой флайвей?

MyBatis migrations http://www.mybatis.org/migrations/ наверно самая простая.

Liquibase -- xml синтаксис, умеет делать diff между реальной базой и твоим XML скриптом.
Также поддерживает scope (там это называется context), когда можно указать что вот эти вот нужно накатывать только на прод, некоторые -- только на тестовую бд. При вызове указываешь какой context хочешь накатить.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

16. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от Аноним (??) on 15-Фев-17, 14:25 
http://www.liquibase.org/
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +1 +/
Сообщение от Шкурка_от_головки (ok) on 15-Фев-17, 15:19 
Мой личный опыт с этой программой.
Понравилось:
1. именование файлов как версию миграции
2. чистый SQL
3. гибкая конфигурация

Не понравилось:
1. отсутствие транзакций. например, если пишите запрос в несколько строк, и одна из них ушла в fail, то откатить исполнившиеся строки нельзя.
2. Никакая работа с несколькими схемами. Вполне логично было бы разделить миграции для разных схем на разные директории, а работать с ними через одну программу.
3. отсутствие downgrade

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от Аноним (??) on 15-Фев-17, 16:32 
> 1. именование файлов как версию миграции

как по мне - очень спорно

> 3. гибкая конфигурация

в чем это проявляется?

> 1. отсутствие транзакций. например, если пишите запрос в несколько строк, и одна
> из них ушла в fail, то откатить исполнившиеся строки нельзя.

не все БД умеют транзакционность DDL (тот же mysql - не умеет)

> 2. Никакая работа с несколькими схемами. Вполне логично было бы разделить миграции
> для разных схем на разные директории, а работать с ними через
> одну программу.

а как же гибкая конфигурация?

> 3. отсутствие downgrade

насколько реально это нужно и как часто востребовано?

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

24. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от Шкурка_от_головки (ok) on 15-Фев-17, 17:26 
> как по мне - очень спорно

Помимо версии указывается еще описание миграции. По мне, так это лучше, чем тyпой таймстамп.

> в чем это проявляется?

Различные префиксы, суффиксы, разделители для именования файлов и т.д. Подробности в комментариях файла конфигурации.

> не все БД умеют транзакционность DDL (тот же mysql - не умеет)

Если программа берет на себя версионность БД, то как-то на уровне ПО можно это реализовать.

> а как же гибкая конфигурация?

Да, не все в ней гладко

> насколько реально это нужно и как часто востребовано?

Ну, это уже у каждого по-разному. Downgrade удобно использовать для отмены миграции, что приводит, соответственно, к уменьшению количества upgrade'ов.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

25. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от Аноним (??) on 15-Фев-17, 17:32 
>> как по мне - очень спорно
> Помимо версии указывается еще описание миграции. По мне, так это лучше, чем
> тyпой таймстамп.

Чем это лучше чем например тyпой таймстамп (для сортировки) и краткое описание миграции? ПОтенциальную проблему с версией я уже выше описал - как по мне это достаточно частый use-case

>> в чем это проявляется?
> Различные префиксы, суффиксы, разделители для именования файлов и т.д. Подробности в комментариях
> файла конфигурации.

хотелось бы услышать про фичи, которые реально нужны и востребованы.

>> не все БД умеют транзакционность DDL (тот же mysql - не умеет)
> Если программа берет на себя версионность БД, то как-то на уровне ПО
> можно это реализовать.

каким способом в данном случае? возможности rollback нет (не уверен, что эта задача в случае pure SQL вообще решается, даже для одной БД). Как по мне - в данном случае претензия не по адресу.

>> насколько реально это нужно и как часто востребовано?
> Ну, это уже у каждого по-разному. Downgrade удобно использовать для отмены миграции,
> что приводит, соответственно, к уменьшению количества upgrade'ов.

Не понимаю. Допустим я добавил миграцию и через пару месяцев решил ее зачем-то откатить. Да, было бы удобно, если бы я просто написал в файле миграции что-то типа "purge migration VXX_****" вместо пачки "ALTER TABLE....", но как это уменьшит количество upgrade'ов? Все равно ведь по сути нужно сформировать эту пачку и провести ее...

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

29. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от Шкурка_от_головки (ok) on 15-Фев-17, 22:33 
> Чем это лучше чем например тyпой таймстамп (для сортировки) и краткое описание миграции? ПОтенциальную проблему с версией я уже выше описал - как по мне это достаточно частый use-case

Да, при наличии двух и более файлов с одной версией он ругается. Но как часто Вы меняете базу, что не можете угнаться за версиями? Поэтому я и говорю о downgrad'е, что если необходимо внести изменения в миграцию, можно было ее downgrade'нуть изменить и upgrade'нуть измененную. А так получается, что при дальнейших изменениях, которые можно было бы объединить в один файл, приходится плодить маленькие миграции, тем самым увеличивая номер версии типи V1_2_45.

> каким способом в данном случае? возможности rollback нет (не уверен, что эта задача в случае pure SQL вообще решается, даже для одной БД). Как по мне - в данном случае претензия не по адресу.

Считаю, что если программа взялась работать с версионностью БД, то нужно это делать намного продуманней. С pure SQL, мне кажется, решается, если ограничить запросы только касающиеся структуры БД, и хранением для каждой миграции состояние структуры изменяемых таблиц. Все-таки на каждое действие должно быть обратное действие, даже если оно будет несколько сложнее начального действия.

> Не понимаю. Допустим я добавил...

Описал в начале, что я имел в виду говоря об уменьшении upgrade'ов.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

30. "Выпуск Flyway 4.1.0, инструмента для контроля версий БД"  +/
Сообщение от Аноним (??) on 15-Фев-17, 23:09 
>Да, при наличии двух и более файлов с одной версией он ругается. Но как часто Вы меняете базу, что не можете угнаться за версиями?

в активной фазе разработки проекта база меняется очень часто. потом пилятся фичи, зачастую параллельно, в итоге - будут конфликты. У нас в основном проекте наваяли самописную подсистему управления миграций, там сделали тупо цифровой номер файла - постоянно конфликты лезут. Но там я хоть при комите вижу этот конфликт и поднимаю версию своего файла до нужной, иначе комит просто не пройдет. В случае же с flyway получается вполне можно закомитить 2 файла с одной версией (но разными именами файлов, т.е. комит пройдет) и проблемы вылезут уже позже... не очень хорошо. можно конечно хуками обвешаться, но это всё равно костыль.


> Поэтому я и говорю о downgrad'е, что если необходимо внести изменения в миграцию, можно было ее downgrade'нуть изменить и upgrade'нуть измененную.

и как ты предлагаешь в таком случае отслеживать изменения миграций? хеш-суммы файлов в базе хранить рядом с версией (и не одну а 3, на случай коллизий)? не, уж лучше так - каждый набор изменений в отдельном файле со своим набором sql операторов. Иначе потом придется по всем миграциям бегать смотреть, кто тебе дев-базу сломал (точнее, лезть в историю VCS), в текущем же варианте - посмотреть нужно будет только последние несколько файлов никуда не переключаясь.

> А так получается, что при дальнейших изменениях, которые можно было бы объединить в один файл, приходится плодить маленькие миграции, тем самым увеличивая номер версии типи V1_2_45.

поэтому я и говорю - решение с номером версии жутко спорное. как по мне гораздо лучше таймстамп и краткое описание в имени файла. количество файлов миграций по большому счету ни на что не влияет.

> Считаю, что если программа взялась работать с версионностью БД, то нужно это делать намного продуманней. С pure SQL, мне кажется, решается, если ограничить запросы только касающиеся структуры БД, и хранением для каждой миграции состояние структуры изменяемых таблиц.

Смотри, нужно для каждого запроса писать "обратный" запрос, который вернет базу в предыдущее состояние. Автоматически такие запросы написать ИМХО невозможно. А пользователи библиотеки такое делать ручками никогда сами не будут. Это решается только своим псевдо-языком миграций, но возникает проблема поддержки всех фич СУБД. Как я понимаю, тут поддерживаются разные СУБД, и нужно следить за изменениями в каждой... Так себе задачка.

И куда девать запросы на изменения данных? Вот нужно заказчику по хитрому условию обновить какое-то поле в большой таблице. Все, эту миграцию мы уже откатить не сможем, т.к. хранить в миграции состояние всех дев/превью/прод баз никто в здравом уме не будет. И разбираться потом, какие миграции откатываются а какие нет - тоже лишний гемор. Гораздо проще добавить новую миграцию.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру