Hi Andrew,
thanks for your hints. I could get rid of the derived migration configs by setting the correct assembly and namespace. This way the initial migrations for each context are found and applied correctly. That's a first little success!
Without this first initial code-based migration there is always this exception:
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.
However, this initial DbMigration feels redundant, because the migration process looks like this:
1) No/empty db -> initial code-based and possibly outdated migration is applied
2) The current model has changed since the initial migration -> another automatic migration is created and applied
Is this first migration really neccessary (technically), when you could just apply the current model state directly?
(I also thought about a creating a faked initial code-based migration manually, that has an empty model (similar to http://stackoverflow.com/a/15027630), to avoid having an outdated code-based migration with a few hundred lines of outdated code...)
Thanks for your help
mat
Here is my MigrationInitializer:
thanks for your hints. I could get rid of the derived migration configs by setting the correct assembly and namespace. This way the initial migrations for each context are found and applied correctly. That's a first little success!
Without this first initial code-based migration there is always this exception:
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.
However, this initial DbMigration feels redundant, because the migration process looks like this:
1) No/empty db -> initial code-based and possibly outdated migration is applied
2) The current model has changed since the initial migration -> another automatic migration is created and applied
Is this first migration really neccessary (technically), when you could just apply the current model state directly?
(I also thought about a creating a faked initial code-based migration manually, that has an empty model (similar to http://stackoverflow.com/a/15027630), to avoid having an outdated code-based migration with a few hundred lines of outdated code...)
Thanks for your help
mat
Here is my MigrationInitializer:
public class MigrationInitializer<TContext>
: IDatabaseInitializer<TContext>
where TContext : DbContext, new()
{
private readonly string _connectionString;
public MigrationInitializer(string connectionString)
{
_connectionString = connectionString;
}
public void InitializeDatabase(TContext context)
{
try
{
// database already compatible?
var isCompatible = true;
try { isCompatible = context.Database.CompatibleWithModel(true); }
catch (Exception) { isCompatible = false; }
if (isCompatible)
return;
// apply current connection
var contextType = typeof(TContext);
var config = new DbMigrationsConfiguration<TContext> {
AutomaticMigrationsEnabled = true,
AutomaticMigrationDataLossAllowed = true,
ContextKey = contextType.Name,
MigrationsAssembly = contextType.Assembly,
MigrationsNamespace = contextType.Namespace + ".Migrations",
TargetDatabase = new DbConnectionInfo(
context.Database.Connection.ConnectionString,
"System.Data.SqlClient") };
// migrate to latest version
var migrator = new DbMigrator(config);
migrator.Update();
}
catch (Exception) { ... }
}
}