2014-12-08 7 views
7

Próbuję skonfigurować automatyczne aktualizacje migracji przy użyciu klasy IdentityDbContext i propagowanie zmian w rzeczywistym kontekście DbContext dla całej bazy danych.Entity Framework przy użyciu IdentityDbContext z kodem Najpierw automatyczna lokalizacja i schemat tabeli migracji?

Zanim przejdę do kodu, na mojej realizacji IdentityDbContext z automatycznych migracji otrzymuję ten błąd:

Automatic migrations that affect the location of the migrations history system table (such as default schema changes) are not supported. Please use code-based migrations for operations that affect the location of the migrations history system table.

ja nie zamierzam zakładać modele, które są związane z migracjami i kodu kontekstowego, chyba ktoś znajduje je w użyciu.

implementacja z IdentityDbContext:

public class SecurityContext: IdentityDbContext<User> 
    { 
     public SecurityContext() : base("MyActualContext") 
     { 

     } 

     protected override void OnModelCreating(DbModelBuilder modelBuilder) 
     { 


      base.OnModelCreating(modelBuilder); 

      //removing this line I do not get an error, but everything gets placed into the dbo schema. Keeping this line, i get the above error. 
      modelBuilder.HasDefaultSchema("ft"); 
     } 
    } 

Spróbowałem więc dodanie tej klasy umieszczenia historii migracje do odpowiedniego schematu. To faktycznie przenosi historię migracji do poprawnego schematu, ale wszystko inne pozostaje w schemacie dbo.

public class MyHistoryContext : HistoryContext 
    { 
     public MyHistoryContext(DbConnection dbConnection, string defaultSchema) 
      : base(dbConnection, defaultSchema) 
     { 
     } 

     protected override void OnModelCreating(DbModelBuilder modelBuilder) 
     { 
      base.OnModelCreating(modelBuilder); 
      modelBuilder.HasDefaultSchema("ft"); 
     } 
    } 

public class SecurityContextMigrations : DbMigrationsConfiguration<SecurityContext> 
    { 
     public SecurityContextMigrations() 
     { 
      AutomaticMigrationsEnabled = true; 
      AutomaticMigrationDataLossAllowed = true; 
      //When the migrations get set, I use the new class created to move the migrations to the correct schema. 
      SetHistoryContextFactory("System.Data.SqlClient", (c, s) => new MyHistoryContext(c, s)); 
     } 

     protected override void Seed(SecurityContext context) 
     { 
      ... 
     } 
    } 

Idealnie, chciałbym, żeby wszystko było w schemacie ft. Nie sądzę, że migracje są tak złożone, że muszę ręcznie skonfigurować migracje. Miałem nadzieję na prostotę, mogłem użyć do tego automatycznych migracji. Zastanawiam się, czy takie podejście jest niemożliwe i co muszę zrobić, aby to się stało i wszelkie zmiany wprowadzone w modelach zostaną rozpowszechnione.

+0

i naturalnie stosować umożliwiają migrację z automatycznym flagi, a następnie zaktualizować bez dodatek migracji .. ale ze względu hasDefaultSchema generować ten sam błąd, więc po pewnym czasie, powiedziałem niech użycie dodatek migracji i zadziałało. zarówno w migracji add-i migracji aktualizacji – deadManN

+0

to bałagan spowodowany przez Oracle przy użyciu nazw użytkowników we wszystkich wersjach i skryptów generujących EF z nazwą użytkownika w cudzysłowach jako "użytkownik". "tabela", podczas gdy rzeczywistą nazwą użytkownika jest USER – Toolkit

Odpowiedz

2

Mam podobny problem z Oracle 12c i EF6: Nie mogę uruchomić automatycznych migracji do pracy. Znalazłem jednak następujące częściowe współczynniki sukcesu: - Musiałem ustawić

modelBuilder.HasDefaultSchema("") 

na moim DbContext aby uzyskać runtime patrz tabele w schemacie logowania danego użytkownika - Dla update-bazy to było konieczne, aby ustawić parametry MyHistoryContext w następujący sposób:

public class MyHistoryContext : HistoryContext 
{ 
    public MyHistoryContext(DbConnection dbConnection, string defaultSchema) 
     : base(dbConnection, defaultSchema) 
    { 
    } 

    protected override void OnModelCreating(DbModelBuilder modelBuilder) 
    { 
     base.OnModelCreating(modelBuilder); 
     modelBuilder.HasDefaultSchema("L2SRVRIZ"); 
    } 
} 

UWAGA: W tym miejscu należy wprowadzić sztywny kod nazwy schematu. W ten sposób baza danych aktualizacji nie próbuje używać dbo jako schematu (ale nadal nie jest możliwa migracja automatyczna, usunie twoją tabelę MigrationHistory i zepsuje wszystko). Jest to moim zdaniem nieprzyjemny błąd w klasie EF6 lub Oracle. Ponieważ nie mam z nimi umowy serwisowej, nie mogę złożyć biletu.

Dla twojej sprawy, myślę, że nie jest to możliwe z powodu projektu, aby uniknąć komunikatu o błędzie z automatycznymi migracjami. EF6 myśli z jakiegoś powodu, że jeśli używasz niestandardowej nazwy schematu, faktycznie przenosisz tabelę __MigrationHistory z domyślnego schematu dbo, co oczywiście nie jest prawdą.

Czy znalazłeś rozwiązanie?

BR Florian

+0

modelBuilder. HasDefaultSchema ("") prawdopodobnie nie jest poprawna. Mam wszystko do pracy również z automatycznymi migracjami, jak tylko ustawiam login bieżącego użytkownika jako nazwę schematu: modelBuilder.HasDefaultSchema (""); - nie wiem jak to zrobić dynamicznie jednak :) – flohack