How does Entity Framework code first create an index in descendant order?

Question

In the free API, we can specify the index in the field:

var indexAttr = new IndexAttribute("IX_EmployeeNumber") { IsClustered = true }; Property(c => c.EmployeeNumber) .HasColumnAnnotation("Index", new IndexAnnotation(indexAttr )) .HasMaxLength(8) .IsRequired(); 

After Add-Migration we get the CreateIndex statement:

 CreateIndex("dbo.Employees", "EmployeeNumber", clustered: true, name: "IX_EmployeeNumber"); 

After a Update-Database , we have sql like this:

 CREATE CLUSTERED INDEX [IX_EmployeeNumber] ON [dbo].[Employees] ( [EmployeeNumber] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] GO 

My question is: how can I create this index in a descendant stream? Something like:

 CREATE CLUSTERED INDEX [IX_EmployeeNumber] ON [dbo].[Employees] ( [EmployeeNumber] DESC 

I could not find the related parameters in CreateIndex . Is it possible to be achieved in the first code migration?

Of course, we know that we can get everything that works with DbMigration.Sql(...some sql statement...) . But how can we get the desired result using CreateIndex() ?

Answer 1

See how to set up the first route migrations from the Rowan Miller blog (one of the Entity Framework program managers).

This describes how to override the SqlServerMigrationsSqlGenerator sql generator so that user arguments affect the generated sql.

As it happens, the script that it scans extends the default behavior of the CreateIndex migration operation to support the indication of the creation of a descending index index .

However, I do not think that you can point this extension point to the code for creating the code model of the code.

Answer 2

I wanted to do what you requested, but also do it with multiple columns and multiple orders.

Based on the answer of Matt Caton and Rowan Miller's blog, I was able to answer my own question and get my own solution that works as general as possible (knowing that you cannot easily extend Entity Framework classes to add properties that don't exist).

For an exact solution, see this answer .