Removal of NpgsqlIndexBuilderExtensions.HasSortOrder extension breaks old migrations

[spanevin]

I have a project based on Npgsql6 which uses NpgsqlIndexBuilderExtensions.HasSortOrder extension to specify index sorting.

After upgrading to Npgsql9 I found that it can't be compiled as there is no HasSortOrder extension anymore.

It is not a problem for current version of DbContext, I can change a few lines of code to use IsDescending manually, but there are hundreds of previously generated migrations which use this extension, and they all have to be updated manually as well...

Is there any solution which helps to avoid this issue?

Unfortunately, this change is not mentioned as Breaking Change in any changelog or release notes :(

[roji]

@spanevin these APIs have been obsolete for quite a while, I decided to finally remove them in 9.0, to prevent them from showing up for new users etc. It's indeed unfortunate that this causes some breakage for people with much older migrations...

Is there some reason that it's not possible to do an automated search-and-replace from HasSortOrder to IsDescending?

[spanevin]

IsDescending is not an extension, it's an instance method of IndexBuilder

Unfortunately, NpgsqlIndexBuilderExtensions.HasSortOrder call in generated migrations is not used as an extension which could easily be replaced, but used as a static method call in a separate line
like

builder.HasIndex("Column1", "Column2")
    .HasDatabaseName("IX_Column1_Column2");

NpgsqlIndexBuilderExtensions.HasSortOrder(b.HasIndex("Column1", "Column2"), new[] { SortOrder.Ascending, SortOrder.Descending });

It is not so easy to replace this automatically...

[roji]

Yeah, I see - this would require a regular expression search, probably...

[spanevin]

I'm not sure if it can be solved by some generic Regex.Replace() which can cover params [] arguments... (as there can be any number of columns in an index)

It looks like it requires some tool which can search for such code, probably using a regex, then parse it and replace code according to the number of columns in the HasIndex arguments list.

But it becomes much more complicated if any prettier has been applied to this EF-generated code... No easy generic solution anyway...