Entity Framework Code-First: Как вручную обновить базу данных?
, я создал небольшое демонстрационное приложение WPF, которое использует EF Code-First для сохранения данных в базе данных SQL CE 4.0. Он отлично работает, если я не удалю свойство из объекта модели. Например, если я удаляю "HosteBy" из этого класса .....
public class Dinner
{
public int DinnerID { get; set; }
public string Title { get; set; }
public DateTime EventDate { get; set; }
public string Address { get; set; }
public string HostedBy { get; set; }
public virtual ICollection<RSVP> RSVPs { get; set; }
}
... возникает это исключение:
Модель, поддерживающая контекст 'NerdDinners', изменилась с момента создания базы данных. Либо вручную удалите / обновите базу данных, либо вызовите Database.SetInitializer с экземпляром IDatabaseInitializer. Например, стратегия DropCreateDatabaseIfModelChanges автоматически удалит и воссоздает базу данных и, при необходимости, заполнит ее новыми данными.
Ошибка сохраняется даже после удаления поля «HosteBy» из базы данных вручную. Что мне здесь не хватает? Нужно ли мне удалить / обрезать базу данных или есть другое решение?
1 ответ
В первом сценарии, в котором вы изменили модель Code First, перед тем, как переходить и изменять базу данных вручную, нужно открыть консоль диспетчера пакетов (Nuget) и ввести:
update-database -verbose
Кроме - потому что в этом случае вы удаляете столбец, он сообщит, что собирается что-то удалить, и ничего не удалит, если вы явно не скажете, что все в порядке. Поэтому вы набираете:
update-database -f -verbose
Теперь это удалит столбец, который вы имели в вашей модели. -verbose говорит, чтобы показать вам SQL, который он запускает. Если вы боитесь просто позволить ему удалить что-то и лучше проверить SQL перед запуском, используйте:
update-database -f -script
, который вместо этого выгрузит SQL в Скрипт, который вы можете просмотреть, и запустить его самостоятельно.
В случае, когда вы пошли дальше и удалили столбец в базе данных вручную, теперь у вас есть более сложный сценарий; таблица EdmMetadata, описанная в другом ответе, содержит хэш всей базы данных, который теперь не соответствует самой базе данных. Вы можете запустить SQL вручную, чтобы вернуть базу данных так, как ожидает Entity Framework (как это было до того, как вы вручную изменили ее, что приводит ее обратно в соответствие с хешем), проверив, что у вас было раньше и как выглядит ваша база данных в настоящее время.
Если это невозможно, вы находитесь в самой уродливой части Entity Framework Code First. Вам нужно удалить хеш-таблицу и перепроектировать БД в файлы кода.
Имя хеш-таблицы зависит от версии EF. В более старом EF4, о котором вы спрашивали, он называется EdmMetadata. В более новой версии EF5 она называется __MigrationHistory (в разделе Системные таблицы в вашей базе данных, если вы ищете в SQL Server Management Studio). Вы должны будете стереть это.
Хорошей новостью второго шага, обратного инжиниринга БД в код, является то, что Microsoft выпустила инструмент для бета-тестирования, который сделает это за вас.
Прохождение обратного инжиниринга БД и EF Power Tools
Вы можете пропустить многие из первых шагов, поскольку они просто настраивают БД и добавляют некоторые ерунда, чтобы они могли продемонстрировать, что вам нужно делать: Инженер-обратник и БД.
Обновление:
Можно также использовать ручную миграцию для обхода этого сценария. Сделайте резервную копию базы данных, затем запустите:
add-migration WhateverYouWantToCallThis
Изменения в миграции db EF, которые необходимо выполнить, появятся в сгенерированных командах C #. Теперь вам нужно поработать с ними, чтобы обойти проблемы с тем, что он пытается сделать (например, попытаться удалить уже удаленные столбцы), и поставить на место то, что ему нужно будет продвигать (например, добавив обратно таблица, которая у вас еще есть в вашей модели, но вы удалили ее вручную в своей базе данных).
После того, как вы добавили это и запустили update-database -f, EF Code First просто с верой примет, что вы обновили базу данных так, как она должна быть, и обновит ее хэш на основе конечного результата. Если вы сделали правильные изменения, теперь вы можете продолжить миграцию в обычном режиме. Если это по-прежнему вызывает ошибки, вы обычно можете скопировать команды переноса вручную куда-нибудь и удалить их. Восстановите базу данных из вашей резервной копии, снова добавьте перенос вручную и попробуйте снова. В худшем случае вы прибегаете к описанному выше шагу обратного инжиниринга.