You've GOT to be kidding me… ADO.NET Entity Framework no Guid Keys?!?

Here I am working through some ADO.NET Entity Framework samples and I come to a standard situation, a Guid as a key.  I generate the model and try to do inserts to no avail.  I start digging and stumble upon a Stack Overflow answer to this problem.  The answer states,

Unfortunately, in v1 of the EF this is not supported. While it is
possible with SQL Server to have a column of type “uniqueidentifier”
and to set it’s default value to be “newid()”, with SQL Server 2000
there’s no good way to extract the value that the server generated at
the time you do the insert. This can be done on more recent versions of
SQL Server, though, so the intent is that we should find a clean way to
special case this support in future versions of the EF so it can be
supported on those databases that allow it and not on others. For now,
the work around is to generate the guid on the client (ideally in the
constructor of your object) rather than on the server.

Ok.  This is stupid.  This is a STANDARD practice for many database teams and developers.  Sure, sure, someone would probably fuss and say, use an int or a bigint.  No, I don't want to, I have my reasons, and I want to use a Guid.  What other bloody purpose does a Guid really have anyway except to garauntee uniqueness!  Ugh.

This I see as a failure of ridiculous magnitudes.  Seriously Microsoft needs to get in gear, and STOP releasing stuff that is supposed to compete with well baked frameworks that is completely unprepared.  The only reason the stupid Entity Framework is getting any penetration is because there are those that won't touch something (no matter how great it is) until Microsoft releases one of their own.  There are reasons behind this too, albeit somewhat stupid.

Ok, rant over, I'm going to go fix my database and use a bunch of ints for now.

2 thoughts on “You've GOT to be kidding me… ADO.NET Entity Framework no Guid Keys?!?

  1. The newid() problem IS a real problem for o/r mappers: there’s no way to obtain the new value. The main thing is the default value for a field which is ‘newid()’. There’s no way to detect that at runtime. With identity fields, one could simply obtain the latest value and that’s inserted.

    though in 2005 they introduced NEWSEQUENTIALID(), which IS retrievable with a piece of sql. llblgen pro supports this so auto-guid generation is supported through NEWSEQUENTIALID(). What’s odd is that they didn’t support this in EF. Oh well… 😉

  2. One of the things I keep thinking about when using the EF is LLBLGen. I’m this close (1 mm?) to just purchasing my own personal copy. I’ve used it in the past for an Enterprise Software Project and it was perfect. Very nice product.

    As for the newid() issue, I know it is a problem, but I just can’t imagine that it isn’t fixed yet or at least some type of default scenario solution is available for EF. Just boggles my mind.

    Thx for the comment, keep up the great work on yer blog, I’m suspecting you will! 🙂

Comments are closed.