2017-09-21 1 views
1

Je suis à la recherche à un code en ligne où il y a deux Contextes pour la même base de données (un pour la lecture et un pour l'écriture):Pourquoi l'initialisateur de base de données doit-il être défini sur null dans un sous-contexte?

public class OrderReadContext: DbContext 
    { 
     public OrderReadContext() : base("name=GeekStuffSales") { 

     } 
     public DbSet<SalesOrder> Orders { get; set; } 

    protected override void OnModelCreating(DbModelBuilder modelBuilder) { 
     modelBuilder.HasDefaultSchema("Order"); 
    } 
    } 
    public class OrderSystemContextConfig : DbConfiguration 
    { 
    public OrderSystemContextConfig() { 
     SetDatabaseInitializer(new NullDatabaseInitializer<OrderReadContext>()); 
    } 

    } 

réponse Ladislav Mrnkas à ce poste explique que l'initialiseur doit être réglé sur null dans les sous-contextes: Entity Framework: One Database, Multiple DbContexts. Is this a bad idea?

Pourquoi l'initialisateur de base de données doit-il être défini sur null dans un sous-contexte?

J'ai essayé d'ajouter une méthode d'amorçage à l'un de mes sous-contextes, mais cela provoque une erreur indiquant qu'il y a des migrations en suspens. Est-ce que ce n'est pas autorisé?

Répondre

1

En fait, vous pouvez avoir autant de contexte que vous avez besoin sur la même base de données (la table de l'historique de la migration contient une référence au contexte).
Si les contextes partagent des tables, vous devez apporter quelques corrections aux migrations (EF essaye de créer plusieurs fois la même table). C'est probablement votre cas, c'est pourquoi vous devez désactiver l'initialiseur.

Si ce n'est pas votre cas (les tableaux se chevauchent), vous pouvez voir un exemple ici mais vous ne verrez rien d'intéressant, ça marche.

https://github.com/bubibubi/JetEntityFrameworkProvider/tree/master/JetEntityFrameworkProvider.Test/Model37_2Contexts

les tables ne se chevauchent pas, donc je viens de créer Dans ce cas, les tables en utilisant l'initialiseur standard.
Ce sont les requêtes runned sur table d'historique Migration

insert into [__MigrationHistory]([MigrationId], [ContextKey], [Model], [ProductVersion]) 
values ('201709210714271_InitialCreate', 'JetEntityFrameworkProvider.Test.Model37_2Contexts_1.Context1', 0x1F8B08000...and so on... , '6.1.3-40302'); 
insert into [__MigrationHistory]([MigrationId], [ContextKey], [Model], [ProductVersion]) 
values ('201709210714279_InitialCreate', 'JetEntityFrameworkProvider.Test.Model37_2Contexts_2.Context2', 0x1F8B0...and so on... , '6.1.3-40302'); 
+0

Voulez-vous dire que vous ne pouvez pas utiliser des méthodes de semences si une table existe dans plusieurs contextes? +1 pour la référence à la table Migrations. Merci. – w0051977

+0

Je ne suis pas sûr d'avoir compris. Le problème concerne uniquement la création de table et la migration de table. Si vous avez 2 contextes avec les mêmes entités (mêmes classes poco) et les mêmes tables (même base de données, même schéma et même table), lorsque vous créez la base de données pour les 2 contextes ou vous changez les entités, les tables avec configuration de migration standard est exécuté 2 fois, un pour chaque contexte (donc sur la deuxième table de création, vous recevrez une erreur). Ainsi, dans votre cas, vous ne pouvez activer qu'une seule migration par défaut. Sur cette migration, vous pouvez également créer des tables de démarrage. – bubi