Открыть список
Как стать автором
Обновить

Комментарии 5

НЛО прилетело и опубликовало эту надпись здесь
Имеется в виду добавить такой функционал в библиотеку?

Честно говоря подобный сценарий пока не рассматривался и я не совсем представляю ситуацию когда такое может понадобится. С изменениями в структуре БД и сопутствующими им добавлениями/изменениями в данных неплохо справляются миграции в EF (Core).

Если надо добавить некоторые данные по-умолчанию, которых не было в первой версии продукта, но они появились позже — то DbInitializer с таким справится. Не будет только удаления того, чего нет в «мастер» базе и это, наверное, хорошо.

В общем, хотелось лучше понять сценарий, когда нужен именно diff.
Имеется в виду добавить такой функционал в библиотеку?

Честно говоря подобный сценарий пока не рассматривался и я не совсем представляю ситуацию когда такое может понадобится. С изменениями в структуре БД и сопутствующими им добавлениями/изменениями в данных неплохо справляются миграции в EF (Core).

Если надо добавить некоторые данные по-умолчанию, которых не было в первой версии продукта, но они появились позже — то DbInitializer с таким справится. Не будет только удаления того, чего нет в «мастер» базе и это, наверное, хорошо.

В общем, хотелось лучше понять сценарий, когда нужен именно diff.
Статью глянул по диагонали, но. Если у вас уже EF, то зачем привязка к конкретным СУБД? Вычитали эталонную базу в объектную модель. Сериализовали в JSON/XML файл. При развёртывании — в обратном порядке. EF позаботиться о том, чтобы можно было с любой БД работать. Если поменялась схема, то это всё равно решается на уровне чтения файла с сериализованными данными.
Была такая мысль. Если глянете в репозиторий, то увидите, что там даже есть проект Korzh.DbUtils.EntityFrameworkCore, который, правда, пока так и не опубликован в качестве NuGet пакета. Причин этому несколько:

1. Не все проекты используют EF (Core). Есть еще Dapper, NPoco, Massive и куча других micro-ORM. Есть проекты, которым просто надо выполнять пару SQL запросов и они делают это просто через DbConnection/DbCommand. Но инициализировать БД нужно и в этом случае.

2. Сделать отдельные «мосты» к разным БД все равно пришлось по двум причинам:
  • Собственно, для утилиты командной строки DbTool
  • Для импорта данных в БД, в таблицах которых есть ключи с автогенерацией и внешние ключи (foreign keys). То есть практически для любых БД. В этом случае при записи в таблицу нужно временно отключать проверку ограничений (типа `SET IDENTITY_INSERT TableName OFF`). Для разных БД это делается по разному — поэтому все равно нужен был дополнительный пакет с этим функционалом для каждой конкретной СУБД.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.