Sdílet prostřednictvím

Migrace Code First s existující databází

  • Článek

Poznámka

EF4.3 Pouze – funkce, rozhraní API atd. probírané na této stránce byly představeny v Entity Frameworku 4.1. Pokud používáte starší verzi, některé nebo všechny informace nemusí být platné.

Tento článek popisuje použití Migrace Code First s existující databází, která nebyla vytvořena rozhraním Entity Framework.

Poznámka

Tento článek předpokládá, že víte, jak používat Migrace Code First v základních scénářích. Pokud ne, budete si muset před pokračováním přečíst Migrace Code First.

Krok 1: Vytvoření modelu

Vaším prvním krokem bude vytvoření modelu Code First, který cílí na vaši stávající databázi. Téma Code First pro existující databázi obsahuje podrobné pokyny k tomuto postupu.

Poznámka

Před provedením jakýchkoli změn modelu, které by vyžadovaly změny schématu databáze, je důležité postupovat podle zbývajících kroků v tomto tématu. Následující kroky vyžadují, aby byl model synchronizovaný se schématem databáze.

Krok 2: Povolení migrací

Dalším krokem je povolení migrací. Můžete to provést spuštěním příkazu Enable-Migrations v konzole Správce balíčků.

Tento příkaz vytvoří ve vašem řešení složku s názvem Migrace a vloží do ní jednu třídu s názvem Konfigurace. Třída Konfigurace je místo, kde konfigurujete migrace pro vaši aplikaci. Další informace o ní najdete v tématu Migrace Code First.

Krok 3: Přidání počáteční migrace

Po vytvoření a použití migrací na místní databázi můžete chtít tyto změny použít i v jiných databázích. Místní databáze může být například testovací databáze a v konečném důsledku můžete chtít také použít změny v produkční databázi nebo jiných vývojářích testovacích databází. Existují dvě možnosti pro tento krok a ta, kterou byste měli vybrat, závisí na tom, jestli je schéma jiných databází prázdné nebo aktuálně odpovídá schématu místní databáze.

  • Možnost Jedna: Jako výchozí bod použijte existující schéma. Tento přístup byste měli použít v případě, že ostatní databáze, na které budou migrace použity v budoucnu, budou mít stejné schéma jako vaše místní databáze. Tuto možnost můžete použít například v případě, že vaše místní testovací databáze aktuálně odpovídá verzi 1 produkční databáze a později tyto migrace použijete k aktualizaci produkční databáze na verzi 2.
  • Možnost 2: Jako výchozí bod použijte prázdnou databázi. Tento přístup byste měli použít v případě, že ostatní databáze, na které budou migrace použity v budoucnu, jsou prázdné (nebo ještě neexistují). Můžete to použít například v případě, že jste začali vyvíjet aplikaci pomocí testovací databáze, ale bez migrace a později budete chtít vytvořit produkční databázi úplně od začátku.

Možnost Jedna: Použití existujícího schématu jako výchozího bodu

Migrace Code First pomocí snímku modelu uloženého v nejnovější migraci zjistí změny modelu (podrobné informace o tom najdete v Migrace Code First v týmových prostředích). Vzhledem k tomu, že předpokládáme, že databáze už mají schéma aktuálního modelu, vygenerujeme prázdnou migraci (no-op), která má aktuální model jako snímek.

  1. V konzole Správce balíčků spusťte příkaz Add-Migration InitialCreate –IgnoreChanges. Tím se vytvoří prázdná migrace s aktuálním modelem jako snímkem.
  2. Spusťte příkaz Update-Database v konzole Správce balíčků. Tím se na databázi použije migrace InitialCreate. Vzhledem k tomu, že skutečná migrace neobsahuje žádné změny, jednoduše přidá řádek do tabulky __MigrationsHistory označující, že tato migrace už byla použita.

Možnost 2: Použití prázdné databáze jako výchozího bodu

V tomto scénáři potřebujeme, aby migrace dokázaly vytvořit celou databázi úplně od začátku – včetně tabulek, které už existují v naší místní databázi. Vygenerujeme migraci InitialCreate, která zahrnuje logiku pro vytvoření existujícího schématu. Pak nastavíme, aby naše stávající databáze vypadala, jako by tato migrace už byla použita.

  1. V konzole Správce balíčků spusťte příkaz Add-Migration InitialCreate. Tím se vytvoří migrace pro vytvoření existujícího schématu.
  2. Zakomentujte veškerý kód v metodě Up nově vytvořené migrace. To nám umožní "použít" migraci na místní databázi, aniž byste se pokusili znovu vytvořit všechny tabulky atd., které už existují.
  3. Spusťte příkaz Update-Database v konzole Správce balíčků. Tím se na databázi použije migrace InitialCreate. Vzhledem k tomu, že skutečná migrace neobsahuje žádné změny (protože jsme je dočasně okomentovali), jednoduše přidá řádek do tabulky __MigrationsHistory označující, že tato migrace už byla použita.
  4. Zrušte komentář kódu v metodě Up. To znamená, že když se tato migrace použije u budoucích databází, vytvoří se migracemi schéma, které již v místní databázi existovalo.

Co je potřeba vědět

Při použití migrací do existující databáze je potřeba mít na paměti několik věcí.

Výchozí nebo počítané názvy nemusí odpovídat existujícímu schématu

Migrace explicitně určují názvy sloupců a tabulek při generování migrace. Existují však i jiné databázové objekty, pro které migrace při použití migrací vypočítá výchozí název. To zahrnuje omezení indexů a cizích klíčů. Při cílení na existující schéma nemusí tyto počítané názvy odpovídat tomu, co ve skutečnosti v databázi existuje.

Tady je několik příkladů, kdy potřebujete vědět o těchto případech:

Pokud jste použili možnost Jedna: Použijte existující schéma jako výchozí bod z kroku 3:

  • Pokud budoucí změny v modelu vyžadují změnu nebo vyřazení jednoho z databázových objektů, které mají jiný název, budete muset upravit vygenerovanou migraci a zadat správný název. Rozhraní API pro migrace mají volitelný parametr Name, který vám to umožní. Vaše stávající schéma může mít například tabulku Post se sloupcem cizího klíče BlogId, který má index s názvem IndexFk_BlogId. Ve výchozím nastavení by však migrace očekávala, že tento index bude pojmenován IX_BlogId. Pokud v modelu provedete změnu, která způsobí vyřazení tohoto indexu, budete muset upravit volání DropIndex vygenerované vygenerované tak, aby určilo název IndexFk_BlogId.

Pokud jste použili možnost Dvě: Použití prázdné databáze jako výchozího bodu z kroku 3:

  • Pokus o spuštění metody Down počáteční migrace (tj. návrat k prázdné databázi) v místní databázi může selhat, protože migrace se pokusí odstranit indexy a omezení cizího klíče pomocí nesprávných názvů. To bude mít vliv jenom na vaši místní databázi, protože ostatní databáze budou vytvořeny úplně od začátku pomocí metody Up počáteční migrace. Pokud chcete existující místní databázi downgradovat na prázdný stav, je nejjednodušší to provést ručně– buď přetažením databáze, nebo vyřazením všech tabulek. Po tomto počátečním downgradu se všechny databázové objekty znovu vytvoří s výchozími názvy, takže se tento problém znovu nezobrazí.
  • Pokud budoucí změny v modelu vyžadují změnu nebo vyřazení některého z databázových objektů, které jsou pojmenované jinak, nebude to fungovat s existující místní databází , protože názvy nebudou odpovídat výchozím nastavením. Bude ale fungovat s databázemi, které byly vytvořeny úplně od začátku, protože budou používat výchozí názvy vybrané migrací. Tyto změny můžete buď provést ručně v místní existující databázi, nebo zvážit opětovné vytvoření databáze úplně od začátku – stejně jako na jiných počítačích.
  • Databáze vytvořené metodou Up počáteční migrace se mohou mírně lišit od místní databáze, protože se použijí počítané výchozí názvy indexů a omezení cizího klíče. Můžete také skončit s dalšími indexy, protože Migrace ve výchozím nastavení vytvoří indexy ve sloupcích cizích klíčů – v původní místní databázi to pravděpodobně nebylo.

V modelu nejsou reprezentovány všechny databázové objekty.

Migrace nezpracují databázové objekty, které nejsou součástí modelu. Může to zahrnovat zobrazení, uložené procedury, oprávnění, tabulky, které nejsou součástí modelu, další indexy atd.

Tady je několik příkladů, kdy potřebujete vědět o těchto případech:

  • Bez ohledu na možnost, kterou jste zvolili v kroku 3, pokud budoucí změny v modelu vyžadují změnu nebo vyřazení těchto dalších objektů Migrace nebudou vědět, aby tyto změny udělaly. Pokud například zahodíte sloupec s dalším indexem, migrace nebudou vědět, že index zahodí. Tuto možnost budete muset přidat ručně do vygenerované migrace.
  • Pokud jste použili možnost Dvě: Jako výchozí bod použijte prázdnou databázi, nebudou tyto další objekty vytvořeny metodou Up vaší počáteční migrace. Pokud chcete, můžete upravit metody Up a Down, aby se o tyto další objekty postaraly. U objektů, které nejsou nativně podporovány v rozhraní API pro migrace , jako jsou zobrazení, můžete použít metodu Sql ke spuštění nezpracovaného SQL k jejich vytvoření nebo vyřazení.