За развитието и ефективността на код първи миграции лице рамка 4
На снимката на пеперуда монарх миграция (CC BY-NC-ND 2.0, originalzdes).
В тази статия, от моя гледна точка, разбира се, да отговори на въпросите, подкрепени с примери:
- Какво е миграцията и какви са те за?
- Какво е интересно в тази версия и в EF Код Първи миграции по принцип?
Мисля, че едва ли някой използва миграция в ежедневието търговско развитие. Така че аз няма да се разпредели изрично списък с нови функции и просто ще говорим за миграция, подчертавайки отделно в новия EF 4.3 Beta 1.
Между другото, може би ще се интересуват, че освобождаването на EF 4.3 е планирано за първото тримесечие на тази година. Единственото жалко е, че освобождаването на EF 5.0 с поддръжка на ENUM и оптимизиране на скоростта на всеки един от нас чака скоро - с пускането на .NET 4.5 само EF 5.0 ще Beta 1.
Кратко описание на миграциите
Миграция EF предназначен за справяне с промените в структурата на базата данни в еволюцията на заявлението. Едно решение на този проблем, аз изрази по-рано в статията "Принципи на SQL - DDL и база данни рефакториране". Надявам се, че когато той е готов EF Код Първи миграции, той ще бъде много по-добре, отколкото подхода със скриптове.
Важна забележка: най-важното, за което искате да следите, когато мигрират бази данни като цяло, освен да отговарят структура - безопасността на данните на клиентите.
Малко вероятно е, че искате, след като инсталирате новата версия на клиента (или по-лошо - клиенти), за да се знае, че системата за автоматична миграция е премахнал някои от данните, и клиентът се мисли за сметка на някой компенсира загубата на парите си ...
На следващо място, аз ще осигури типичен пример за работа с миграции, но първо нека да зададете всички.
Как да се инсталира?
На първо място бих искал да кажа, че това е бета версия, с всички произтичащи от това рискове. На второ място, Код Първи миграции сега са включени в ЕФ и не е необходимо да се инсталират отделно.
Със сигурност знаете, че за монтаж NuGet-пакети-лесно да напишеш в конзолата за Мениджър на пакети (наричани PM), така че аз ще разглеждаме само този метод. Монтаж на действия, е както следва:
- Ако пакетът е "Код Първи миграции Beta 1" е създаден:
За да се ускори писането на един пример, аз използвам Модел скеле. Ето защо, аз ще добавя още една по избор, в общия случай, стъпка:
Примери за работа с миграции
Тези, които са работили с миграции може да преминете към следващия раздел.
Вие все още сте тук. ) След това нека да разгледаме един прост пример - добавяне на модел, а след това го добавите към нов имот, а след това да я премахнете. Данните с новите вградени механизми ще мигрират.
Създаване на свързването към базата данни
Ще използвам SQL Server Express. като опция, предложен от подразбиране. За бърза връзка на нашата DbContext в web.config копирате съществуваща връзка низ (по подразбиране ApplicationServices) и го добавете с името, което съвпада с името на контекста:
Важна забележка: Без фразата "Database = aspnetdb.mdf" заявлението и миграцията няма да работи правилно (по подразбиране, тази фраза не се появи в низа за връзка).
Създаване на първата версия на модела
Сега, за да се създаде много прост модел, ще се въведе следната команда:
Ако прочетете моята статия за ModelScaffolding вие вече знаете, че това ще създаде следния модел (и всички тръбопроводи за да го редактирате в ASP.NET MVC приложение - контролер и представянето):
Нека да тече нашата молба, като към URL адреса "Тестове" (можете да го направите веднага да се създаде проект за спестяване на време и в бъдеще) и да въведе малко данни.
Искам да обърна внимание на факта, че аз не съзнателно свързан миграцията, за да проверите как ще работят в ситуация, в която данните са вече там, и миграцията все още не са свързани.
Гледайки напред да кажа, че въпреки предупреждение от блога на ADO.NET екип долу, с грешки, не съм имал възможност да се срещнат, както изглежда, че е твърде позитивно настроение :)
Забележка: Има още редица грешки в функционалността на скриптове в EF 4.3 бета1, които пречат на вас генериране на скрипт, като се започне от миграция, различна от празна база данни. Тези грешки ще бъдат фиксирани във финалния RTM.
Промяна на модела и първата миграция
За да се даде възможност на миграция се сега (от версия 4.3 EF), можете просто да изпълните следната команда:
Към това се добавя към папка на проекта и досието на "Миграции" "Configuration.cs". Ако сте съгласни с поведението по подразбиране, трябва да изключите автоматичното миграцията, няма нищо общо вече. В случаите, когато DbContext-ите ще бъде много необходимо да се добави малко файла ръчно.
Ако се компилира приложението и го отвори, получаваме следната грешка недвусмислено:
Моделът архивиране контекста "MvcEfDemoContext" е променена след създаването на базата данни. Помислете за използване Код Първи миграции за актуализиране на базата данни.
Всичко е логично - моделът се е променило, основата - не. Нека да мигрират. Изпълнете командата за добавяне на миграцията:
Като параметър премина към името на миграция (името на файла ще бъде добавен към левия текущото време). Вие сте свободни да изберат схема за именуване. Например, ако искате непрекъсната номерация - обадете се на миграцията във формат "00 000". Лично аз предпочитам варианта с смислено име, тъй като поръчката вече дадено от текущото време.
След успешното завършване на тази команда, ние получаваме един клас по миграция, която съдържа два метода:
Както можете да видите, миграцията поддържа автоматично генериране и прилагане, и се връщам на промените, които работи, поне за прости случаи.
Сега, ние имаме няколко опции, за да се движат на миграцията:
- Приложете промените директно в базата данни - най-бързият и най-лесният вариант (за изход да се изпълнява команди, можете да добавите опция за подробно, достъпно от версия 4.3 EF):
Отново можете да решите как ще бъде построен на процеса на миграция. Така например, в началото можете първо да генерира скрипт и да направи своя преглед. След това, ако всичко е наред, можете просто да се актуализира базата данни. Естествено, бих препоръчваме да тествате щателно всички нови миграция заедно с останалата част от кода, преди освобождаването на клиентите.
В нашия случай, първата миграция ще добави колона E-mail:
В допълнение, ще бъдат създадени таблиците на услуги за съхраняване на информация за миграцията на базата данни.
Ако изпълните командата Актуализация база данни, и да го завърши с грешка "Може да се отвори базата данни ... поискано от вход." Или "не може да се създаде файл" ... ", защото тя вече съществува.", Уверете се, че низ връзка е посочено "Database = aspnetdb. мдф "и студиото не е открита връзка към вашата база данни.
Финализиране
Нарочно остави дължината не е уточнено Email, така че сега можем да видим как се случва, миграция, когато промените свойствата на атрибута. StringLength добавяне атрибут към имота, отново добавяйки да мигрират и да го стартирате:
С преминаването на класа ще получите всичко е наред, той съдържа следните методи:
Но след като се започне миграцията върна грешка по този начин:
Обектът "DF__Tests__Email__014935CB" зависи от колона "E-mail". ALTER TABLE ALTER КОЛОНА Email неуспешно, защото един или повече предмети, достъп до тази колона.
Тук имам претенции към реализацията на миграция, а не на факта, че промяната в графата "не на пълен автоматичен", както и че при създаването на колона не е кръстен DEFAULT ОГРАНИЧЕНИЯ "DF_Tests_Email". Поради тази причина на този етап ние ще трябва да мигрират podkovyrivat малко повече, отколкото трябва. Оказа се:
Както можете да видите, не е нищо необичайно, но на сегашния DEFAULT-ах виждаше Entity Framework - поне да се опита да го пресъздаде по същия начин, след промяна на колоната - ако това не се е случило, тогава има dopilivat ръце.
Се връщат назад миграция
Сега (от версия 4.3 EF. Въпреки, че може би това беше в предишната Beta, което не съм виждал), можете да се откажете от миграцията. Можете да направите това с помощта на "TargetMigration", което трябва да се каже, също работи в миналото и в бъдещето (когато искате да прилага по отношение на миграцията на базата данни не е нова).
Проблеми възникват, когато намаление на цените не е (защото методът е "Надолу", аз се коригира по-горе, заедно с метода на "Up").
Премахване на колона
За да премахнете колона, можете просто да пресъздадете модела в първоначалния си вид (не в дясно от представителство) и повторете процеса на създаване и прилагане на миграцията:
Ако не използвате "Update-Database" намаление на цените след миграцията, не можете да добавите нов, това, което ще бъде известен като грешка:
Този проблем се коригира, без да поема "Update база данни", истината ще бъде предупреждение в резултат на това:
Не може да се прилага от предстоящите промени, тъй като автоматично миграция е забранено. За да активирате автоматичното миграция, се гарантира, че DbMigrationsConfiguration.AutomaticMigrationsEnabled е настроен да е вярно.
Автоматично миграция в този случай да включва евентуално повторение достатъчно команда за добавяне на миграцията, а след това се актуализира базата данни.
Добавяне на свързан модел
За да видите как работи миграция със сродни модели ги създават:
След добавянето на миграция ще изглежда така:
Имайте предвид, че механизмът за миграция се грижи за нас, създаване на табели на стълбове, които участват в външен ключ. Мисля, че е по-добър, отколкото лош, особено след като можете просто да премахнете индекса на този етап.
Когато актуализирането на базата данни в този случай тя ще бъде дадена грешка, защото графата "CategoryId" ще се опита да запълни стойност 0 и стойност в таблица "Категория" на само по себе си не се появява.
Мисля, че вече знаете достатъчно, за да се справят с решаването на този проблем сами по себе си. Ще дам само един намек, че при регулиране на миграцията е достъпно не само изпълнение на SQL директно, но настройките в кода. Например, методът на "ColumnBuilder.Int" могат допълнително да премине параметър "defaultValue".
автоматизирано миграция
Аз ще кажа малко за вече споменатите автоматична миграция. Възможно е да се използва режим, когато не е необходимо да се добавят миграция изрично помощта на командата "Add-Миграция". Този режим е включен в клас "Configuration" с имота "AutomaticMigrationsEnabled".
Добър или лош - това зависи от твърде много фактори. Мога само да добавя, че никой не си прави труда да добавите автоматично миграция изрично, когато това е необходимо.
В допълнение към автоматичен режим е възможно да се управлява миграцията на миграцията в началото на приложение, използващо MigrateDatabaseToLatestVersion инициализатор база данни (на разположение от версия EF 4.3).
Какво остава зад кулисите
За да не се издуват статията, аз не се появи по-сложни вариации (промени в свързаните таблици и т.н.). Разбира се, нещо, което работи автоматично, нещо трябва да dopilivat.
Аз също не се обърне внимание на следните новости в EF 4.3:
- Добавен достатъчно подробна документация за XML-миграционни класове.
- Изключение маси "EdmMetadata" - Сега, когато за първи път се създаде база данни в стила на Code First без миграция, миграция все още се използва в автоматичен режим :)
- Двойка от корекции на грешки (GetDatabaseValues и Unicode поддръжка DbSet).
- Код Първо сега разбира, анотации за затворени свойства.
- Добавена е поддръжка на конфигурацията в конфигурационния файл.
Английски Кликнете тук, за повече подробности.
Досега това, което виждам в EF 4.3 по отношение на миграцията ми харесва, с изключение на някои недостатъци. Разбира се, опитайте миграцията наистина само в употреба в търговско развитие. Ще те чакам :)
И защо е решил, че ако областта е може да се анулира, е необходимо да се мотае по подразбиране konstreyt с генерирано име и празна стойност? Би било добре, ако те се опитаха да EF като ORM някак си по-близо до хотел NH :(
По мое мнение, това са ситуации, поради което всички avtomigratsii обречени на провал - запис на данни схема миграция може и да го предават прости действия - добавяне / премахване на колона / маса / konstreynt. Но миграция на данни е почти невъзможно да се автоматизира. Въпреки това, добавянето на имейл - ако ние се уточни, че областта трябва да има стойност, празен низ - патерица, а не стойността.
Аз използвам Migrator.Net - това решава всички проблеми на инфраструктурата, както и на разработчика е най-актуалната код миграцията.
За да @Vasiliy Shiryaev:
И какво щеше да се случи, като се има предвид факта, че има данни в таблицата? Между другото, никой не си прави труда да се коригира миграция код преди употреба.
Тези прости неща, като посочите друг подразбиране са написани директно в кода, в случай на прехвърляне на данни може да се започне метод Sql (например в статията е).
Поради това, не е ясно какво предимство Migrator.Net - че не предлага решения за прости случаи? )
Какво трябва да се случи? Това зависи от ситуацията. Това най-вероятно няма да се изисква не нула цяло, за окачване на един празен ред, а не по подразбиране нулеви полета са повече от достатъчно, IMHO.
Вторият въпрос, който от своя страна имат изрази за konstreynta име, и се добавя към тази патерица.
Да, Migratora.Net предимство е, че той не предлага решения криви за прости случаи, за които е необходимо да се следват и след това проверете :)
За да @Vasiliy Shiryaev
> За висящи празен ред, а не по подразбиране нулеви полета са повече от достатъчно, IMHO.
Сега знаех, че това, което ние трябваше да загуби синхрон :)
За имоти с атрибут * Задължително * - не е достатъчно.
И по мое мнение, все пак е странно - * Задължително * означава, че е необходимо областта да направи разликата. Празна стойност - това е някак си странно в контекста * Задължително *, но приемлив - ако нямате повече опции за текущите данни. И тук е по подразбиране за нови данни konstreynt точно веднъж.
Тук Migrator трябваше да направя нещо:
- създайте празен поле
- зададете всички линии към стойността по подразбиране
- актуализиране на полето, за да не нула.
За да @Vasiliy Shiryaev:
> Тук Migrator трябваше да направя нещо.
Това, казват те, вкус и цвят.
Бях в подхода към създаването на по подразбиране ограничение разстроен от факта, че той не е бил при нормално име.
Напомням ви, че, ако е необходимо, в миграцията може лесно да бъде настроен по подразбиране, без използването на SQL-код.
Що се отнася до Migrator като цяло - Мисля, полза или вреда от употребата зависи от целите и екипа. Някой ще бъде по-полезен на някого вреда.
Как да се кодират първа употреба съхранени процедури?
Добър ден. Очевидно в описанието на пример, който пропуска необходимите детайли.
Създадената контекста не съдържа context.Test, който генерира помощник. Когато коригиране на context.Tests, не работи под prvedenny контролер
обществен TestController клас. контрольор
контекст лично MyMvc3Context = нов MyMvc3Context ();
обществен Index ViewResult ()
Вижте върне (context.Tests.ToList ());
Generiruettsya грешка: Видът "тест" не се дължи с EdmEntityTypeAttribute но се съдържа в устройство дължи с EdmSchemaAttribute. Poco лица, които не използват EdmEntityTypeAttribute не могат да се съдържат в един и същ комплект като не-Poco лица, които използват EdmEntityTypeAttribute.
Към Анонимен:
> И как да се кодират първа употреба съхранени процедури?
Процедура за миграция не изглежда да осигури.
За да @Alex Fatkin:
Проектът edmx-файлове? Код първо не се сприятеляват с тях.