Cu privire la dezvoltarea și eficiența cadrului de cod prima entitate migrări 4
În fotografie migrația fluture monarh (CC BY-NC-ND 2.0, originalzdes).
În acest articol, din punctul meu de vedere, desigur, răspunde la întrebări, susținute de exemple:
- Ce este migrația și ce sunt?
- Ceea ce este interesant în această versiune și în Codul EF Prima migrații în general?
Cred că, aproape nimeni nu folosește migrația în dezvoltarea comercială de zi cu zi. Așa că nu va aloca în mod explicit o listă de caracteristici noi și doar va vorbi despre migrație, evidențiind separat în noul EF 4.3 Beta 1.
Apropo, poate că va fi interesat, că eliberarea de FE 4.3 este planificată pentru primul trimestru al acestui an. Păcat numai este că eliberarea de FE 5.0 cu suport pentru enum și de a optimiza viteza de fiecare dintre noi așteaptă în curând - cu lansarea .NET 4.5 va numai EF 5.0 Beta 1.
Scurtă descriere a migrațiilor
Migrația EF concepute pentru a aborda modificări ale structurii bazei de date în evoluția cererii. O soluție la această problemă, am exprimat mai devreme în articolul „Principiile SQL - DDL și baza de date refactoring“. Sper că atunci când el este gata EF primul cod Migrații, el va fi mult mai bine decât abordarea cu script-uri.
Notă importantă: principalul lucru pe care doriți să urmăriți atunci când migrarea bazelor de date, în general, în plus față de respectarea structurii - siguranței datelor clientului.
Este puțin probabil că doriți după ce instalați noua versiune a clientului (sau mai rău - clienți) să știe că sistemul automat de migrare a eliminat o parte din date, iar clientul se gândește în detrimentul cuiva pentru a compensa pierderea de banii lor ...
În continuare, voi oferi un exemplu tipic de a lucra cu migrații, dar mai întâi să configurăm totul.
Cum se instalează?
În primul rând permiteți-mi să spun că este Beta, cu toate riscurile inerente. În al doilea rând, primul cod migrații sunt acum incluse în FE și nu trebuie să fie instalat separat.
Cu siguranță știți că instalarea NuGet-pachete cel mai ușor de făcut în Managerul Console Package (denumit în continuare PM), așa că va lua în considerare numai această metodă. Etapele de montaj de acțiuni este după cum urmează:
- În cazul în care pachetul este „primul cod migrații Beta 1“ a fost stabilit:
Pentru a accelera scrierea unui exemplu, am folosi modelul de schele. De aceea, voi adăuga unul mai multe opționale, în cazul general, etapa:
Exemple de lucru cu migrații
Cei care au lucrat cu migrații se poate trece la secțiunea următoare.
Ești încă aici. ) Atunci să ia în considerare un exemplu simplu - adăugați un model, apoi se adauga la noua proprietate, și apoi scoateți-l. Datele cu noile mecanisme integrate vor migra.
Configurarea conexiunii bazei de date
Voi folosi SQL Server Express. ca opțiune, propusă în mod implicit. Pentru conectarea rapidă a DbContext noastre în web.config copia un șir de conexiune existentă (ApplicationServices implicit) și adăugați-l cu numele care se potrivește cu numele contextului:
Notă importantă: Fără sintagma „Database = aspnetdb.mdf“, aplicarea și migrația nu va funcționa corect (în mod implicit, această frază nu apare în șirul de conectare).
Crearea primei versiuni a modelului
Acum, pentru a crea un model foarte simplu, vom introduce următoarea comandă:
Dacă ați citit articolul meu despre ModelScaffolding știți deja că acest lucru va crea următorul model (și toate conductele pentru editarea ei într-o aplicație ASP.NET MVC - controler și prezentare):
Să rula aplicația noastră, adăugând la URL-ul „Teste“ (o puteți face imediat pentru a configura un proiect pentru a economisi timp în viitor) și să introducă un pic de date.
Vreau să atrag atenția asupra faptului că nu conectat în mod conștient migrarea pentru a verifica modul în care acestea ar lucra într-o situație în care datele sunt deja acolo, și migrația nu au fost încă conectate.
Privind în perspectivă să spun că, în ciuda unui avertisment de pe blog-ul echipei ADO.NET de mai jos, cu bug-uri, nu am avut o șansă de a întâlni, se pare că a fost starea de spirit prea pozitiv :)
NOTĂ: Există o serie de bug-uri în funcționalitatea de scripting în EF 4.3 Beta 1, care vă împiedică generarea unui script pornind de la o alta decât o bază de date goală de migrare. Aceste bug-uri vor fi stabilite în RTM finală.
Schimbarea modelului și prima migrare
Pentru a activa migrația este acum (începând cu versiunea 4.3 EF), puteți rula pur și simplu următoarea comandă:
Aceasta se adaugă la directorul proiectului „Migratii“ și fișierul „Configuration.cs“. Dacă sunteți de acord cu comportamentul implicit, trebuie să deconectați migrarea automată, nu are nimic de-a face mai. În cazul în care DbContext-uri va fi o mulțime de necesitatea de a adăuga un pic de fișier manual.
Dacă vom compila aplicația și deschideți-l în sus, obținem următoarea eroare fără echivoc:
Modelul sprijină contextul „MvcEfDemoContext“ sa schimbat de când a fost creată baza de date. Luați în considerare utilizarea primul cod Migrații pentru a actualiza baza de date.
Totul este logic - modelul s-a schimbat, baza - nr. Să migreze. Rulați comanda pentru a adăuga o migrare:
Ca un parametru a trecut la numele de migrare (numele fișierului va fi adăugat la stânga ora curentă). Sunteți liberi să alegeți o schemă de denumire. De exemplu, dacă doriți numerotare continuă - apel migrația în formatul „00000“. Personal, prefer varianta cu un nume semnificativ, deoarece ordinea deja dată de ora curentă.
După finalizarea cu succes a acestei comenzi, vom obține o clasă pentru migrație, care conține două metode:
După cum puteți vedea, migrația sprijină generarea automată și aplicarea, și se rostogolesc înapoi modificările care funcționează, cel puțin pentru cazurile simple.
Acum, avem mai multe opțiuni pentru a rula migrației:
- Aplicați modificările direct la baza de date - cea mai rapidă și cea mai simplă opțiune (pentru ieșire pentru a rula comenzi, puteți adăuga opțiunea Detaliat, disponibil incepand cu versiunea 4.3 EF):
Din nou, vă decide modul în care procesul de migrare va fi construit. De exemplu, la început puteți genera mai întâi un scenariu și de a face recenzia lui. Apoi, dacă totul este în ordine, puteți pur și simplu actualiza baza de date. Bineînțeles, aș recomanda să testați temeinic toate migrația nouă, împreună cu restul codului înainte de eliberare clienților.
În cazul nostru, prima migrare va adăuga un e-mail coloană:
În plus, vor fi create tabelele de servicii pentru stocarea de informații despre migrarea bazei de date.
Dacă executați comanda update-Database, si sa terminat cu o eroare „Can bază de date nu este deschis ... solicitate de conectare.“ Sau „Nu se poate crea fișierul«...»pentru că există deja.“, Asigurați-vă că șirul de conexiune specificat „Database = aspnetdb. MDF „și studioul nu este conexiune deschisă la baza de date.
Definitivarea
Am intenționat lăsat lungimea nu este specificată de e-mail, astfel încât acum putem uita la modul în care are loc migrația atunci când modificați proprietățile atributului. StringLength adăugarea unui atribut la proprietate, din nou, adăugând să migreze și să rulați-l:
Odată cu migrarea clasei va primi bine, conține următoarele metode:
Dar, după începerea migrației vom obține o eroare de genul:
Obiectul „DF__Tests__Email__014935CB“ este dependentă de coloana „E-mail“. ALTER TABLE ALTER COLOANA E-mail a eșuat, deoarece unul sau mai multe obiecte de acces la această coloană.
Aici am o cerere la realizarea migrației, mai degrabă decât faptul că schimbarea în coloana „nu pe complet automate“, și că, la crearea unei coloane nu este numit DEFAULT CONSTRAINT „DF_Tests_Email“. Din acest motiv, în această etapă va trebui să migreze podkovyrivat un pic mai mult decât ar trebui. Sa dovedit:
După cum puteți vedea, nimic extraordinar, dar pe actualul DEFAULT-ar putea vedea ah cadru Entitate - cel puțin pentru a încerca să-l recreeze în același mod, după schimbarea coloanei - în cazul în care nu sa întâmplat, atunci dopilivat mâini.
Rulare înapoi migrația
Acum (de la versiunea 4.3 EF. Deși poate că a fost în versiunea beta anterioară, pe care nu l-am văzut), puteți anula migrația. Puteți face acest lucru folosind „TargetMigration“, care, trebuie spus, de asemenea, funcționează în trecut și în viitor (atunci când doriți să se aplice migrarea bazei de date nu este nou).
Problemele au apărut atunci când rollback nu este (pentru că metoda este „jos“, am corectat cele de mai sus, împreună cu metoda „Up“).
Eliminarea coloană
Pentru a elimina o coloană, puteți pur și simplu re-crea modelul în forma sa originală (nu la dreptul de reprezentare) și se repetă procesul de migrare de creare și de aplicare:
Dacă nu se execută „Update-Database“ rollback după migrare, nu puteți adăuga unul nou, ceea ce va fi notificat ca o eroare:
Această problemă este corectată fără a executa „Update-Database“, adevarul va fi un avertisment, ca urmare a acesteia:
Nu se pot aplica modificări în așteptare din cauza migrației automată este dezactivată. Pentru a activa migrarea automată, asigurați-vă că DbMigrationsConfiguration.AutomaticMigrationsEnabled este setat la true.
migrarea automată în acest caz cuprind o repetare suficient de comandă, opțional, pentru a adăuga migrarea, și apoi actualizarea bazei de date.
Adăugarea unui model de legat
Pentru a vedea modul în care funcționează migrația cu modele similare a le crea:
După adăugarea de migrare va arăta astfel:
Rețineți că mecanismul de migrare are grijă de noi, crearea indecșilor pe coloane implicate într-o cheie externă. Cred că e mai bine decât rău, mai ales că puteți pur și simplu eliminați indexul în această etapă.
Când actualizați baza de date, în acest caz, se va da o eroare, deoarece coloana „categoryID“ va încerca să umple o valoare de 0, și o valoare în tabelul „categoria“ de la sine nu apare.
Cred că acum știi suficient pentru a face față cu soluția la această problemă pe cont propriu. Voi da doar un pont că, atunci când ajustarea migrării este disponibil nu numai de executare SQL direct, dar setările din codul. De exemplu, metoda „ColumnBuilder.Int“ poate trece în plus un parametru „defaultValue“.
migrația automatizată
Voi spune un pic despre migrarea automată deja menționată. Este posibil să se utilizeze modul atunci când nu este necesar să se adauge în mod explicit migrația folosind comanda „Add-Migration“. Acest mod este inclus în clasa „Configurare“ cu proprietatea „AutomaticMigrationsEnabled“.
Bine sau rău - depinde de prea mulți factori. Nu pot adăuga doar că nimeni nu deranjează să adăugați automat migrația în mod explicit, atunci când este necesar.
În plus față de modul automat, este posibil pentru a rula migrarea de migrare la începutul aplicației cu ajutorul bazei de date initializare MigrateDatabaseToLatestVersion (disponibil din versiunea 4.3 EF).
Ce a mai rămas în spatele scenei
Deci, ca să nu se umfla articol, nu am arată variații mai complexe (modificări în tabelele aferente, etc.). Desigur, ceva care funcționează în mod automat, ceva trebuie să dopilivat.
De asemenea, nu acorde atenție la următoarele inovații în EF 4.3:
- Adaugata documentație suficient de detaliate pentru clasele XML-migrare.
- tabele de excepție „EdmMetadata“ - Acum, când creați o bază de date în stilul de cod În primul rând, fără a migrației, migrația este încă folosit în modul automat :)
- Câteva remedieri de erori (GetDatabaseValues și suport Unicode DbSet).
- Codul În primul rând înțelege acum adnotări pentru proprietățile închise.
- Adăugat de configurare suport în config-fișier.
Engleză Click aici pentru detalii.
Până în prezent, ceea ce văd în FE 4.3 în ceea ce privește migrația îmi place, cu excepția unor neajunsuri. Desigur, încercați migrația într-adevăr numai în utilizarea în dezvoltarea comercială. Voi aștepta :)
Și de ce s-a decis că în cazul în care terenul poate să fie nulă, este necesar să stea implicit konstreyt cu numele generat și o valoare goală? Ar fi mai bine dacă ar încerca să EF ca ORM cumva mai aproape de NH :(
În opinia mea, acestea sunt situațiile din cauza cărora orice avtomigratsii sortite eșecului - scrie date de migrare schemă pot și io întinse acțiuni simple - adăuga / elimina coloana / tabel / konstreynt. Dar migrarea datelor este aproape imposibil de a automatiza. Cu toate acestea, adăugarea unui e-mail - dacă vom specifica că câmpul trebuie să aibă o valoare, un șir gol - o cârjă, nu valoarea.
Eu folosesc Migrator.Net - rezolvă toate problemele de infrastructură, iar dezvoltatorul este cel mai curent migrarea codului.
Pentru @Vasiliy Shiryaev:
Și ce ai obligat să se întâmple, având în vedere faptul că există date în tabel? Apropo, nimeni nu deranjează să corecteze codul de migrare înainte de utilizare.
Astfel de lucruri simple, cum ar specifica un alt implicite sunt scrise direct în codul, în cazul redistribuire a datelor poate rula metoda Sql (de exemplu, în articol este).
Prin urmare, nu este clar ce Migrator.Net avantaj - care nu oferă soluții pentru cazuri simple? ;)
Ce ar fi întâmplat? Depinde de situație. Nu este de natură să solicite nu nul general pentru agățat o linie goală în loc de implicit câmpurile nule sunt mai mult decât suficient, IMHO.
A doua întrebare pe care ei înșiși au exprimat cu privire la numele konstreynta, și a adăugat la această carja.
Da, Migratora.Net avantaj este că nu oferă soluții curbe pentru cazuri simple, pentru care este necesar să se urmeze și apoi verificați :)
Pentru @Vasiliy Shiryaev
> Pentru agățat linie goală în loc de implicit câmpurile nule sunt mai mult decât suficient, IMHO.
Acum am știut ce am avut de sincronizare :)
Pentru proprietăți cu un atribut * Obligatoriu * - nu este suficient.
Și, în opinia mea, este încă ciudat - * Obligatoriu * înseamnă că domeniul este necesară pentru a face o diferenta. O valoare gol - este într-un fel ciudat, în contextul * * Obligatoriu, dar acceptabil - dacă nu aveți mai multe opțiuni pentru datele actuale. Și aici este implicit pentru noile date konstreynt exact o dată.
Aici Migrator a trebuit să facă ceva:
- a crea un câmp nul
- setați toate liniile la valoarea implicită
- actualizarea câmpului pentru a nu nul.
Pentru @Vasiliy Shiryaev:
> Aici Migrator a trebuit să facă ceva.
Acest lucru, spun ei, gustul și culoarea.
Am fost în abordarea la crearea de constrângere implicit supărat pe faptul că el nu a fost dat un nume normal.
Vă reamintesc că, dacă se dorește, în migrația poate fi ușor setat implicit fără utilizarea SQL-cod.
În ceea ce privește migrator, în general, - cred că beneficiu sau rău din utilizarea depinde de obiectivele și echipa. Cineva va fi mai util cuiva rău.
Cum să cod procedurile memorate de prima utilizare?
Bună ziua. Se pare că în descrierea unui exemplu care omite detaliile necesare.
Contextul creat nu conține context.Test, care generează un vrăjitor. Când corectarea pe context.Tests, nu funcționează de mai jos controler prvedenny
TestController public class. controlor
Contextul MyMvc3Context privat = new MyMvc3Context ();
Indicele ViewResult publice ()
reveni View (context.Tests.ToList ());
Generiruettsya eroare: „test“ Tipul nu este atribuit cu EdmEntityTypeAttribute, dar este conținută într-un ansamblu atribuit cu EdmSchemaAttribute. Entitățile Poco care nu utilizează EdmEntityTypeAttribute nu pot fi conținute în același ansamblu ca entități non-Poco care utilizează EdmEntityTypeAttribute.
Pentru Anonim:
> Și cum să cod procedurile memorate de prima utilizare?
Procedura de migrare nu pare să ofere.
Pentru @Alex Fatkin:
Proiectul a fișierelor edmx-? Primul cod nu face prieteni cu ei.