EF 4.3 Auto-Migrationen mit mehreren DbContexten in einer Datenbank

Code First-Migrationen wird davon ausgegangen, dass es nur ein Migrationen Konfiguration pro Datenbank (und ein Kontext pro-Konfiguration).

Ich denken kann zwei mögliche Lösungen:

1. Erstellen einer aggregierten Rahmen beinhaltet, dass alle Personen jeden Kontext und einen Verweis auf diese "super" - Kontext aus Ihrer Migrationen configuration-Klasse. Auf diese Weise werden alle Tabellen erstellt, in der Benutzer-Datenbank, aber die Daten werden nur in diejenigen, die Sie installiert haben plugins für.

2. Verwenden Sie separate Datenbanken für jeden Kontext. Wenn Sie haben gemeinsame Einheiten zwischen den Kontexten, fügen Sie eine benutzerdefinierte migration und ersetzen Sie die CreateTable(...) Anruf mit einem Sql("CREATE VIEW ...") aufrufen, um die Daten aus der Entität "entstehen" - Datenbank.

Ich würde versuchen, #1, weil es hält sich noch alles in einer einzigen Datenbank. Sie könnten ein separates Projekt in der Projektmappe enthalten Migrationen und diese "super" - Kontext. Fügen Sie einfach das Projekt, Referenz, alle Ihre plugins " - Projekte, erstellen Sie einen Kontext, der alle Entitäten, dann rufen Sie Ermöglichen-Migrationen auf das neue Projekt. Dinge, die funktionieren sollte, wie erwartet, nach, dass.

InformationsquelleAutor der Antwort bricelam

Ich habe eine funktionierende Website mit mehreren Kontexten Verwendung von Migrationen. Jedoch, Sie brauchen, um eine separate Datenbank pro Kontext, und es ist alles angetrieben von einem *Configuration-Klasse im Migrations-namespace des Projekts, so zum Beispiel CompanyDbContext Punkte zu Unternehmen.sdf mit CompanyConfiguration. update-database -configurationtypename CompanyConfiguration. Ein weiterer LogDbContext Punkte zu Melden.sdf mit LogConfiguration, etc.

Gegeben dies funktioniert, haben Sie versucht, erstellen 2 Kontexte verweist auf die gleiche Datenbank zu und erzählte dem modelbuilder zu ignorieren die anderen im Rahmen der Liste der Tabellen?

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    modelBuilder.Ignore<OtherContextsClass>();
    //more of these
}

Seit der Migration die Arbeit mit dem ModelBuilder, könnte dies den job zu erledigen.

Beschissen alternative ist zu vermeiden, mit Automatische Migrationen, erstellen Sie eine migration jedes mal, und dann manuell zu durchforsten, und entfernen Sie unerwünschte Aussagen, dann laufen Sie, obwohl es nichts hindert Sie von der Erstellung einer einfachen tool, schaut auf die Zusammenhänge und generiert Aussagen und tut der Migrations-Korrekturen für Sie.

InformationsquelleAutor der Antwort Chris Moschini

Wie oben erwähnt von Brice, die praktische Lösung ist, um 1 super DbContext pro Anwendung/Datenbank.

Dass nur 1 DbContext für eine gesamte Anwendung zu sein scheint, einen entscheidenden technischen und methodischen Nachteil, denn es betrifft die Modularität, unter anderem. Auch, wenn Sie mithilfe von WCF Data Services Sie können nur 1 DataService pro-Anwendung, da eine DataService-Karte kann nur 1 DbContext. Also dadurch verändert sich die Architektur deutlich.

Auf der plus-Seite, ein kleiner Vorteil ist, dass alle im Zusammenhang mit der Datenbank-Migrations-code wird zentralisiert.

InformationsquelleAutor der Antwort user1718625

Habe ich es arbeiten mit manuellen Migrationen, aber man kann nicht downgraden, da es nicht discrimitate zwischen den Konfigurationen in der __MigrationHistory Tabelle. Wenn ich versuche, und downgrade dann behandelt er die Migrationen von den anderen Konfigurationen als Automatik und da ich nicht zulassen Datenverlust führt. Wir werden immer nur, es zu aktualisieren, aber so funktioniert es für unsere Zwecke.

Scheint einiges ommision obwohl, ich bin sicher, es würde nicht schwer sein, Sie zu unterstützen, vorausgesetzt, es wurde keine überlappung zwischen DbContexts.

InformationsquelleAutor der Antwort mackie

Ich will, dass die Leute wissen, dass die Antwort mit diesem unten ist das, was für mich gearbeitet, aber mit einer Einschränkung: benutzen Sie nicht die MigrationsNamespace Linie.

internal sealed class Configuration1 : DbMigrationsConfiguration<Context1>{
       public Configuration1 (){
        AutomaticMigrationsEnabled = false;
        MigrationsNamespace = "YourProject.Models.ContextNamespace1";
   }
 }

internal sealed class Configuration2 : DbMigrationsConfiguration<Context2>{
   public Configuration2 (){
        AutomaticMigrationsEnabled = false;
        MigrationsNamespace = "YourProject.Models.ContextNamespace2";
   }
}

Jedoch, ich hatte bereits die 2 Datenbanken eingerichtet, die mit Ihren eigenen Kontexten definiert, so fand ich mich immer die Fehlermeldung "YourProject.Modelle namespace bereits ContextNamespace1 definiert". Dies war, weil die "MigrationsNamespace = "YourProject.Modelle.ContextNamespace2";" war, die den dbcontext definiert werden, unter der YourProjects.Modelle namespace zweimal nach ich habe versucht die Init (einmal in der migration Context1Init-Datei und einmal, wo ich hatte es vorher definiert).

So, ich fand, dass das, was ich zu tun hatte an diesem Punkt war der start meiner Datenbank und Migrationen von Grund auf neu (zum Glück hatte ich keine Daten, die ich behalten musste) über und folgt den Anweisungen hier:
http://pawel.sawicz.eu/entity-framework-reseting-migrations/

Dann änderte ich den code, damit Sie NICHT die MigrationsNamespace Linie.

internal sealed class Configuration1 : DbMigrationsConfiguration<Context1>{
       public Configuration1 (){
        AutomaticMigrationsEnabled = false;
   }
 }

internal sealed class Configuration2 : DbMigrationsConfiguration<Context2>{
   public Configuration2 (){
        AutomaticMigrationsEnabled = false;
   }
}

Dann lief ich in den Add-Migration -Konfiguration Configuration1 Context1Init Befehl erneut aus, und die Update-Datenbank -Konfiguration Configuration1 Linie wieder (für meinen 2ten Rahmen zu), und schließlich scheint alles zu funktionieren nun Super.

InformationsquelleAutor der Antwort Notso