Kód első migrálása meglévő adatbázissal

Megjegyzés:

CSAK EF4.3 – Az ezen az oldalon tárgyalt funkciók, API-k stb. az Entity Framework 4.1-ben jelentek meg. Ha korábbi verziót használ, az információk egy része vagy egésze nem érvényes.

Ez a cikk a Code First Migrations meglévő adatbázissal való használatát ismerteti, amelyet nem az Entity Framework hozott létre.

Megjegyzés:

Ez a cikk feltételezi, hogy tudja, hogyan használhatja a Code First Migrationst az alapforgatókönyvekben. Ha nem, akkor a folytatás előtt el kell olvasnia a Code First Migrationst .

1. lépés: Modell létrehozása

Első lépésként létre kell hoznia egy Code First modellt, amely a meglévő adatbázist célozza. A Code First to a Existing Database témakör részletes útmutatást nyújt ennek módjáról.

Megjegyzés:

Fontos, hogy kövesse a jelen témakör többi lépését, mielőtt bármilyen olyan módosítást végezne a modellen, amely az adatbázisséma módosítását igényelné. Az alábbi lépések megkövetelik, hogy a modell szinkronban legyen az adatbázissémával.

2. lépés: Áttelepítések engedélyezése

A következő lépés az áttelepítések engedélyezése. Ehhez futtassa az Enable-Migrations parancsot a Package Manager-konzolon.

Ez a parancs létrehoz egy mappát a migrálások nevű megoldásban, és egyetlen osztályt helyez el benne konfiguráció néven. A konfigurációs osztályban konfigurálhatja az alkalmazás áttelepítéseit. Erről bővebben a Code First Migrations (Első áttelepítések kód) című témakörben talál további információkat.

3. lépés: Kezdeti migrálás hozzáadása

A migrálások létrehozása és a helyi adatbázisra való alkalmazása után érdemes lehet ezeket a módosításokat más adatbázisokra is alkalmazni. Előfordulhat például, hogy a helyi adatbázis tesztadatbázis, és végső soron egy éles adatbázisra és/vagy más fejlesztők tesztadatbázisára is alkalmazni szeretné a módosításokat. Ehhez a lépéshez két lehetőség közül választhat, és attól függ, hogy bármely más adatbázis sémája üres-e, vagy jelenleg megfelel-e a helyi adatbázis sémájának.

• Első lehetőség: A meglévő séma használata kiindulási pontként. Ezt a módszert akkor érdemes használni, ha a jövőben más, migrálásra alkalmazott adatbázisok sémája megegyezik a helyi adatbázis jelenlegi sémáival. Ezt például akkor használhatja, ha a helyi tesztadatbázis jelenleg megfelel az éles adatbázis 1. verziójának, és ezeket az áttelepítéseket később alkalmazza az éles adatbázis 2-s verzióra való frissítéséhez.
• Második lehetőség: Üres adatbázis használata kiindulási pontként. Ezt a módszert akkor érdemes használni, ha más adatbázisok, amelyekre a jövőben migrálás lesz alkalmazva, üresek (vagy még nem léteznek). Ezt használhatja például, ha tesztadatbázis használatával, de migrálás nélkül kezdte el fejleszteni az alkalmazást, és később létre szeretne hozni egy éles adatbázist az alapoktól.

Első lehetőség: Meglévő séma használata kiindulási pontként

A Code First Migrations a legújabb migrálásban tárolt modell pillanatképét használja a modell módosításainak észleléséhez (erről részletes információt a Csapatkörnyezetekben található Első kódmigrálások című témakörben talál). Mivel feltételezzük, hogy az adatbázisok már rendelkeznek az aktuális modell sémával, létrehozunk egy üres (no-op) migrálást, amely az aktuális modellt pillanatképként használja.

1. Hajtsa végre a Add-Migration InitialCreate –IgnoreChanges parancsot a Package Manager konzolban. Ez létrehoz egy üres migrálást, ahol az aktuális modell szolgál pillanatképként.
2. Futtassa az Update-Database parancsot a Package Manager konzolon. Az InitialCreate migrálását a rendszer alkalmazza az adatbázisra. Mivel a tényleges migrálás nem tartalmaz módosításokat, egyszerűen hozzáad egy sort a __MigrationsHistory táblához, amely jelzi, hogy az áttelepítés már megtörtént.

Második lehetőség: Üres adatbázis használata kiindulási pontként

Ebben a forgatókönyvben a migrálásoknak az alapoktól kell létrehozniuk a teljes adatbázist , beleértve a helyi adatbázisunkban már meglévő táblákat is. Létrehozunk egy InitialCreate-migrálást, amely logikát tartalmaz a meglévő séma létrehozásához. Ezután a meglévő adatbázist úgy fogjuk kinézni, mintha ez a migrálás már alkalmazva lett volna.

1. Futtassa a Add-Migration InitialCreate parancsot a Package Manager-konzolon. Ez létrehoz egy migrálást a meglévő séma létrehozásához.
2. Megjegyzést fűzhet az újonnan létrehozott migrálás Up metódusában szereplő összes kódhoz. Ez lehetővé teszi, hogy "alkalmazzuk" a helyi adatbázisra való migrálást anélkül, hogy megpróbálnánk újra létrehozni a már létező táblákat stb.
3. Futtassa az Update-Database parancsot a Package Manager konzolon. Az InitialCreate migrációt ez alkalmazza az adatbázisra. Mivel a tényleges migrálás nem tartalmaz módosításokat (mivel ideiglenesen megjegyzést fűztünk hozzájuk), egyszerűen hozzáad egy sort a __MigrationsHistory táblához, amely azt jelzi, hogy az áttelepítés már megtörtént.
4. Törölje a megjegyzést a Fel metódusban. Ez azt jelenti, hogy ha ezt az áttelepítést a jövőbeli adatbázisokra alkalmazza, a helyi adatbázisban már meglévő sémát migrálások hozzák létre.

A fontos tudnivalók

A migrálások meglévő adatbázissal való használatakor tisztában kell lennie néhány dologtal.

Előfordulhat, hogy az alapértelmezett/számított nevek nem egyeznek a meglévő sémával

A migrációk explicit módon megszabják az oszlopok és táblák nevét, amikor egy migrációt generálnak. Vannak azonban más adatbázis-objektumok is, amelyek esetében a migráció alapértelmezett nevet számít ki azok alkalmazásakor. Ide tartoznak az indexek és a külső kulcsok korlátozásai. Meglévő séma megcélzásakor előfordulhat, hogy ezek a számított nevek nem egyeznek az adatbázisban ténylegesen létező névvel.

Íme néhány példa arra, hogy mikor kell tisztában lennie ezzel:

Ha a 3. lépésben a "One option: Use existing schema as a starting point" (A meglévő séma használata kiindulási pontként) lehetőséget használta:

• Ha a modell későbbi módosításaihoz módosítani vagy elvetni kell a más néven elnevezett adatbázis-objektumok egyikét, módosítania kell az állványzatú migrálást a megfelelő név megadásához. A Migrations API-k opcionális Név paraméterrel rendelkeznek, amely lehetővé teszi ezt. Előfordulhat például, hogy a meglévő sémában van egy Post tábla, amely egy BlogId idegenkulcs-oszlopot tartalmaz, amely egy IndexFk_BlogId nevű indexet tartalmaz. Alapértelmezés szerint azonban a migrálások elvárják, hogy az index neve IX_BlogId legyen. Ha olyan módosítást végez a modellen, amely az index elhagyásához vezet, módosítania kell a generált DropIndex hívást, hogy megadja az IndexFk_BlogId nevet.

Ha a 3. lépésben a "Második lehetőség: Üres adatbázis használata kiindulási pontként" lehetőséget használta:

• Az első migráció Down metódusának futtatása (vagyis az üres adatbázisra történő visszaállítás) a helyi adatbázison sikertelen lehet, mert a migrációk helytelen nevek használatával megpróbálják elvetni az indexeket és az idegenkulcs-korlátozásokat. Ez csak a helyi adatbázisra lesz hatással, mivel a rendszer a kezdeti migrálás Up metódusával hoz létre más adatbázisokat. Ha a meglévő helyi adatbázist üres állapotra szeretné visszaminősíteni, akkor ezt a legegyszerűbb manuálisan elvégezni az adatbázis elvetésével vagy az összes tábla elvetésével. A kezdeti visszalépés után az összes adatbázis-objektum újra létrejön az alapértelmezett névvel, így ez a probléma nem jelenik meg újra.
• Ha a modell jövőbeni változásaihoz módosítani vagy elvetni kell a más néven elnevezett adatbázis-objektumok egyikét, ez nem fog működni a meglévő helyi adatbázissal szemben – mivel a nevek nem egyeznek az alapértelmezett értékekkel. Ez azonban az "alapoktól" létrehozott adatbázisok ellen fog működni, mivel a migrálások által választott alapértelmezett neveket fogják használni. Ezeket a módosításokat elvégezheti manuálisan a meglévő helyi adatbázisán, vagy megfontolhatja, hogy a Migrációk az adatbázist újraalkossa az alapoktól - ahogyan más gépeken is történne.
• A kezdeti migrálás Up metódusával létrehozott adatbázisok kissé eltérhetnek a helyi adatbázistól, mivel az indexek és az idegenkulcs-korlátozások számított alapértelmezett nevei lesznek használatban. A végén további indexek is előfordulhatnak, mivel a migrálások alapértelmezés szerint indexeket hoznak létre az idegen kulcsoszlopokon – lehet, hogy ez nem történt meg az eredeti helyi adatbázisban.

Nem minden adatbázis-objektum jelenik meg a modellben

A migrálások nem kezelik a modell részét nem képező adatbázis-objektumokat. Ilyenek lehetnek a nézetek, a tárolt eljárások, az engedélyek, a modell részét nem képező táblák, további indexek stb.

Íme néhány példa arra, hogy mikor kell tisztában lennie ezzel:

• A 3. lépésben választott beállítástól függetlenül, ha a modell későbbi módosításaihoz módosítani vagy elvetni kell ezeket a további objektumokat, az áttelepítések nem fogják tudni, hogy végrehajtják-e ezeket a módosításokat. Ha például elvet egy olyan oszlopot, amelyen egy további index található, az áttelepítések nem fogják tudni, hogy elvetik az indexet. Önnek manuálisan kell hozzáadnia ezt a sablon szerinti migrációhoz.
• Ha a "Második lehetőség: Üres adatbázis használata kiindulási pontként" lehetőséget használta, ezek a további objektumok nem jönnek létre a kezdeti migrálás Up metódusával. Igény szerint módosíthatja a Fel és a Le metódust, hogy gondoskodjon ezekről a további objektumokról. A Migrations API-ban natív módon nem támogatott objektumok – például nézetek – esetén az SQL-metódussal nyers SQL-t futtathat a létrehozásukhoz/elvetésükhöz.