Koda första migreringar med en befintlig databas

Anmärkning

ENDAST EF4.3 – De funktioner, API:er osv. som beskrivs på den här sidan introducerades i Entity Framework 4.1. Om du använder en tidigare version gäller inte en del av eller all information.

Den här artikeln beskriver hur du använder Code First Migrations med en befintlig databas, en som inte har skapats av Entity Framework.

Anmärkning

Den här artikeln förutsätter att du vet hur du använder Code First Migrations i grundläggande scenarier. Om du inte gör det måste du läsa Code First Migrations innan du fortsätter.

Steg 1: Skapa en modell

Ditt första steg är att skapa en Code First-modell som riktar sig mot din befintliga databas. Avsnittet Koda först till en befintlig databas innehåller detaljerad vägledning om hur du gör detta.

Anmärkning

Det är viktigt att du följer resten av stegen i det här avsnittet innan du gör några ändringar i din modell som skulle kräva ändringar i databasschemat. Följande steg kräver att modellen är synkroniserad med databasschemat.

Steg 2: Aktivera migreringar

Nästa steg är att aktivera migreringar. Du kan göra detta genom att köra kommandot Enable-Migrations i Package Manager Console.

Det här kommandot skapar en mapp i din lösning med namnet Migreringar och placerar en enda klass i den med namnet Konfiguration. I klassen Configuration (Konfiguration) konfigurerar du migreringar för ditt program. Mer information finns i avsnittet Kod första migreringar .

Steg 3: Lägg till en inledande migrering

När migreringar har skapats och tillämpats på den lokala databasen kanske du också vill tillämpa dessa ändringar på andra databaser. Din lokala databas kan till exempel vara en testdatabas och du kanske vill tillämpa ändringarna på en produktionsdatabas och/eller andra utvecklares testdatabaser. Det finns två alternativ för det här steget och det du bör välja beror på om schemat för andra databaser är tomt eller för närvarande matchar schemat för den lokala databasen.

• Alternativ ett: Använd befintligt schema som startpunkt. Du bör använda den här metoden när andra databaser som migreringar kommer att tillämpas på i framtiden har samma schema som din lokala databas har för närvarande. Du kan till exempel använda detta om din lokala testdatabas för närvarande matchar v1 i produktionsdatabasen och du senare använder migreringarna för att uppdatera produktionsdatabasen till v2.
• Alternativ två: Använd tom databas som startpunkt. Du bör använda den här metoden när andra databaser som migreringar kommer att tillämpas på i framtiden är tomma (eller inte finns ännu). Du kan till exempel använda detta om du började utveckla ditt program med hjälp av en testdatabas, men utan att använda migreringar och du senare vill skapa en produktionsdatabas från grunden.

Alternativ ett: Använd befintligt schema som utgångspunkt

Code First Migrations använder en ögonblicksbild av modellen som lagrats i den senaste migreringen för att identifiera ändringar i modellen (du hittar detaljerad information om detta i Code First Migrations in Team Environments). Eftersom vi kommer att anta att databaser redan har schemat för den aktuella modellen genererar vi en tom (no-op) migrering som har den aktuella modellen som en ögonblicksbild.

1. Kör kommandot Add-Migration InitialCreate – IgnoreChanges i Package Manager Console. Detta skapar en tom migrering med den aktuella modellen som en ögonblicksbild.
2. Kör kommandot Update-Database i Package Manager Console. Detta tillämpar migreringen InitialCreate på databasen. Eftersom den faktiska migreringen inte innehåller några ändringar, lägger den helt enkelt till en rad i tabellen __MigrationsHistory som anger att den här migreringen redan har tillämpats.

Alternativ två: Använd tom databas som utgångspunkt

I det här scenariot behöver vi migreringar för att kunna skapa hela databasen från grunden – inklusive tabellerna som redan finns i vår lokala databas. Vi ska generera en InitialCreate-migrering som innehåller logik för att skapa det befintliga schemat. Sedan får vi vår befintliga databas att se ut som om den här migreringen redan har tillämpats.

1. Kör kommandot Add-Migration InitialCreate i Package Manager Console. Detta skapar en migrering för att skapa det befintliga schemat.
2. Kommentera ut all kod i up-metoden för den nyligen skapade migreringen. På så sätt kan vi "tillämpa" migreringen på den lokala databasen utan att försöka återskapa alla tabeller osv. som redan finns.
3. Kör kommandot Update-Database i Package Manager Console. Detta tillämpar migreringen InitialCreate på databasen. Eftersom den faktiska migreringen inte innehåller några ändringar (eftersom vi tillfälligt kommenterade ut dem) lägger den helt enkelt till en rad i tabellen __MigrationsHistory som anger att den här migreringen redan har tillämpats.
4. Ta bort kommentaren till koden i up-metoden. Det innebär att när den här migreringen tillämpas på framtida databaser skapas schemat som redan fanns i den lokala databasen av migreringar.

Saker att vara medveten om

Det finns några saker du måste vara medveten om när du använder migreringar mot en befintlig databas.

Standard-/beräknade namn kanske inte matchar befintligt schema

Migreringar specificerar uttryckligen namn för kolumner och tabeller när de skapar en migrering. Det finns dock andra databasobjekt som migreringar beräknar ett standardnamn för när migreringarna tillämpas. Detta inkluderar index och begränsningar för referensnyckel. När du riktar in dig på ett befintligt schema kanske dessa beräknade namn inte matchar det som faktiskt finns i databasen.

Här är några exempel på när du behöver vara medveten om detta:

Om du använde Alternativ ett: Använd befintligt schema som utgångspunkt från steg 3:

• Om framtida ändringar i din modell kräver att du ändrar eller tar bort ett av databasobjekten som har ett annat namn, måste du modifiera den skapade migreringen för att ange rätt namn. API:erna för migreringar har en valfri namnparameter som gör att du kan göra detta. Ditt befintliga schema kan till exempel ha en Post-tabell med en sekundärnyckelkolumn för BlogId som har ett index med namnet IndexFk_BlogId. Som standard förväntar sig dock migreringar att det här indexet namnges IX_BlogId. Om du gör en ändring i din modell som resulterar i att det här indexet tas bort måste du ändra DropIndex-anropet för att specificera namnet IndexFk_BlogId.

Om du använde Alternativ två: Använd tom databas som utgångspunkt från steg 3:

• Om du försöker köra Ned-metoden för den inledande migreringen (dvs. återgå till en tom databas) mot din lokala databas kan det misslyckas eftersom migreringarna kan försöka släppa index och begränsningar för främmande nyckel med hjälp av felaktiga namn. Detta påverkar bara din lokala databas eftersom andra databaser skapas från grunden med hjälp av up-metoden för den första migreringen. Om du vill nedgradera din befintliga lokala databas till ett tomt tillstånd är det enklast att göra detta manuellt, antingen genom att ta bort databasen eller ta bort alla tabeller. Efter den här inledande nedgraderingen återskapas alla databasobjekt med standardnamnen, så det här problemet visas inte igen.
• Om framtida ändringar i din modell kräver att ett av databasobjekten som namnges annorlunda ändras eller tas bort, fungerar detta inte mot din befintliga lokala databas – eftersom namnen inte matchar standardvärdena. Det fungerar dock mot databaser som har skapats "från grunden" eftersom de har använt de standardnamn som valts av migreringar. Du kan antingen göra dessa ändringar manuellt i din lokala befintliga databas eller överväga att låta migreringar återskapa databasen från grunden – precis som på andra datorer.
• Databaser som skapats med up-metoden för den första migreringen kan skilja sig något från den lokala databasen eftersom de beräknade standardnamnen för index och begränsningar för sekundärnyckel används. Du kan också få extra index eftersom migreringar skapar index på sekundärnyckelkolumner som standard – detta kanske inte har varit fallet i den ursprungliga lokala databasen.

Alla databasobjekt representeras inte i modellen

Databasobjekt som inte ingår i din modell hanteras inte av migreringar. Detta kan omfatta vyer, lagrade procedurer, behörigheter, tabeller som inte ingår i din modell, ytterligare index osv.

Här är några exempel på när du behöver vara medveten om detta:

• Oavsett vilket alternativ du valde i Steg 3, om framtida ändringar i din modell kräver att du ändrar eller tar bort dessa ytterligare objekt kommer migreringar inte att kunna göra dessa ändringar. Om du till exempel släpper en kolumn som har ytterligare ett index på sig kommer migreringen inte att veta att den måste släppa indexet. Du måste lägga till detta manuellt i den autogenererade migreringen.
• Om du använde Alternativ två: Använd tom databas som startpunkt skapas inte dessa ytterligare objekt med up-metoden för den första migreringen. Du kan ändra upp- och ned-metoderna för att ta hand om dessa ytterligare objekt om du vill. För objekt som inte stöds internt i MIGrerings-API:et – till exempel vyer – kan du använda Sql-metoden för att köra rå SQL för att skapa/släppa dem.