Как сделать миграцию entity framework
Как включить миграцию 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-от ограничивает?
Что делает убогий императивщик?
А что сделает божественный дб-щик?
А что сделает божественный дб-щик?
Это тоже не имеет значения. Такой подход как ты говоришь будет работать только, если каждый разработчик делает изменения, никак не связанные с изменениями других людей.
Читайте также: