Identity Insert still indicates error with version 1.1.1

[brentlyjdavid]

Describe what is not working as expected.

Identity insert not working correctly. Still shows same error as #6426

Steps to reproduce

See attached codebase, run it and hit the contact route. This will trigger the error i am seeing.

WebApplication1.zip

Further technical details

EF Core version: 1.1.1
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Operating system: Windows 10
IDE: Visual Studio 2017

[brentlyjdavid]

@ajcvickers, here is the new issue as requested.

[ajcvickers]

@brentdavid2008 The code is making a non-key property use an Identity column. These seems to be working as expected, although note that there is no need for this:

builder.Entity<Invoice>()
    .Property(p => p.InvoiceNumber)
    .UseSqlServerIdentityColumn();

since the default for SQL Server is to create an identity column anyway.

However, Identity columns cannot be updated. Normally for a key the property is marked as read-only, so EF does not attempt to update the column by default (unless you explicitly change the value.) But since this is a non-key property it is not marked as read-only. So, assuming you don't intend to try to change the value, then you can add the following code to make it read-only:

builder.Entity<Invoice>()
    .Property(p => p.InvoiceNumber)
    .Metadata.IsReadOnlyAfterSave = true;

Referencing #7913 also here, since we may be able to do something better by convention in this case.
See also #8271

[brentlyjdavid]

Yeah, i just wanted a SQL server generated column for numbers, it never should be updated. Why doesn't this happen by default when i have the database generated attribute like it did in EF6?

[ajcvickers]

@brentdavid2008 Because EF Core supports having a column that gets a store-generated value on insert but can then later be updated. For example, if you have a default constraint on the column. It's just that SQL Server doesn't allow this for Identity columns.

[brentlyjdavid]

I guess my assumption is that there should never be a reason why someone would ever want to update an identity column. SQL doesn't even allow this through SSMS. So to have it error out on a field that is [DatabaseGenerated(DatabaseGeneratedOption.Identity)] seems odd to me.

I would presume EF would know how to handle that since the method indicates it understands it as a SQL database. (hence .UseSqlServerIdentityColumn()). Why does it still error out in that case?

I may be misunderstanding it though.

Thanks!

[ajcvickers]

@brentdavid2008 Yes, it would be possible to write a convention that connects the dots back from it being a SQL Server Identity column to it getting this behavior by default. That's why I liked #7913, which is about better experiences in this area. But it's pretty uncommon to have Identity for a non-key column, so this doesn't come up very often.

[brentlyjdavid]

Sounds good, Thanks for the clarification.