I don't believe there is a simple solution to this, but I have an idea about what you could do: create a custom migration generator.
Migration generators are the components that are responsible for creating the SQL script that is run on the database from the migration code files. I assume you have SQL Server based on the screenshot. In this case, you can write a custom sql generator that simply overrides the index creation operation so that if the index is non-clustered, nothing is written to the script:
public class NoIndexGenerator : SqlServerMigrationSqlGenerator
{
protected override void Generate(CreateIndexOperation createIndexOperation)
{
if (!createIndexOperation.IsClustered)
{
return;
}
}
}
Then you have to register this component in the Configuration
class of the migration:
internal sealed class Configuration : DbMigrationsConfiguration<MyCtx>
{
public Configuration()
{
AutomaticMigrationsEnabled = false;
// Add this line to register the sql generator
this.SetSqlGenerator("System.Data.SqlClient", new NoIndexGenerator());
}
}
Now if you run Add-Migration
, you'll have a normal migration file, with the CreateIndexOperation in it. But if you run Update-Database
, the non-clustered indices will not be created. You can also check this if you run Update-Database -Script
. The resulting script does not have the non-clustered indices.
If you want, you can go even higher up in the pipeline, and create a custom C# migration scaffolder. It applies the same logic as the sql generator:
internal class NoIndexMigrationCodeGenerator : CSharpMigrationCodeGenerator
{
protected override void Generate(CreateIndexOperation createIndexOperation, IndentedTextWriter writer)
{
if (!createIndexOperation.IsClustered)
{
return;
}
}
}
Then, you can register it in the Configuration
class like this:
internal sealed class Configuration : DbMigrationsConfiguration<MyCtx>
{
public Configuration()
{
AutomaticMigrationsEnabled = false;
// Add this line to register the C# code generator
this.CodeGenerator = new NoIndexMigrationCodeGenerator();
}
}
Now, if you run Add-Migration
, the CreateIndex operations will disappear from the generated migration cs files as well.
I'd probably go with the second solution (it can be confusing for others reading your code to see that there are CreateIndex operations in the migration cs file, but not in the SQL scripts), but ultimately it is your choice :)
You can play with other properties of the createIndexOperation
parameter of the Generate()
methods to implement more sophisticated index filtering, if you have to.
If you want, you can also override the Generate methods that have a parameter of type DropCreateIndexOperation
but since indices are dropped with a 'drop-if-exists' pattern, I don't think this is necessary.
EDIT
While the above code samples seem to work, to be fair and follow general best-practices and principles, you should probably include calls to the base methods in both generators after the if statements.