12 comments

Add a comment…

Sign in

prestine

Your email address

Check!

invalid email

(thinking…)

Reset

or sign in with

• 
• 

UserVoice password

Forgot password?

Create a password

Your name

I agree to the terms of service

You'll receive a confirmation email with a link to create a password (optional).

Signed in as (Sign out)

Close

Close

Post comment Submitting...

• Justin commented  ·  April 13, 2012 09:33  ·  Flag as inappropriate  ·  Delete

  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  ·  March 04, 2012 06:13  ·  Flag as inappropriate  ·  Delete

  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)

• HiredMind commented  ·  December 16, 2011 11:02  ·  Flag as inappropriate  ·  Delete

  @Kram: Google "KB2561001". It's fixed! :-) (At least for DB-First, or non-Guid keys)

• Kram commented  ·  December 02, 2011 09:17  ·  Flag as inappropriate  ·  Delete

  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.

• mabster commented  ·  February 16, 2011 15:35  ·  Flag as inappropriate  ·  Delete

  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  ·  February 12, 2011 10:45  ·  Flag as inappropriate  ·  Delete

  Just something like guid.comb from NH would be perfect!

• Mohammed Hasan commented  ·  October 06, 2010 13:38  ·  Flag as inappropriate  ·  Delete

  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.

• Anonymous commented  ·  September 16, 2010 09:01  ·  Flag as inappropriate  ·  Delete

  A guid should never be the primary key of MS sql server table.

• mike commented  ·  September 13, 2010 06:29  ·  Flag as inappropriate  ·  Delete

  Yes! BUT please make sure they are sequential by date/time when generated!

• Kristofer Andersson commented  ·  September 12, 2010 21:19  ·  Flag as inappropriate  ·  Delete

  @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  ·  September 11, 2010 08:15  ·  Flag as inappropriate  ·  Delete

  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  ·  September 11, 2010 08:14  ·  Flag as inappropriate  ·  Delete

  +1.
  In my opinion, only the StoreGeneratedPattern in CSDL should be used.