The fields with default values and not null change to nullable in the Scaffold process.

[JuanIrigoyen]

I receive a lot of warnings in the Scaffold process with fields that have a default value and not nullable in 2.0 version. I have read the article about this https://go.microsoft.com/fwlink/?linkid=851278 and https://docs.microsoft.com/en-us/ef/core/saving/explicit-values-generated-properties, but I cannot understood this change. All the changes of the default values, triggers or any other procedures that can alter the registry when registering a inserted are solved by rereading the record after giving it to insert it.

This is a big problem on models like mine because I have a lot of fields of type bool, all numeric and money fields have default value 0 and don't let null values, because I need this configuration in my database and model, and that would force me to modify the entire application, thousands of lines of code, forms, controls, etc.

The Scaffold-DbContext change the type of field to nullable. I think that it's a mistake because in the table of database the field is not nullable, only have a default value.

Further technical details

EF Core version: 2.0
Database Provider: Sql Server 2016
Operating system: Windows 10 Pro
IDE: (Visual Studio 2017)

[ajcvickers]

@JuanIrigoyen Would it be fare to say that even though the database has default values on columns, your application is not intending EF to behave any differently because of this? That is, any value you provide should be inserted as is? If so, then I filed #9627 to consider this. If not. how is it that you expect the defaults to be used by EF?

[JuanIrigoyen]

This change break with the model, if you need to use the default value in a entity, the logical is set these in the constructor of the class or in the property how default value. The problem is when the database modify the record after insert with a trigger, calculate fields, another procedure or function of transact-Sql that EF don´t know. For example if your default value is a function in sql server how default([dbo].[NEWDOC_Order]()) EF never to know this. In this case the default value will be lost and you always must to read the records inserted before return it to EF, but if EF know the function, numeric values, getdate() or other basic functions these can be set in the constructor or in the properties if I have a bool field and in my model the field refer to bool?, the validations an other functions are different. In numeric fields If I make a sum I would be forced to change the function to not read the null values. If I have a default value in a table with not null in my model must be the same because I must to change my validations and programs for this cause. I´m sure that this behavior is not correct.

In my opinion the use of default values ​​should be something like this:

public partial class Customer
{
    public Customer()
    {
        Date = DateTime.Now;    // Default Value "Getdate()"
        Total = 100;	        // Default Value 100
    }

    public string CustomerId { get; set; }
    public string Name { get; set; }

    [DefaultValue("Getdate()")]
    public DateTime Date { get; set; }

    [DefaultValue(100)]
    public decimal Total { get; set; }
}

// Or using default values in properties

public partial class Customer
{
    public Customer()
    {

    }

    public int CustomerId { get; set; }

    public string Name { get; set; }

    public DateTime Date { get; set; } = System.DateTime.Now;  	    // Default Value "Getdate()"

    public decimal Total { get; set; } = 100;                       // Default Value 100
}

[ajcvickers]

@JuanIrigoyen It seems like you are asking for a different feature--that is, the use of column defaults to generate CLR defaults for properties in generated code. I filed #9632 for this.

For the rest of your comments, are you saying that the way EF handles store-generated values in general is something that doesn't work for you? Or are you saying that the reverse engineering to nullable bools is what is causing you problems?

[JuanIrigoyen]

Both because in EF the default values is part of metadata, but if you add a new class based in a entity in your program this entity don't take the default values until the entity is inserted, with this approximation the Entity take set the basic default values, numeric values, date and time functions, etc.

For this reason, I have development a program for set the default values in my entities class using reflexion. This part is only a proposal for the handling of basic default values.

The problem with the bool values is new in the 2.0 version, I can´t use this version until resolve this and other problem with the nvarchar types.

Sorry for mixing both.

[ajcvickers]

Closing this since all issues are now tracked elsewhere.

[ajcvickers]

Hi @JuanIrigoyen. We are gathering information on the use of EF Core pre-release builds. You reported this issue shortly after the release of 2.0.0 RTM. It would be really helpful if you could let us know:

• Did you consider testing your code against the pre-release builds?
• Was there anything blocking you from using pre-release builds?
• What do you think could make it easier for you to use pre-release builds in the future?

Thanks in advance for any feedback. Hopefully this will help us to increase the value of pre-release builds going forward.