Designer support for GUID as Entity Keys
This should be supported in the designer.
After marking this as “declined” this weekend, I investigated a bit more and turns out the original issue posted here was fixed a long time ago:
The issue as originally described in a blog post that is no longer available, but a copy can be found at https://web.archive.org/web/20120201232953/http://leedumond.com/blog/using-a-guid-as-an-entitykey-in-entity-framework-4/.
In summary, changing the StoreGeneratedPattern of a GUID key property on the EF designer to Identity used not to change the corresponding store model column to Identity, then the EF runtime would not know to retrieve a generated value from the database after insert operations.
This was hotfixed in the designer in 2011: https://support.microsoft.com/en-us/help/2561001/fix-unexpected-data-entry-or-data-corruption-might-occur-when-a-visual-studio-2010-sp1-ado.net-application-changes-data-in-the-storegeneratedpattern-attribute
Now the EF designer keeps the column’s StoreGeneratedPattern in sync with property’s.
That said, there are remaining limitations:
1. Database first workflow (reverse engineering) does not recognize a default value of newid() or newsequentialid() on a GUID column as a hint that it should use StoreGeneratedPattern.Identity.
2. Model first will not automatically generate either newid() or newsequentialid() in the database column for a GUID property that has StoreGeneratedPattern.Identity.
However these last two limitations are not mentioned in the comments of this item. We could consider fixing them if there is enough interest or especially if someone form the community produces a well-written contribution. The repo at https://github.com/aspnet/entityframework6 is the right place to follow up for anyone interested.
Only took 7 years to get any reply. congrats.
Very bad you aren’t currently working on this
@Justin "GUIDs sometimes have to be a primary key. A perfect example is a WPF client app with offline access and peer-to-peer sync which we are building now."
Excellent example. Thanks.
Sergey Kostrukov commented
It should be supported by Entity Framework, even if GUID as PK or FK is a bad practice for database, because do workarounds in code is much more worst thing.
Everyone has absolutely different point of view what (and how) to use as primary keys in their database schemes.
This is a TERRIBLE idea. In EF and other ORMs Entity keys are used to identify unique records and build associations. Using a GUID to identify unique records is ok (but up for debate).
But to use them to build associations makes a terrible implementation at the DB level as index and table pages are stuffed with 32 byte records making queries much less efficient than a 4 byte int record or a 8 byte bigint.
GUIDs can be Unique not null-able keys without being PK or FK
mabster, I don't agree that EF should ensure that we don't create a clustered index. An orm should never didicate database design. Plus clustered index performance is just fine as long as you use NEWSEQUENTIALID(). That's the whole point of that function.
GUIDs sometimes have to be a primary key. A perfect example is a WPF client app with offline access and peer-to-peer sync which we are building now.
Ricardo Peres commented
A more general request: Extensible Id Generation (http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions/suggestions/1796337-extensible-id-generation)
@Kram: Google "KB2561001". It's fixed! :-) (At least for DB-First, or non-Guid keys)
Another glitch which, until fixed, makes EF unusable for us. We will consider putting EF into production apps when we no longer have to continually hack the edmx file, like manually re-adding the StoreGeneratedPattern="Identity" for GUID key fields every time the EDM is updated from the database.
GUIDs as primary keys are fine provided it's a non-clustered index. Baked in support for GUID keys should ensure that they don't create a clustered index when creating the table.
Paul Barton commented
Just something like guid.comb from NH would be perfect!
Mohammed Hasan commented
GUID not being supported 100% in the Designer is a major bug/flaw in Entity Framework 4.0 considering Microsoft itself uses GUID's as primary keys in as rudimentory framework as the SqlMembershipProvider in asp.net. Using GUID's as primary keys is a generally accepted database methodology. What were you guys thinking or not thinking? Instead of including this in the next version of the framework how about a service release to fix this problem. Manually editing the SSDL section everytime we work on a existing database model with Guid's is getting to be a major pain.
A guid should never be the primary key of MS sql server table.
Yes! BUT please make sure they are sequential by date/time when generated!
Kristofer Andersson commented
@Matthieu - FYI: I have a workaround for that in my add-in's "model comparer" feature for EF4. It allows you to choose what default constraints (e.g. newid, newsequentialid) should be treated as storegeneratedpattern=identity and which default constraints should be treated as storegeneratedpattern=computed. See http://huagati.blogspot.com/2010/08/whats-new-in-model-comparer-for-entity.html
Matthieu MEZIL commented
It's the same with Computed columns
And it's a big problem, particularly with this f... designer which lose all SSDL modification when I update my model from DB.
Matthieu MEZIL commented
In my opinion, only the StoreGeneratedPattern in CSDL should be used.