Open lajones opened 4 years ago
On SQL Server, it looks like this syntax avoids the need to rebuild referencing foreign keys. However, this is minimized by the fact that any foreign keys created by EF will be referencing unique constraints and not unique indexes.
FWIW PG also allows various index modifications. I think there's more than enough reason to do this.
Another thought on this: when the migrations SQL generator sees an AlterIndexOperation with a facet that cannot be altered, it can automatically drop and recreate the index. This would save users the trouble of having to do it themselves.
FWIW I just ran into this again in a PG-related thing (https://github.com/npgsql/efcore.pg/issues/2899).
Per discussion with @bricelam when reviewing PR #20634
Currently a FILLFACTOR change causes a DROP and CREATE of the index on which the fillfactor is defined. But in SQL Server (2008 onwards) it's possible to just do:
We should consider the relative performance of ALTER INDEX versus DROP and CREATE and perhaps add an
AlterIndexOperation
class to migrations.Note: several other operations are allowed on ALTER INDEX. We would need to consider which of them to support.