-
Notifications
You must be signed in to change notification settings - Fork 227
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'dotnet ef migrations script' fails if any migrations had "timestamp without time zone" type #2071
Comments
First, can you please try with the latest daily build from the vNext feed? There have been some fixes in the area since RC2 was released. If you're still seeing an issue, can you please post the migration code that's causing the issue? A minimal repro would be ideal in order to investigate and fix this. |
Still the same. I will try to create minimal repro. |
https://github.com/TiraelSedai/NpgsqlScriptIssue
|
Thanks for the detailed repro, I can see the error and am looking into (if only everyone posted such a detailed step-by-step repro...!) |
OK, I understand the issue. BTW it reproes even without generating a migration; it's enough to simply upgrade to 6.0.0 and try to generate a script. The issue is that your first migration contains seeding data with a UTC DateTime for I'm guessing you set up the seeding to use UTC before even generating the first migration (while still on 5.0) - I expect that in the typical case people would just have Unspecified there. But this is indeed an upgrade difficulty - people will have to manually modify such mismatched seeding data. The same is true in the reverse, BTW: a migration seeding a Unfortunately, short of relaxing the mismatch rules (which we really try to avoid) I don't see what I can do, beyond pointing this out in the release notes... Finally, this only showed up when generating a script presumably because your database was already at the first migration. If you drop your database and try to do |
Yes, that is exactly the case. So to sum up what I have to do is to pretend my seed data was in Kind.Local until I generate the migration to timestamptz? It would definitely be useful to document what is happening somewhere here: |
Yep (though Kind.Unspecified would be slightly more accurate). There's no switching back and forth - you need to do this exactly once when you upgrade to 6.0, from that point the UTC/non-UTC distinction is enforced and you shouldn't need to do anything. Basically once you move to 6.0, I'll definitely add a note about this. |
My apologies, I just read the release notes and you've given a great guide on how to fix this issue. Thank you for that :)
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This commit fixes the migrations failing to apply because the seed data was incompatible with the new DateTime-standard in Npgsql Entity Framework Core 6. The fix involves changing all existing database items to Unspecified DateTimeKind, which are then updated to Utc-Kind by the update. See-Also: npgsql/efcore.pg#2071 See-Also: https://www.npgsql.org/efcore/release-notes/6.0.html#migrating-columns-from-timestamp-to-timestamptz
I'm using RC2.
I have project that has DateTime fields, and all of them have Kind = UTC. They used to be timestamp without time zone.
If I use
dotnet ef migrations add Timestamptz
and also addmigrationBuilder.Sql("SET TimeZone='UTC';");
to the top of Up migration it goes pretty smoothly and now fields are timestamptz as far as I can tell.However, when I'm trying to see what exactly was executed,
migrations script
fails:Here's full output in case it's useful:
The text was updated successfully, but these errors were encountered: