Миграции с EF.Где они хранятся?

Question

Вчера я был абсолютно уверен, что все данные о миграции для EF, помещенные в классы, помещены в мое решение как вложенные из DbMigration. Но сегодня я стал копать немного глубже (просто попробуйте вернуться к старой миграции с включенной потерей данных не с nu-get и visual studio, а с code ())

DbMigrator fg = new DbMigrator(new Settings() { AutomaticDataLossEnabled = true});

fg.Update("MigrationName");

И получить исключение, что-то вроде «строка должна быть усечена», это означает, что переносчик попытался обновить столбец с большого на маленький атрибут MaxLength. Итак, я исключил миграцию, которая вызвала это обновление, и перенес эти изменения в миграцию, те, которые создают таблицы. Ошибка все еще произошла. Я добрался до intellitrace, и он сказал, что те (удаленные) миграции все еще назывались. Глядя на запросы сказал мне такие вещи:

SELECT [Extent1].[MigrationId] AS [MigrationId] FROM [dbo].[__MigrationHistory] AS [Extent1]    

Посмотрите на таблицу __MigrationsHistory и получите там мою удаленную миграцию с полем model , которое содержит зашифрованные данные (пока не расшифровывайте это). Я был действительно шокирован. Означает ли это, что весь код, написанный в классах, является просто поддельным и действительно исполняемым кодом, размещенным здесь? И кто-нибудь знает, как работать с этой таблицей, регистрировать проекции классов миграции на нее и т. Д. Или единственный способ работы с миграциями - консоль nu-get?

Answer 1

Я не совсем уверен, каков ваш основной вопрос, поэтому я сначала попытаюсь ответить на последнюю часть о __MigrationHistory таблице.

Код в классах: не фальшивка, ваш кодв классах компилируется и запускается.

Эта таблица, однако, действительно содержит модель вашей базы данных, но она не зашифрована, она сжата.Причина, по которой Migrations API должен хранить вашу модель, состоит в том, чтобы иметь возможность сравнивать ее с вашей текущей фактической моделью и отслеживать изменения для вас (например, когда вы добавляете новое свойство, оно сможет сказать, какое свойство вы добавили, и выполнить).автоматическая миграция базы данных).

В предыдущей версии EF была таблица EdmMetadata, в которой хэш вашей модели был сохранен, и EF смог определить, вносили ли вы какие-либо изменения в модель, сравнивая значение хеш-функции сохраненной и текущей модели,В новой версии, когда миграция включена, вся модель хранится в виде сжатого большого двоичного объекта, поэтому она может выполнять diff между моделью, которая использовалась для создания базы данных, и используемой вами текущей моделью, и соответственно выполнять автоматические миграции.

Вы не должны работать непосредственно с этой таблицей, она автоматически заполняется API-интерфейсом миграций, но консоль nuget - не единственный способ выполнения миграций, вы можете проверить ресурс , чтобы узнать, как это сделать изcode.

Теперь, что касается вашего вопроса из заголовка вопроса (где они хранятся?), миграции хранятся в коде, в классе, унаследованном от класса DbMigration, который API-интерфейс миграций создает для вас при выполнении Add-Команда миграции в консоли nuget.Когда вы выполняете миграцию (Update-Database), либо из консоли диспетчера пакетов nuget, либо из кода, API будет сравнивать вашу текущую модель с версиями в __MigrationsHistory, чтобы найти начальную версию (если вы ее не указали), и выполнить все миграции вмежду начальной и целевой версией (если не указано иное, цель является последней версией).

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

Может быть, вы могли бы решить проблему возврата к старой версии, внедрив в свою миграцию метод public override void Down(), который вызывает проблемы при попытке отката?Этот метод может использоваться для выполнения кода, который выполняет обратные любые операции для миграции.

Не имеет прямого отношения к вопросу, но стоит упомянуть, здесь также есть довольно подробное руководство для EF CF.