#c# #entity-framework #entity #code-first
#c# #entity-framework #сущность #сначала код
Вопрос:
Я впервые использую Entity Framework code first в производственной среде. Все шло нормально, пока мы не запустили базу данных и не поместили в нее часть данных, а затем, чтобы получить часть данных, которые мы импортировали из другого местоположения, нам пришлось изменить длину полей. Итак, мы сделали некоторые поля nvarchar (99) вместо nvarchar (50).
Все прошло нормально, и приложение все еще работало, но я знал, что мне нужно изменить аннотацию данных, иначе она взорвется позже, когда загрузится и попытается сохранить слишком длинное поле. Когда я это сделал, приложение взорвалось, хотя модель и база данных теперь совпадают. Итак, я подумал, что это хэш в таблице метаданных, поэтому я подумал, что буду умным и создам новую базу данных, возьму хэш оттуда и скопирую его. Это не сработало, и фактически теперь я вообще не могу подключить свое приложение к тестовой базе данных, в которую у нас загружены данные.
Я не хочу удалять и воссоздавать эту базу данных. Я хочу, чтобы entity Framework осознал, что модель и схема действительно совпадают. Есть ли у меня какой-нибудь способ сделать это? Также почему копирование метаданных из базы данных, созданной entity Framework с помощью этой модели, не сработало?
Комментарии:
1. Это на том же сервере базы данных? Если нет, то являются ли серверы баз данных одной и той же версией?
2. Не могли бы вы пояснить, что вы имеете в виду, когда говорите: «… приложение взорвалось?» Это не дает нам многого для продолжения.
Ответ №1:
Код Entity Framework сначала создает EdmMetadata таблицу и сохраняет в ней хэш ваших классов модели. Когда вы что-то меняете в модели, хэш новых классов модели больше не соответствует тому, что находится в EdmMetadata таблице, и приложение должно «взорваться» во время выполнения. Что вам нужно сделать, чтобы продолжать использовать ту же базу данных, не удаляя ее, так это удалить EdmMetadata таблицу. Таким образом, EF не будет выполнять эту проверку и попытается продолжить доступ к базе данных.
Ознакомьтесь с этим видеоуроком (перейдите к 8: 10 раздела «При смене классов»).
Комментарии:
1. Я понимаю эту часть. Я думал, что смогу обойти это, позволив приложению создать новую базу данных где-нибудь еще на сервере и скопировать метаданные, но оказывается, что за кулисами происходит нечто большее, чем просто хэширование модели. Я попытался удалить таблицу метаданных, и приложение запустится сейчас и не жалуется, пока не попытается получить доступ к отношениям «многие ко многим», которые у меня были. Теперь я получаю сообщение об ошибке — $exception {«Произошла ошибка при выполнении определения команды. Подробности см. во внутреннем исключении.» } Внутреннее исключение- InnerException {«Недопустимое имя объекта»dbo. GroupPersons’.»}
2. Возможно, при хэшировании классов модели происходит какая-то «магия», я не знаю об этом. Эта ошибка, которую вы получаете сейчас, вероятно, связана с тем, что модель не соответствует базе данных. Похоже, EF ожидает таблицу с именем dbo. GroupPersons и в базе данных нет такой таблицы.
Ответ №2:
Извините, я это исправил. Удаление метаданных сработало. Но, оказывается, я случайно обновился до более поздней версии EntityFramework, пытаясь решить свою проблему, и эта более поздняя версия ожидала других соглашений об именовании для базы данных. В любом случае, воссоздание таблицы групповых пользователей «многие ко многим» с помощью скрипта из базы данных, созданной Entity Framework, и удаление метаданных устранили проблему.
Комментарии:
1. На самом деле это неправильно. Это была вовсе не новая версия entity Framework (слава богу), скорее это был просто фрагмент кода, который я закомментировал, который определял отношение «многие ко многим», и без этого фрагмента кода EF ожидал чего-то другого.