2014-12-08 8 views
7

Ich versuche automatische Migrationsaktualisierungen mithilfe der IdentityDbContext-Klasse einzurichten und Änderungen an den tatsächlichen DbContext für die gesamte Datenbank zu übertragen.Entity Framework mit IdentityDbContext mit Code First Automatische Migrationen Tabellenposition und Schema?

Bevor ich in den Code zu bekommen, auf meiner Umsetzung des IdentityDbContext mit automatischer Migration bekomme ich diesen Fehler:

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.

Ich bin nicht die Modelle gehen zu schreiben, die mit den Migrationen und Kontext-Code zugeordnet sind, es sei denn, jemand findet sie nützlich.

Implemenation des 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"); 
     } 
    } 

Also habe ich versucht, diese Klasse Hinzufügen der Migrationen Geschichte in die richtige Schema zu platzieren. Dies verschiebt den Migrationsverlauf tatsächlich in das richtige Schema, aber alles andere verbleibt im dbo-Schema.

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) 
     { 
      ... 
     } 
    } 

Idealerweise würde ich gerne alles im ft Schema sein. Ich denke nicht, dass die Migrationen so komplex sind, dass ich die Migrationen manuell einrichten muss. Ich habe der Einfachheit halber gehofft, ich könnte automatische Migrationen dafür verwenden. Ich frage mich, ob dieser Ansatz unmöglich ist und was ich tun muss, um dies zu erreichen, und alle Änderungen, die an den Modellen vorgenommen werden, werden propagiert.

+0

i verwendet natürlich Migration mit automatischer Flag aktivieren, und dann aktualisieren, ohne Add-Migration, .. aber durch hasDefaultSchema es denselben Fehler zu erzeugen, so dass nach einiger Zeit sagte ich Add-Migration lassen, und es funktionierte .. sowohl in add-migration und update-migration – deadManN

+0

das ist ein chaos durch Oracle using Benutzernamen in Großbuchstaben und EF generiert Skripts mit Benutzernamen in Anführungszeichen als "Benutzer". "Tabelle" während tatsächliche Benutzername ist USER – Toolkit

Antwort

2

Ich habe ein ähnliches Problem mit Oracle 12c und EF6: Ich kann nicht automatische Migrationen zu arbeiten. Ich fand jedoch die folgenden Teilerfolgsfaktoren: - Ich brauchte

modelBuilder.HasDefaultSchema("") 

auf meinem DbContext zu setzen, um die Laufzeit finden Sie in die Tabellen im Anmeldeschema des jeweiligen Benutzers zu erhalten - Für die Update-Datenbank es war notwendig, um die MyHistoryContext Parameter so einzustellen:

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"); 
    } 
} 

Hinweis: Sie müssen hart Code der Schemaname dort. Auf diese Weise versucht update-database nicht, dbo als Schema zu verwenden (aber noch sind keine automatischen Migrationen möglich, sie werden Ihre MigrationHistory-Tabelle löschen und alles vermasseln). Dies ist meiner Meinung nach ein ekliger Fehler in EF6 oder der benutzerdefinierten Oracle-Klasse. Da ich keinen Wartungsvertrag mit ihnen habe, kann ich kein Ticket einreichen.

Für Ihren Fall halte ich es irgendwie nicht für möglich, die Fehlermeldung mit automatischen Migrationen zu vermeiden. EF6 denkt aus irgendeinem Grund, wenn Sie einen benutzerdefinierten Schemanamen verwenden, dass Sie die __MigrationHistory-Tabelle tatsächlich aus dem Standard-Dbo-Schema verschieben, was natürlich nicht stimmt.

Oder haben Sie eine Lösung dafür gefunden?

BR Florian

+0

modelBuilder. HasDefaultSchema ("") ist wahrscheinlich nicht korrekt. Ich habe auch mit automatischen Migrationen alles im Griff, sobald ich den Login des aktuellen Benutzers als Schemaname gesetzt habe: modelBuilder.HasDefaultSchema (""); - weiß nicht wie man das dynamisch macht :) – flohack

Verwandte Themen