Search for existing suggestions

Support database default values in Code First

152 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)

We’ll send you updates on this idea

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


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Grzegorz Pawluch commented  ·   ·  Flag as inappropriate

    Diego: "The EF team does not have plans to back port the feature to EF6, but we could consider a pull request."

    Please consider adding such feature to EF6 ;)

    Grzegorz Pawluch

  • John Doe commented  ·   ·  Flag as inappropriate

    I really LOVE Entity Framework Code First but, it's just a shame that it still feels incomplete!

    I think a lot of that comes down to EF trying to be all things to all people! Had EF been simply targeted towards MS SQL databases, and allow developers to create most, if not ALL features using attributes or Fluent API, then all would be Right in our World again!

    In any case, I've managed to 'hack' this feature using the System.ComponentModel.DefaultValueAttribute, along with some heavy use of Reflection and EF's Database.ExecuteSqlCommand, to automate the setting of entity property default values, both within the constructor AND the database, so that everything is nicely synced together.

    The hack works beautifully (and taught me a LOT about how EF works behind the scenes!) but, I would trade that all to get this feature properly installed into EF7... So here's hoping!

    On a side note... It would also be nice if the Key attribute could be augmented to provide extra features... Such as non-clustered primary keys etc.

    In short (and without the use of the overly 'complex' database migrations) it would be great if developers could leverage the FULL power of SQL by simply using attributes and Fluent API :-)

  • Dave Coates commented  ·   ·  Flag as inappropriate

    Upvote! I thought this would have been a basic requirement. Sorry guys. It just seems like such a basic requirement to me, that I'm quite unsure how this was missed/left out. Maybe it's just the way I do things but I have never come across or designed a database (except for legacy systems) that didn't require a default value constraint on at least ONE column in the database.

    Please could you back port it to EF 6 at the very least...

    Great work on EF so far though guys! It's come a long way and it get's better and better ! Nice work.

  • Rami commented  ·   ·  Flag as inappropriate

    Are there any plans to support setting the default expression from an attribute or attribute property value on the column instead of using the model builder?

    For example,

    public class Person
    [Column(DefaultExpression = "CURRENT_TIMESTAMP")]
    public DateTime CreatedOn { get; set; }


    public class Person
    public DateTime CreatedOn { get; set; }

    Thank you.

  • AdminDiego Vega (Program Manager, Microsoft Entity Framework) commented  ·   ·  Flag as inappropriate

    EF7 beta4 supports this for relational databases with the DefaultExpression() extension method on PropertyBuilder. Usage is something like this:

    .Property(p => p.CreatedOn)

    The EF team does not have plans to back port the feature to EF6, but we could consider a pull request.

  • Shaun commented  ·   ·  Flag as inappropriate

    Can we get this updated to EF 6.. maybe under 6.1.4 release?


  • James Reategui commented  ·   ·  Flag as inappropriate

    Will this work with the FluentAPI? And also not only for string or int values but datetime = utcnow etc?

  • Anonymous commented  ·   ·  Flag as inappropriate

    Must support Default Values in general...Code first or Database first. Please fix this bug

  • tne commented  ·   ·  Flag as inappropriate

    I would add to this suggestion that doing so with both the DefaultValue[1] annotation and a new PrimitivePropertyConfiguration[2] API in the model builder[3] is probably desired by most who voted.

    It's probably tied, but besides adding support for backends that support it themselves (SQL-based backends use the DEFAULT clause), the default value should be properly carried in the internal EDM model itself so that it can be used by other components like WCF Data Services[4].

    In addition, it would be extra great if EF would inject these values in tracked POCOs, which would allow developers to not redundantly specify this value in both the constructor and the model.

    Alternatively (but slightly less trivial); if the developer declares a property with a default value as virtual, EF could proxy the accessor (getter) to return the value without actually setting it automatically (only the developer can set it) so that it can simply omit them if null at SaveChanges and let the backend set it. This should optimize queries and, with certain backends, storage (potentially greatly if default values are leveraged heavily).

    Note that in the latter case, if the property is nullable and the developer explicitly sets the property to null using the property mutator (setter), EF shouldn't omit the property in the queries as null is different than the default value. Ths would require proxying the mutator as well.

    'Hope that it's a solid suggestion. Thanks for considering this.


Feedback and Knowledge Base