-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Using ValueGeneratedOnAdd
on a property that is seeded causes UpdateData
calls in every subsequent migration
#21661
Comments
Given |
@smitpatel I switched it to use the following and it still does not work properly: entity.Property(x => x.TimeZone).IsRequired().HasDefaultValueSql("('UTC')")
.HasConversion(x => x.Id, x => TimeZoneInfo.FindSystemTimeZoneById(x))
.Metadata.SetValueComparer(new ValueComparer<TimeZoneInfo>((a, b) => a.Id == b.Id, x => x.GetHashCode())); Also, why would this issue happen only when using FYI: var a = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");
var b = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");
Console.WriteLine(a == b); // False
Console.WriteLine(a.Id == b.Id); // True
Console.WriteLine(a.GetHashCode() == b.GetHashCode()); // True
Console.WriteLine(a.Equals(b)); // True
Console.WriteLine(Object.Equals(a, b)); // True
Console.WriteLine(Object.ReferenceEquals(a, b)); // False |
@smitpatel After playing around a bit, I can confirm that this has nothing to do with value conversion, but rather seeding any value (including built-in CLR types) that use The following entity setup also has the issue: public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}
public DbSet<TestEntity> TestEntities { get; set; }
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<TestEntity>(entity =>
{
entity.HasKey(x => x.Code).IsClustered();
entity.Property(x => x.TimeZone).ValueGeneratedOnAdd();
entity.HasData(new TestEntity(
code: "code-1",
timeZone: "Eastern Standard Time"
));
});
}
}
public class TestEntity
{
public TestEntity(string code, string timeZone)
{
Code = code;
TimeZone = timeZone;
}
public string Code { get; set; }
public string TimeZone { get; set; }
} |
UpdateData
callsHasDefaultValueSql
on a property that is seeded causes UpdateData
calls in every subsequent migration
HasDefaultValueSql
on a property that is seeded causes UpdateData
calls in every subsequent migrationValueGeneratedOnAdd
on a property that is seeded causes UpdateData
calls in every subsequent migration
…very migration Fixes dotnet#21661
I believe that I found the root cause of the issue, so I created a unit test and a PR with my changes. It looks like ValueGeneratedOnAdd properties were not being accounted for when comparing the values in the |
…very migration Fixes dotnet#21661
…bug generating a change only in the Down method. See dotnet/efcore#21661
Every time I create a new migration, even when no data has changed, my migration contains a call to
UpdateData
when one of the properties is configured withHasDefaultValueSql
andHasConversion
. If I remove theHasDefaultValueSql
call, the issue does not happen.Steps to reproduce
EFCore 3.1.6:
https://github.com/ChristopherHaws/bug-repro-efcore-migrations
EF Core 5.0.0-preview.6.20312.4:
https://github.com/ChristopherHaws/bug-repro-efcore-migrations/tree/dotnet-5
Given the following DbContext configuration, if you call
dotnet ef migrations add
twice without changing configuration, the migration script will contain anUpdateData
call to theTimeZone
field.The second call to
dotnet ef migrations add
results in the following migration:Output for
dotnet ef migrations add NoChanges2 --verbose
-->
Further technical details
EF Core version: EF Core 3.1.6 (and prior) as well as EF Core 5.0.0-preview.6.20312.4
Database provider: Microsoft.EntityFrameworkCore.SqlServer
Target framework: .NET Core 3.1 as well as .NET 5.0.100-preview.6.20318.15
Operating system: Windows 10
IDE: PowerShell or Visual Studio 2019 16.7.0 Preview 4.0
The text was updated successfully, but these errors were encountered: