Search for existing suggestions

Designer support for GUID as Entity Keys

466 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    lancefisher shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    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

    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:

    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 is the right place to follow up for anyone interested.


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      • Sam commented  ·   ·  Flag as inappropriate

        @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  ·   ·  Flag as inappropriate

        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.

      • GregJF commented  ·   ·  Flag as inappropriate

        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

      • Justin commented  ·   ·  Flag as inappropriate

        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.

      • HiredMind commented  ·   ·  Flag as inappropriate

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

      • Kram commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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.

      • Mohammed Hasan commented  ·   ·  Flag as inappropriate

        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 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.

      • mike commented  ·   ·  Flag as inappropriate

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

      • Kristofer Andersson commented  ·   ·  Flag as inappropriate

        @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

      • Matthieu MEZIL commented  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base