Designer support for GUID as Entity Keys
This should be supported in the designer.
Reverting status from “under review” to “no status” since we aren’t currently working on this. We will still consider it for future releases.
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.