Особенно интересно следующее: 1) Считаете ли вы полезной в реальности возможность

Question

Особенно интересно следующее: 1) Считаете ли вы полезной в реальности возможность

отката назад к версии Х или даже произвольного перехода назад/вперед?
2) Есть кто-нибудь, у кого не цепочка инкрементальных миграций, а генерация diff-а между актуальной и целевой БД и применение этого diff-а к целевой?
3) Если цепочка инкрементальных миграций, то используете ли вы миграторы, которые по сути создают доп.прослойку над DDL (FluentMigrator, Migrator.NET, миграции EntityFramework, ...)? Если да, то что в них вас очаровало по сравнению с простым прямым SQL?

#backend #dot #programming #russian

0

28.04.2019

6 ответов

9 просмотров

Михаил Макарычев

У нас в проекте реализовано 2) через database project. Живём нормально, но иногда (редко) при миграциях случаются нюансы. В домашнем проекте использую evolve. Он при каждом сравнивае актуальность БД с файлами миграций. Минус в том, что приходится ручками писать миграции. Но так больше контроля

0

28.04.2019

Vabka

на прошлой работе писали голый SQL - было норм. FluentMigrator громоздкий очень и всё равно писать много надо - разве что строгая типизация и нормальный автокомплит в помощь. Откат до произвольной версии, кмк, будет полезен раз в миллион лет - и то, оно легко решается, если используется голый SQL. А вот решения, которые строят diff между схемами - збс

0

29.04.2019

Nikita Fedorov

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

0

29.04.2019

Nikita Fedorov

имеет смысл sql + кастомные хелперы для создания таблиц/seq чтобы поддержать кодстайл в названиях таблиц/связей/seq

0

29.04.2019

Nikita Fedorov

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

0

29.04.2019

ιπταμενο ψαρι · Accepted Answer

Код обычно сам берёт и обновляет при новом запуске приложения БД до требуемой версии. 1) На практике с такой потребностью пока не сталкивался. Есть мнение, что FluentMigrator может в такое. 2) Что в данном случае Вы понимаете под diff-ом? Было бы интересно узнать об этом больше, пожалуй. Не пользовался. 3) Есть опыт использования EntityFramework и FluentMigrator. В целом связка Linq2Db+FluentMigrator выглядит гибче, чистый SQL при этом использовать не гнушаемся в сложных ситуациях, которые не покрывает типизированный Fluent API. Из преимуществ типизированного SQL — страхует от опечаток в простых ситуациях, которых обычно больше всего.

170 похожих чатов

Особенно интересно следующее: 1) Считаете ли вы полезной в реальности возможность

6 ответов

Похожие вопросы