Migration behavior changed between dotnet core 3.1 and dotnet 5

Hi, I’m unsure if this is a breaking change or just a bug / also unsure if it’s related to Npgsql.EntityFrameworkCore.PostgreSQL.NodaTime Npgsql.EntityFrameworkCore or Microsoft.EntityFrameworkCore

Repo with an example https://github.com/erwan-joly/EF5Bug

Before dotnet 3.1 the ef tools was not adding type and oldtype to altercolumn generated code. https://github.com/erwan-joly/EF5Bug/blob/master/EF31/Migrations/20210125041953_Second.cs#L10

on dotnet core 3.1 when using update-database First migration create Instant ADate as timestamp Second migration change it to Date ADate as date

on dotnet 5 First migration create Instant ADate as timestamp Second migration change it to Date ADate as timestamp

timestamp not being able to map to Date you then get runtime exception in EF5.

I’ve been able to fix this by manually adding the valid type/oldType to previous migrations(but modifying existing migration behavior seems like a bad practice). Also you don’t have this issue if you delete all migration and recreate with the recent ef tools as new tool nows add type / oldtype to altercolumn by default.

[bricelam]

We might be able to add some logic to SnapshotModelProcessor to handle this, but if the correct type simply isn’t available then there’s not much we can do, and users will need to manually update their old migrations.

[roji]

Wait, isn’t the expectation that migrations are (mostly always) forward compatible? Or is this 2.0 issue a ‘mostly always’ case?

Yes, and we do our best to always make it that way, but there are some occasion problems which it’s not always possible to fix without manual intervention. Having said that we definitely need to understand if this is something known.

@bricelam does any of this ring a bell? Probably better to start looking at #1600 (probable dup) which contains a bit more info. Have we seen issues with specifying oldType in scaffolded migration code?