Обновление схемы базы данных при изменении модели без потери данных - PullRequest
Новая
       28

Обновление схемы базы данных при изменении модели без потери данных

3 голосов
/ 22 февраля 2012

Справочная информация : Допустим, я использую структуру сущностей, и одна из сопоставленных сущностей имеет вид: 

class Foo
{
    public int ID { get; set; }
    public string Bar { get; set; }
    // other useful properties
}

С отображением: 

class FooMap : EntityTypeConfiguration<Foo>
{
    // bear me with, I know this is redundant right now
    ToTable("Foo");
    HasKey(e => e.ID);
    Property(e => e.ID).HasColumnName("ID");
    Property(e => e.Bar);
}

Где-то в будущем нам нужно изменить имя столбца на Foo, потому что мой босс говорит мне, что Foo должно иметь более экстравагантное имя, чем ID, иначе наши клиенты будут несчастны. Он говорит нам переименовать его тоже "FooID": 

class FooMap : EntityTypeConfiguration<Foo>
{
    // bear me with, I know this is redundant right now
    ToTable("Foo");
    HasKey(e => e.ID);
    Property(e => e.ID).HasColumnName("FooID"); // Now you map to FooID
    Property(e => e.Bar);
}

В нынешнем виде, если я запустлю это, ничего не изменится. В таблице Foo все еще будет столбец с именем ID, и будет выдано исключение, сообщающее, что столбец FooID не существует.

Вопрос : Как я могу заставить платформу сущностей распознать, что теперь я хочу обновить таблицу Foo, чтобы столбец с именем ID теперь назывался FooID?

В целом, как я могу заставить платформу сущностей автоматически распространять изменения из моего кода в фактическую базу данных (скажем, при запуске приложения) БЕЗ уничтожения существующих данных?

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

Ответы [ 3 ]

4 голосов
/ 22 февраля 2012
2 голосов
/ 07 сентября 2017

Как восстановить данные из кошмара Entity Framework - в базе данных уже есть таблицы с таким же именем

Описание : Если вы похожи на нас, когда ваша команда впервые в EF, вы окажетесь в состоянии, когда вы либо не можете создать новую локальную базу данных, либо не можете подать заявку Обновления вашей производственной базы данных. Вы хотите вернуться к чистой среде EF и затем придерживаться основ, но вы не можете. Если вы работаете на производстве, вы не можете создать локальную базу данных, а если вы работаете на локальном, ваш производственный сервер не синхронизируется. И, наконец, вы не хотите удалять данные производственного сервера.

Симптом : Невозможно запустить Update-Database , поскольку он пытается запустить сценарий создания, а в базе данных уже есть таблицы с тем же именем.

Сообщение об ошибке: System.Data.SqlClient.SqlException (0x80131904): есть уже является объектом с именем '' в базе данных.

Описание проблемы : EF понимает, где находится текущая база данных, по сравнению с тем, где находится код, основываясь на таблице в базе данных с именем dbo .__ MigrationHistory. Когда он смотрит на сценарии миграции, он пытается согласовать, где он был в последний раз, со сценариями. Если это невозможно, он просто пытается применить их по порядку. Это означает, что он возвращается к исходному сценарию создания, и если вы посмотрите на самую первую часть команды UP, это будет CreeateTable для таблицы, в которой произошла ошибка.

Чтобы понять это более подробно, я бы рекомендовал посмотреть оба видео, на которые есть ссылки здесь: https://msdn.microsoft.com/en-us/library/dn481501(v=vs.113).aspx

Решение : Что нам нужно сделать, это заставить EF думать, что текущая база данных обновлена, не применяя эти команды CreateTable. В то же время мы все еще хотим, чтобы эти команды существовали, чтобы мы могли создавать новые локальные базы данных.

Шаг 1: Очистка производственной БД Сначала сделайте резервную копию вашей производственной базы данных. В SSMS щелкните правой кнопкой мыши базу данных, выберите «Задачи> Экспорт приложения уровня данных ...» и следуйте инструкциям. Откройте производственную базу данных и удалите / удалите таблицу dbo .__ MigrationHistory.

Шаг 2: Чистая местная среда Откройте папку с миграциями и удалите ее. Я предполагаю, что вы можете вернуть все это из git, если это необходимо.

Шаг 3: Воссоздать начальный В диспетчере пакетов запустите «Enable-Migrations» (EF предложит вам использовать -ContextTypeName, если у вас несколько контекстов). Запустите «Add-Migration Initial -verbose». Это создаст начальный скрипт для создания базы данных с нуля на основе текущего кода. Если у вас были какие-либо начальные операции в предыдущем файле Configuration.cs, скопируйте их.

Шаг 4: Трюк EF На этом этапе, если мы запустим Update-Database , мы получим исходную ошибку. Итак, нам нужно обмануть EF, думая, что он актуален, без выполнения этих команд. Итак, перейдите к методу Up в только что созданной начальной миграции и закомментируйте все это.

Шаг 5: Обновление базы данных Не имея кода для выполнения в процессе Up, EF создаст таблицу dbo .__ MigrationHistory с правильной записью, сообщающей, что он правильно выполнил этот сценарий. Иди и проверь, если хочешь. Теперь раскомментируйте этот код и сохраните. Вы можете запустить Update-Database еще раз, если хотите убедиться, что EF считает, что он обновлен. Он не выполнит шаг Up со всеми командами CreateTable, потому что думает, что это уже сделано.

Шаг 6: Подтвердите, что EF действительно актуальна Если у вас был код, к которому еще не применены миграции, это то, что я сделал ...

Запустите «Добавить-миграцию, пропущенную миграцию» Это создаст практически пустой скрипт. Поскольку код уже был там, на самом деле были правильные команды для создания этих таблиц в начальном сценарии миграции, поэтому я просто вырезал CreateTable и эквивалентные команды удаления в методы Up и Down.

Теперь снова запустите Update-Database и посмотрите, как он выполнит ваш новый скрипт миграции, создав соответствующие таблицы в базе данных.

Шаг 7: Подтвердите и подтвердите. Сборка, тестирование, запуск.Убедитесь, что все работает, затем передайте изменения.

Шаг 8: Сообщите остальным членам вашей команды, как действовать. Когда следующий человек обновится, EF не будет знать, что поразило его.учитывая, что скрипты, которые он запускал раньше, не существуют.Но, предполагая, что локальные базы данных могут быть снесены и воссозданы, это все хорошо.Им нужно будет удалить свою локальную базу данных и снова добавить ее в EF.Если бы у них были локальные изменения и ожидающие миграции, я бы порекомендовал им снова создать свою БД на главном компьютере, переключиться на свою функциональную ветку и заново создать эти сценарии миграции с нуля.

1 голос
/ 22 февраля 2012

вы должны использовать Entity Framework Migrations, чтобы сделать это

использовать эту ссылку

...