Alter Identity is always added to migrations

[overdravila]

Every time I create a migration, it adds an AlterColumn statement to change the Identity column of a property, which i have not modified. If you then try to do Update Database, it will fail, since it needs to recreate the table, and Entity Framework does not support that. Also, dropping the table is not an option, since I have data there which I can't remove. It always happen with the same entity, but it has happened with several different ones in the past. In order for me to be able to update the database with any migration, I need to manually remove that piece of code from the migration itself.

Steps to reproduce

Add a new migration

Code snippets

Generated migration file

Entity

DbContext

Exception

Further technical details

EF Core version: 3.1.3
Database provider: Microsoft.EntityFrameworkCore.SqlServer
Target framework: NET Core 3.1
Operating system: Windows 10
IDE: VS Code

[ajcvickers]

@andresargos Is it your intention to generate an Identity column for PersonTypeID? (The code has ValueGeneratedOnAdd which would indicate an Identity column, but a fixed set of values in the enum, which would be unusual for an Identity column.

[overdravila]

Yes, I want to generate an identity column for PersonTypeID. I want it to be auto incremental if I add a new record on the database, but I want it to start with the data from those enums. However, this also happens randomly sometimes for other tables, where it adds an AlterColumn for an identity field I am not touching.

[ajcvickers]

@andresargos I have not been able to reproduce this. Please attach a small, runnable project or post a small, runnable code listing that reproduces what you are seeing so that we can investigate.

[overdravila]

How should I post this? Is a link to a folder in drive okay?

[ajcvickers]

@andresargos Generally people just attach the small, runnable project to this issue.

[overdravila]

@ajcvickers Great, I am keeping my EF context and models in a separate project to the rest of the web api, so here's the complete EF project I am working on. I think you may need to change the context connection string.

ExpressMapApi.Data.zip

[ajcvickers]

I was able to reproduce this (on 3.1.4 and 5.0.0 preview 4). It appears to be caused by an enum property mapped to an Identity column.

[overdravila]

So, the recommendation would be to not use enumerations mapped on identity columns, correct? Do you think it doesn't make any sense to set that column as Identity?

[ajcvickers]

@andresargos This is a bug--it should work. As a workaround I would just delete the unneeded changes in the generated migrations.

[overdravila]

Yeah, that's what I've kept doing. Hope it gets fixed.

Thanks!

[smitpatel]

Just wondering why am I assigned to this issue @ajcvickers ?

[bricelam]

Note, it is not currently possible to mark an enum property as IDENTITY.

modelBuilder.Entity<PersonType>().Property(r => r.PersonTypeID).UseIdentityColumn();

Identity value generation cannot be used for the property 'PersonTypeID' on entity type 'PersonType' because the property type is 'PersonTypes'. Identity value generation can only be used with signed integer properties.

[ajcvickers]

@bricelam What happens if you just mark it as ValueGenerated.OnAdd?

[bricelam]

A non-IDENTITY column is created. Not sure what SaveChanges does.

[bricelam]

But, there is a bug here in that we don't mark the property in the snapshot as non-IDENTITY. We need to do this because when we use the underlying type in the snapshot, ValueGenerated.OnAdd suddenly means IDENTITY which is why we get a diff every time.

[bricelam]

I'll update the snapshot to look like this (note, there's no provider-specific Fluent API for this)

b.Property<int>("PersonTypeID")
    .ValueGeneratedOnAdd()
    .HasColumnType("int")
    .HasAnnotation("SqlServer:ValueGenerationStrategy", SqlServerValueGenerationStrategy.None);

[bricelam]

In triage, let's discuss whether we should enable enum IDENTITY properties.

[JeremyLikness]

@roji ping to track possible duplicate

[bricelam]

Duplicate of #11970