In my current project I use one db for different contexts using HasDefaultSchema. All contexts have a custom initializer, that automatically migrates to the newest version using Database.CompatibleWithModel(), DbMigrator.Update() and a configuration that has AutomaticMigrationsEnabled set to true.
Two things are unclear to me:
Initial DbMigration
The first Add-Migration for each contexts contains the complete model - as expected. Accessing the contexts for the first time calls the initializer and updates the db correctly using the specified schemas. From this point on, automatic migrations are applied correctly for all contexts/schemas. Without an initial Add-Migration the migrator fails to insert any table, even if the db is empty.
The documentation says:
"However, for implementation reasons, transferring the __MigrationHistory table to a different schema can only occur using a code-based migration."
So, why does migrations refuse to automatically update an empty db without an initial DbMigration, but adds tables of an other context/schema to a db, that already contains tables of another context/schema (with an initial code-based migration)? The expected behavior was, that without any added DbMigration the complete model gets added to an empty db, where no schema transferring should be neccessary.
DbMigration discovery
Not having read the source code of ef much, it's hard to know how DbMigrations are discovered. I implemented a custom initializer to do automatic migration, because my connection string names are only known at runtime (one db per tenant).
When using DbMigrationsConfiguration<TContext> only to enable automatic migrations,the custom initializer could be simplified by just creating a generic configuration for the context at runtime, enable automatic migrations and supply it to the DbMigrator.
If I don't use a derived configuration class in the same assembly as the migrations, the initial DbMigration can not be found (in the assembly of the context) and the update fails. Is there a way to tell DbMigrator where the DbMigrations live without implementing a configuration?
Thanks in advance
mat
Two things are unclear to me:
Initial DbMigration
The first Add-Migration for each contexts contains the complete model - as expected. Accessing the contexts for the first time calls the initializer and updates the db correctly using the specified schemas. From this point on, automatic migrations are applied correctly for all contexts/schemas. Without an initial Add-Migration the migrator fails to insert any table, even if the db is empty.
The documentation says:
"However, for implementation reasons, transferring the __MigrationHistory table to a different schema can only occur using a code-based migration."
So, why does migrations refuse to automatically update an empty db without an initial DbMigration, but adds tables of an other context/schema to a db, that already contains tables of another context/schema (with an initial code-based migration)? The expected behavior was, that without any added DbMigration the complete model gets added to an empty db, where no schema transferring should be neccessary.
DbMigration discovery
Not having read the source code of ef much, it's hard to know how DbMigrations are discovered. I implemented a custom initializer to do automatic migration, because my connection string names are only known at runtime (one db per tenant).
When using DbMigrationsConfiguration<TContext> only to enable automatic migrations,the custom initializer could be simplified by just creating a generic configuration for the context at runtime, enable automatic migrations and supply it to the DbMigrator.
If I don't use a derived configuration class in the same assembly as the migrations, the initial DbMigration can not be found (in the assembly of the context) and the update fails. Is there a way to tell DbMigrator where the DbMigrations live without implementing a configuration?
Thanks in advance
mat
