Entity Framework Feature Suggestions

Designer support for GUID as Entity Keys

794 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    lancefisherlancefisher shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Diego VegaAdminDiego Vega (Development Lead, DataFx) responded  · 

    Reverting status from “under review” to “no status” since we aren’t currently working on this. We will still consider it for future releases.

    16 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • SamSam 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 KostrukovSergey 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.

      • GregJFGregJF 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

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

      • HiredMindHiredMind commented  ·   ·  Flag as inappropriate

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

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

      • mabstermabster 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 HasanMohammed 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 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.

      • mikemike commented  ·   ·  Flag as inappropriate

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

      • Kristofer AnderssonKristofer 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 http://huagati.blogspot.com/2010/08/whats-new-in-model-comparer-for-entity.html

      • Matthieu MEZILMatthieu 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