New Post: HasDatabaseGeneratedOption(DatabaseGenerationOption.Identity).WithDefault("NewSequentialId");

Hello Michael,

Thanks for your interest on contributing to EF. We will discuss your idea in more detail in an upcoming design meeting, but I wanted to respond with some initial thoughts:

In EF there is a small but important mismatch between the database identity option and the behavior required to support database defaults: while with the identity option the value is always expected to be set on the database and therefore values from the client are ignored, defaults are about enabling the value to come from either the client or the database.

Supporting database defaults property would most likely involve a lot of work:

• Provide a way to specify the database default value:
  • We would need to analyze whether the existing DefaultValue attribute on CSDL can be repurposed for this. Currently this attribute is used only to insert these values in code generation in database and model first scenarios and it would be a breaking change to use it for anything else.
  • We would need to support both constants and scalar function calls. Ideally either database independent or database specific functions should work. Preferably Code First would support specifying default values as LINQ lambda expressions.
• Define a new database generation option with default value semantics and adapt EF’s update pipeline to handle it correctly, e.g.: when the value coming from the client is null, the behavior is equivalent to identity, if the property value is not null, the value is included in the INSERT VALUE statement. An alternative approach would be to include the default value (or function) in the INSERT VALUE statement if the value for the property is null, instead of declaring it in the database schema.

On the other hand we currently have problems around GUID keys like the one used in your example. I believe this is a much more constrained problem space that can be addressed with much less work. Here are the most common scenarios we hear about:

1. Many applications that choose to use sequential GUIDs don’t require the ability to set the key value on the client. In those cases the fact that in SQL Server you have to specify a default value becomes an implementation detail of defining “GUID identities”.
   1. Issue 551 is about adding support for GUID identities in the EF Designer, i.e. if a property is of type GUID and has the identity database generated option, it should produce a column with a default of “newsequentialid()”
   2. Issue 71 is about switching from “newid()” to “newsequentialid()” for the default value generated for GUID identities in Code Fist. This would help create more efficient clustered indexes on the database server.
2. On the other hand other applications use mostly client-generated GUIDs that are random in nature and are not well conditioned for creating clustered indexes.
   1. Issue 614 is about providing an option to create non-clustered primary keys for GUID keys that don’t have the identity option.

In conclusion, while one could argue that there is a third scenario for supporting default values in which the GUID can come from either the database or the client, but I believe reality is that for GUID keys most applications can be written to work either like #1 or #2. Given the benefits and the relative lower cost, my recommendation would be to focus on the GUID key issues first.