Как сделать миграцию entity framework

Обновлено: 05.07.2024

Как включить миграцию Entity Framework 5 (версия 5.0.0) для нескольких контекстов БД в том же проекте, где каждый контекст соответствует собственной базе данных? Когда я запускаю Enable-Migrations в консоли PM (Visual Studio 2012), появляется ошибка из-за наличия нескольких контекстов:

Если я запустил Enable-Migrations -ContextTypeName DatabaseService.Models.Product1DbContext , мне не разрешено запускать Enable-Migrations -ContextTypeName DatabaseService.Models.Product2DbContext , потому что миграция уже существует: Migrations have already been enabled in project 'DatabaseService'. To overwrite the existing migrations configuration, use the -Force parameter.

Второй вызов Enable-Migrations не работает, потому что файл Configuration.cs уже существует. Если вы переименуете этот класс и файл, вы должны будете запустить эту вторую Enable-Migrations, которая создаст другую Configuration.cs.

Затем вам нужно указать, какую конфигурацию вы хотите использовать при обновлении баз данных.

В дополнение к тому, что предложил @ckal, это критический, чтобы дать каждому переименованному Configuration.cs собственное пространство имен. Если вы этого не сделаете, EF попытается применить миграции к неправильному контексту.

Вот конкретные шаги, которые хорошо работают для меня.

Если Миграции перепутаны, и вы хотите создать новую "базовую линию":

Удалите все существующие файлы .cs в папке Migrations
В SSMS удалите системную таблицу __MigrationHistory.

Создание начальной миграции:

В консоли диспетчера пакетов:

В обозревателе решений: переименуйте Migrations.Configuration.cs в Migrations.ConfigurationA.cs. Это должно автоматически переименовывать конструктор при использовании Visual Studio. Убедитесь, что это так. Изменить ConfigurationA.cs: изменить пространство имен на NamespaceOfContext.Migrations.MigrationsA

В обозревателе решений: переименуйте Migrations.Configuration.cs в Migrations.ConfigurationB.cs. Опять же, убедитесь, что конструктор также переименован соответствующим образом. Изменить ConfigurationB.cs: изменить пространство имен на NamespaceOfContext.Migrations.MigrationsB

Шаги по созданию сценариев миграции в консоли диспетчера пакетов:

ОК, чтобы повторно запустить эту команду, пока в базу данных не будут внесены изменения.

Либо запускайте скрипты с нужной локальной базой данных, либо запустите Update-Database без - Script, чтобы применить локально:

Я просто столкнулся с той же проблемой, и я использовал следующее решение (все из консоли диспетчера пакетов)

Это создаст две отдельные папки в папке Migrations. Каждый из них будет содержать сгенерированный файл Configuration.cs . К сожалению, вам все равно придется переименовывать те файлы Configuration.cs , иначе будут жалобы на наличие двух из них. Я переименовал свои файлы в ConfigA.cs и ConfigB.cs

РЕДАКТИРОВАТЬ: (вежливость Кевин МакФит) Помните при переименовании файлов Configuration.cs, также переименуйте имена классов и конструкторы /EDIT

С помощью этой структуры вы можете просто сделать

Что создаст файлы кода для миграции внутри папки рядом с конфигурационными файлами (это хорошо, чтобы сохранить эти файлы вместе)

И последнее, но не менее важное: эти две команды будут применять правильные миграции для своих корневых баз данных.

РЕДАКТИРОВАТЬ 08 февраля 2016 года: Я провел небольшое тестирование с EF7 версии 7.0.0-rc1-16348

Однако похоже, что при первом добавлении переноса он добавляется в папку Migrations, а последующая миграция для другого контекста автоматически помещается в поддокладчик миграции.

Оригинальные имена ContextA , похоже, нарушают некоторые соглашения об именах, поэтому теперь я использую ContextAContext и ContextBContext . Используя эти имена, вы можете использовать следующие команды: (обратите внимание, что мой dnx по-прежнему работает из консоли диспетчера пакетов, и я не люблю открывать отдельное окно CMD для миграции).

Это создаст моментальный снимок модели и начальную миграцию в папке Migrations для ContextAContext . Он создаст папку с именем ContextB , содержащую эти файлы для ContextBContext

Я вручную добавил папку ContextA и переместил файлы миграции из ContextAContext в эту папку. Затем я переименовал пространство имен внутри этих файлов (моментальный снимок, начальную миграцию и заметьте, что есть третий файл в файле начальной миграции. designer.cs). Мне пришлось добавить .ContextA в пространство имен, и оттуда фреймворк обработает его автоматически снова.

Использование следующих команд создаст новую миграцию для каждого контекста

Выполнил рекомендации из вот этого решения и получил:

В менеджере nuget "Microsoft.EntityFrameworkCore, Version=2.1.4.0" не находится - там уже давно более поздняя версия 2.2.2.
Куда копать дальше? Есть ли у кого-то какие-то идеи?

Entity Framework
Здравствуйте, есть проблема с Entity Framework, как источник данных я указал объекты созданные.

Entity Framework and FluentApi
Всем привет. Есть у меня класс модели, описывающий статусы: public class Status < .

Навигационные свойства в Entity Framework
Всем привет! Помогите разобраться с навигационными свойствами в EF. Уже перечитал и msdn и другие.

Сохранение картинки Entity Framework
Пытаюсь сохранить картинку в базу данных. Использую entity fraemwork. using (AgroFirst db =.

В менеджере nuget "Microsoft.EntityFrameworkCore, Version=2.1.4.0" не находится - там уже давно более поздняя версия 2.2.2.

Так вы используете EF 6.2 или EF Core 2.2.2?
Это абсолютно разные вещи, EF Core написан полностью с нуля.

Наверное, в первую очередь стоит определиться с библиотекой, которая должна использоваться.
После чего создать класс, наследующийся от DbContext.

использую EF Core 2.2.2, прошу прощения, что ввел в заблуждение.

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

Тогда не надо использовать команду Enable-Migrations — она в Core не нужна. Используйте сразу Add-Migration .

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

Хм. странно. Решил проверить может быть у меня что-то не то с самим проектом и создал в том же решении еще один проект для теста. Установил в него EF Core, EntityFramework (без него команад Enable-Migrations не хотела работать), а затем создал класс Context : System.Data.Entity.DbContext . После этого команда Enable-Migrations нашла контекст и выполнилась (хоть и с ошибками)

Неужели у EF Core не реализована возможность создавать миграции?

Тогда не надо использовать команду Enable-Migrations — она в Core не нужна. Используйте сразу Add-Migration.

не удается вставить значение NULL в столбец "директор", таблица 'MOVIES_cf7bad808fa94f89afa2e5dae1161e78.ДБО.Фильмы'; колонка не делает разрешить значения null. Сбой обновления. Заявление было прекращено.

Это связано с тем, что некоторые записи имеют значение NULL в их Director столбцы. Как я могу автоматически изменить эти значения на некоторые значения по умолчанию (скажем, "John Doe") директор?

и вот моя последняя миграция:

Если я правильно помню, что-то вроде этого должно работать:

В дополнение к ответу от @webdeveloper и @Pushpendra, вам нужно вручную добавить обновления в вашу миграцию, чтобы обновить существующие строки. Например:

Это так AlterColumn производит DDL, чтобы установить значение по умолчанию столбца на некоторое конкретное значение в спецификации таблицы. DDL не влияет на существующие строки в базе данных.

вы фактически делаете два изменения одновременно (устанавливая значение по умолчанию и делая столбец не нулевым), и каждый из них они действительны индивидуально, но поскольку вы делаете их одновременно, вы можете ожидать, что система "разумно" реализует ваше намерение и устанавливает все NULL значения по умолчанию, но это не то, что ожидалось все время.

предположим, что вы только устанавливаете значение по умолчанию для столбца, а не делаете его NOT NULL. Вы, очевидно, не ожидаете, что все нулевые записи будут обновлены с помощью значения по умолчанию, которое вы предоставляете.

Так что, по-моему, это не баг, а я не хочу, чтобы EF обновлял мои данные так, как я явно не говорю ему делать. Разработчик несет ответственность за инструктаж системы о том, что делать с данными.

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

defaultValueSql: "'NY'"

я получил ошибку, когда предоставленное значение было "NY" тогда я понял, что они ожидают значение SQL, как "GETDATE()" Так я пробовал "'NY'" и это сделало трюк

вся строка выглядит так

AddColumn("TABLE_NAME", "State", c => c.String(maxLength: 2, nullable: false, defaultValueSql: "'NY'"));

спасибо ответ, я на правильном пути

Я обнаружил, что просто с помощью инициализатора Auto-Property на entity property достаточно, чтобы выполнить эту работу.

например:

по какой-то причине, что я не смог объяснить себя, одобренный ответ больше не работает для меня.

он работал на другом приложении, на том, что я работаю, это не так.

да, альтернатива, но довольно неэффективно, решение было бы переопределить метод SaveChanges (), как показано ниже. Этот метод должен быть в классе контекста.

Как уйти в разработку на локальной копии, а потом накатить апдейт на рабочую базу??

Мээээ. Так а что делать мне?

Если ты под скриптами имеешь ввиду то, что видно в студии - то эти "скрипты" генерятся при add-migration команде.

Чо та толсто как-та.

Ээммм. секунды тут не при чём, миграция основывается на конкретной предыдущей миграции. Я не в курсе какие у вас там были миграции, но Entity Framework хрен даст тебе сунуть свою миграцию, если кто-то постарался и успел сунуть свою. Не имеет значения ни номер спринта, ни дата до секунды, -- и это очень правильно.

Так как тебя EF-от ограничивает?

Что делает убогий императивщик?

А что сделает божественный дб-щик?

Это тоже не имеет значения. Такой подход как ты говоришь будет работать только, если каждый разработчик делает изменения, никак не связанные с изменениями других людей.

Читайте также: