After upgrade from 2.1 to 2.2, creating a new migration adds unexpected DropForeignKey, DropUniqueConstraint, DropColumn statements

[EddyP23]

Issue summary

We have been using EF Core for 6 months now, and recently, after updating our project from 2.1 to 2.2, any new migration script has a ton of unexpected DropForeignKey, DropUniqueConstraint, DropColumn statements. Neither of the Keys, UniqueConstraints or Columns exists, so running this on the DB obviously fails. But this prevents us from creating new migrations.

I cannot come up with a small reproducible example, but I will try to share some patterns of the statements I noticed.

Issue details

All DROP COLUMN statements happen only for classes that are owned by parent classes that are owned by a grandparent (it has to be double owning, single not enough). By owning I mean something like that:

builder.OwnsOne(
                nav => nav.MyCustomChildProperty, action =>
                {
                    action.OwnsOne(nav => nav.MyCustomGrandChildProperty);
                }
            );

In all such scenarions, in my migration scripts, I would see DROP COLUMN statements like such:

• MyCustomChildProperty_TempId
• MyCustomChildProperty_TempId1 (this one is a maybe)
• ...
• MyCustomChildProperty_MyCustomGrandChildProperty_TempId
• MyCustomChildProperty_MyCustomGrandChildProperty_TempId1 (this one is a maybe)
• MyCustomChildProperty_MyCustomGrandChildProperty_TempId2 (this one is a maybe)
• ...
  and even weirder ones like:
• MyCustomChildProperty_MyCustomGrandChildProperty_MyCustomChildPropertyClassMyCustomClassId
  Basically the pattern here is take class name of grandparent, add it to a grandparent class name, etc... and after reaching end, add Id to it.

I haven't tried to find a pattern for the other two types of statements (DropForeignKey, DropUniqueConstraint), but this seems that it should be related.

I tried deleting all of my migrations and creating a single fresh migration, and everything looks there as expected, therefore it seems that this is some bug that happens only if you already have some old migration scripts and trying to add a new one.

I have raised an SO question for this as well with no success.

Possibly relevant versions

We were running using 2.1 versions of dotnetcore andef core`.
Currently, my versions are:

• dotnet --version = 2.2.102
• dotnet ef --version = 2.2.1-servicing-10028
• Database Provider: Microsoft.EntityFrameworkCore.SqlServer, v2.2.1
• OS: Windows 10

[ajcvickers]

@EddyP23 Ideally, we need a runnable project/solution that reproduces what you are seeing. Absent of that, could you share you the model snapshot (from your Migrations folder) before and after adding a new migration that causes this issue?

[EddyP23]

Unfortunately, I can't.

But if that is of any help, a git diff after the problematic migration contains the following:

-                .HasAnnotation("ProductVersion", "2.1.4-rtm-31024")
+                .HasAnnotation("ProductVersion", "2.2.1-servicing-10028")

and a lot of lines like this:

                     b.OwnsOne("A.B.C.D.E.F", "ParameterNameOfTypeF", b1 =>
                         {
-                            b1.Property<Guid?>("SomethingId");
+                            b1.Property<Guid>("SomethingId");
+
+                            b1.HasKey("SomethingId");
...

and a lot of lines like this:

                     b.OwnsOne("A.B.C.D.E.F", "ParameterNameOfTypeF", b1 =>
                         {
+                            b1.HasKey("SomethingId");
...

and nothing else. For clarity, that is the migration that should not produce anything, as models have not changed at all.

[vasicvuk]

We have the same issue with our code with OwnedTypes.

builder.OwnsOne(b => b.ContactAddr, cb =>
{
     cb.OwnsOne(c => c.Coordinates);
});
builder.OwnsOne(b => b.LegalAddr, cb =>
{
    cb.OwnsOne(c => c.Coordinates);
});

for both LegalAddr and ContactAddr we get DropForeignKey, DropUniqueConstraint, DropColumn in migrations with some TempId1 and TempId field

Also for simple OwnsOne it creates the issue of adding primary key from class that contains that owned type. This seems to happen when inheritance is involved between classes.

modelBuilder.Entity<SampleModel>().OwnsOne(x => x.SampleOwnedType);

I would rise this issue as Blocking issue, since there is no way to upgrade from 2.1 to 2.2 in this case.

[arielmoraes]

Any news on this case? We are facing the same issue when upgrading to 2.2.

[ajcvickers]

@arielmoraes We're treating it as a bug scheduled for 3.0, but we don't have a runnable project/solution or code listing yet. If you could provide that it would be very helpful.

[arielmoraes]

@ajcvickers I will try to break down the classes needed to reproduce without showing much of our code.

In the mean time we noted that the migrations generated using the version 2.2 started to add the HasKey method for the OwnsOne relationships in the Snapshot, maybe this could be related because in the previous Snapshot the HasKey was not present and the code responsible for creating the migrations thinks those constraints should be dropped.