-
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
Value generation on add failing for GUID #10070
Comments
@ZHollingshead By convention values for GUID keys are generated on the client rather than in the database. (For SQL Server, this uses a sequential GUID algorithm, similar to "newsequentialid" on SQL Server.) Client-side key generation has the advantage that new keys are available immediately rather than only after a round-trip to the database. To make EF Core use values generated on the database you just need to tell EF which database function to use to do this. Something like: modelBuilder.Entity<OrganizationInvitation>()
.Property(e => e.OrganizationInvitationId)
.HasDefaultValueSql("newsequentialid()"); |
Ah so it is. Thanks for the quick reply. I was tripped up by this line from the docs.
|
Completely agree ... Here's what i think is a simpler explanation though ... |
@ajcvickers I don't think that answer solves the issue. You're basically saying that "by convention all guid keys require something outside the db" then why does EF "sometimes" generate a migration that results in the guid keys being created by SQL and sometimes not? ^ there is definitely a bug here, if nothing else it's that the behaviour is not consistent but IMO when a property on an entity is marked with a database generated option then it should always mean that and it's EF's problem to figure out what that means regardless of "best practice". |
Can you file an issue for this including a small, runnable project/solution or complete code listing that demonstrates the behavior.
I don't fully follow this. EF Core will use different value generation strategies for primary keys depending on the type being used and the capabilities of the database provider. For GUIDs, most providers default to client-side sequential generation. This can of course be changed by configuring something else. With regards to the EF6 behavior it is by-design different from the EF Core behavior. This is because EF6 doesn't support client-generated keys, or indeed many of the value generation strategies that can be used with EF Core. So if by "not consistent" you mean between EF Core and EF6, then that is very much expected. If there is some inconsistent behavior in EF6, then please file a bug clearly describing it and we will take a look. However, we won't be making any breaking changes on EF6, and the bar for new features is very high. |
The EF6 Issue The link i provided above is describing the inconsistency I noticed that EF6 suffers in Guid Key generation. I Suspect that the core fluent API call of .HasDefaultValueSql("newid()"); being added to EF6's API layer would resolve my issue. Happy to accept that as the fix for that ticket, asusming it works as you described above if you can make that happen. Currently the only solution seems to be for me to manually hack the migration. Generating Keys, Best Practice Could you guys (someone in EF dev) explain how this (preferring client side key gen) came about as a "best practice" for EF core as I felt EF6 worked perfectly fine preferring the server to gen keys? I've always felt the lower perf came at the advantage of having the framework do more for me and supporting bulk operations was always a goal of EF Core from the outset from what I understand which could easily be handled by generating scripts that do things like use SQLBulkCopy (in the event the server was MSSQL. Honestly though, I don't mind where the keys are generated by I would just like to be able to just build an entity and not populate the primary key then ask EF (any version) to insert that in to the DB with the result being "it now has a valid saved primary key value" ... how that actually happens regarding DB scripts is essentially not my concern as a consumer of EF. For the most part, (unless the key is a string i guess) Is it not reasonable for the default to be "EF handles the key gen in some way unless user tells me otherwise" for all key properties? |
@TehWardy Your last two paragraphs describe in a general sense how EF Core works. |
Ah perfect then :) It's sounding like i may have to migrate though if Core is going to start having tooling in it that 6 doesn't ... I found .Net core to be temperamental at best though due to referencing issues. Thanks for the feedback though :) |
I totally put this ticket out of my mind after working around the problem @ajcvickers Just in case this helps in some small way here's a sort of retrospective on it ... The bottom line is that for entity keys I think the default should be that they are generated with common rules followed for types like integers and guid's with us having an ability to specify a generation expression or something if need be. I have examples like say ... a cultures table where the key is a string, requires no generation and the system should just accept what I give it but that's more of an edge case than the norm from what I understand. In my case I was finding that I couldn't get to the bottom of why in some cases the auto generated migrations would generate the auto generation calls for the key and in other cases it wouldn't. I gelt like it was a bug but never could get to the bottom as to why EF would do it some cases and not in others. I had to manually alter the migration code to do what I felt should have been automatic but the feedback I got at the time was that the Application should generate the keys not the db. |
I believe I have stumbled across a bug. Using EntityFrameworkCore 2.0, I am trying to set up a table that has a primary key of type
guid
. However, when I add the migration, the new primary key is not set to auto-generate. According to the generated values documentation this should work.Steps to reproduce
Entity
DbContext
EF Setup in Startup.cs
I run
Which results in the following migration that is missing the code to auto-generate the guid.
I have tried my initial migration with all of the following, and I believe valid, combinations for the Id field.
In each case, the migration produced the incorrect migration code. However, upon renaming the property to a valid Id (examples 1 and 2) or with a non-conventional name and explicitly defining it as a key (example 5), the second migration will produce migration code that would look as though it will work, specifically it adds the following line to the column properties.
That seems to be incorrect as well and is causing the database to simply generate a GUID of
00000000-0000-0000-0000-000000000000
.Further technical details
EF Core version: 2.0
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Database: Microsoft Azure SQL Server
Operating system: Windows 10 Professional (15063)
IDE: VS Code and Visual Studio 2017, using the dotnet-cli tools.
The text was updated successfully, but these errors were encountered: