Migrations fail after upgrading from 1.1.1 to 2.0 - string foreign key is not defaulted to 450 characters

[clement911]

We have a large project for which we keep the entire history of all migrations.

Any developer can checkout the project and run all the migrations on their local db server to create their own db.
This worked great until we tried to upgrade from 1.1.1 to 2.0

We use asp.net on top of .net framework 4.6.1 with sql server 2016.

We have upgraded our csproj file as follows:
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.0" />
In 1.1.1, the migration used to automatically create any string primary/foreign keys with a default length of 450, which is the max size allowed for sql server.

It appears that in 2.0, the automatic length is not applied, causing all our string primary key and foreign key migration statements to fail.

We figured out that we can manually add the maxlength in the migrations, but is there a better way to handle this breaking change?

We do not want to recreate a huge single initial migration because we are not sure whether some migrations we manually modified, and the loss of flexibility to deploy on various databases that may not have all migrations ran yet.

Please in the future document all breaking changes in the migration documentation.
https://docs.microsoft.com/en-us/aspnet/core/migration/1x-to-2x/

[clement911]

In the 1.1, the following code was generated for a string key:

migrationBuilder.CreateTable(
                name: "Others",
                columns: table => new
                {
                    OtherKey = table.Column<string>(nullable: false)
                },
                constraints: table =>
                {
                    table.PrimaryKey("PK_Others", x => x.OtherKey);
                });

In 1.2, the following code gets generated:

migrationBuilder.CreateTable(
                name: "Others",
                columns: table => new
                {
                    OtherKey = table.Column<string>(type: "nvarchar(450)", nullable: false)
                },
                constraints: table =>
                {
                    table.PrimaryKey("PK_Others", x => x.OtherKey);
                });

The type: "nvarchar(450)" makes it work for new migrations but existing migrations are broken.

[smitpatel]

I investigated this. We are generating different migrations but migration generated with 1.1.2 packages with string PK is working correctly in 2.0.0 packages. While it does not have type specified explicitly, it infers type from the model built by Designer code. Since migrations add migration & designer files both, they are consistent. But if the table being created in migration is not found in designer's model (no entityType with ToTable call to given table) then we cannot infer type and generate nvarchar(max)

Removing this from milestone for re-triage.

[ajcvickers]

Notes from triage: As @smitpatel says, this seems to be functional as long as the model is up-to-date. However, assigning to @bricelam to investigate further since we should really not be specifying the type explicitly in this case since the type mapper will generate the same type by convention, which means that the Migration can be more provider-agnostic if the type is not specified explicitly.

[bricelam]

I believe I fixed this in #9469. I'll confirm before closing.

[bricelam]

Confirmed. We'll no longer generate the by-convention type in 2.0.1.

[Eilon]

Hi, we have a public test feed that you can use to try out the ASP.NET/EF Core 2.0.3 patch!

To try out the pre-release patch, please refer to the following guide:

• ASP.NET/EF Core 2.0.3 patch pre-release test feed aspnet/Announcements#274 (info)
• ASP.NET/EF Core 2.0.3 patch pre-release test feed - discussion aspnetcore#2254 (discussions and questions)

We are looking for feedback on this patch. We'd like to know if you have any issues with this patch by updating your apps and libraries to the latest packages and seeing if it fixes the issues you've had, or if it introduces any new issues. If you have any issues or questions, please reply on this issue to let us know as soon as possible.

Thanks,
Eilon

[clement911]

So if I understand correctly this only works if the migration and the entity are in sync?
But my scenario is not that. The history of all migrations is very long, and the current shape of entities is very different from when the migrations were generated.

[bricelam]

No, we let the provider re-calculate the column type using the same information it used for the model at the time the migration was generated

[bricelam]

(This is the same as it worked in all previous versions of EF Core. We inadvertantly regressed the behavior in 2.0.0.)

[clement911]

I couldn't get it working. How would it know the model used at the time the migration was generated?

[bricelam]

It's in the *.Designer.cs file.

[clement911]

Oh, I see it. However, the sql script generated is still using nvarchar(max) for the string primary key in my case, which is causing failure...

I managed to regenerate a new initial migration file with ef 2.0) to replace all the existing ones, by following this post https://weblog.west-wind.com/posts/2016/Jan/13/Resetting-Entity-Framework-Migrations-to-a-clean-Slate
Luckily I was careful enough to not manually edit the migrations, so I think this will get rid of the problem for me...