How do I change the default for DeleteBehavior?

[Eaglef90]

As mentioned in #3815 the default behavior for DeleteBehavior is CASCADE. In EF6 this could be over ridden with one simple line of code:

modelBuilder.Conventions.Remove();

There seems to be no equivalent inside EF7. Yes, you can type out something like 5 lines of code for every single FK property and explicitly change the behavior but when you have over 100 properties that gets tedious and has a good potential for introducing problems. There was a solution provided in the issue I linked but when I use that then no migration data is generated. I have searched Google and even asked on Stack Overflow but am getting no where. Is there a way to change the default behavior? If not there really should be.

[smitpatel]

The solution provided in #3815 is correct. If you have not generated FKs on database yet then the solution works fine. But if you already have FK generated in previous migration then as you noticed it generates no migration data due to different bug which got fixed in #3756 (will be shipped in RC2).

The bug is ModelSnapshot is not storing the delete behavior.
In the absence of any extra code, the migration generated will have DeleteBehavior as CASCADE. Migration scripts are generated based on the migration files so database will get CASCADE behavior.
Now since the model snapshot doesn't store delete behavior according to snapshot the delete behavior is Restrict. So when you generate new migration with above solution no migration data is generated since runtime model matches with model snapshot. This is only happen if you change the behavior to Restrict. For anything else it works fine (creating down operation with Restrict because that what model snapshot says).

Work-around till RC2 release would be set the default behavior to SetNull. This will generate migration file. And edit up method in migration file to change the SetNull to Restrict. (Find & Replace) If you run migration script based on this edited migration, it will drop FK on database & create a new one with changed action.

[Eaglef90]

The Database I am running against has no existing tables, this is the initial creation of it so no I have not generated any FKs on it yet so something else wrong is happening. Also, why so fast to close this? Maybe I have ran into some bug?

[smitpatel]

For the first migration, if the default behavior is changed then generated migration file & script both reflect the changes well. I am able to reproduce empty migration for modifying FK but not for the first one.
Few questions:

1. Which version of EF are you using?
2. What behavior are you trying to set?
3. Is this happening for first migration or subsequent one?

[Eaglef90]

1: "EntityFramework.Core": "7.0.0-rc1-final",
2: I am trying to set DeleteBehavior.Restrict
3: This is the very first migration. If I remove the solution code the Initial.cs file is generated and contains the code to make my tables. If I delete the file and the other .cs files in the Migrations Folder and then run the migration with the code from the solution a Initial.cs file is made but contains no code in the two methods.

[smitpatel]

I did 3rd step in the same way. After deleting the migrations folder, I ran the migration with solution. But the initial file made has code to generate tables (with Restrict behavior).
Can you share the repro project? (probably minimizing it to 2 entities if there are many entities)

[Eaglef90]

Here is the project, if it is working for you I am sure I am running into some edge case bug or misconfiguration some where.

https://drive.google.com/file/d/0BxA-roBz9DmBcmU3clFYNHo1aDg/view?usp=sharing

[smitpatel]

Thanks for the project.
Steps I followed:
I deleted migrations folder from WebUI project. And tried following scenarios.
Scenario 1:
When I create first migration, FK is set to Restrict. This is happening because the FK property ParentId is nullable. Cascade is set as default only for non-nullable FKs.
Scenario 2:
I changed ParentId to Int16 (non-nullable).
When I generate first Migration without solution code. It sets the FK to CASCADE. This is what default EF behavior is.
Scenario 3:
Keeping ParentId non-nullable, I applied the solution code and created first migration, it created FK to be restrict.

Can you help out with more details on the steps followed?

[Eaglef90]

I am not sure where you see "ParentId" at, I don't have any properties named that and the only nullable In16 I have is named "ApprovedByID" is that the one your talking about? But my steps are these:

1: Without the code from your solution I Build Solution
2: Run dnvm install latest -r coreclr from the command line in the JobSight.WebUI folder
3 Run dnx ef migrations add Inital -p JobSight.DAL from command line
At this point Migrations files are generated fine
4. Delete Migrations folder from solution
5. Add your solution code to ot OnModelCreating override method in JobSightDBContext.cs
6. Change modelBuilder to modelbuilder
7. Build Solution
6. Run dnx ef migrations add Inital -p JobSight.DAL from command line again.
This is where I can go into the new migrations folder and see that...

What the heck? Now it is working. I swear it was not working before. I don't know maybe something was wrong in VS? I did just have to uninstall Enterprise and install Pro as the IT department installed the wrong edition for my license key. I am sorry, I don't know what has changed. I tried to get the migration to build at least a dozen times using your solution code and it never would till now.

For future reference, will the loop always be the way to do this or is there a cleaner way of doing it (like in EF 6) in the works?

[smitpatel]

Its alright. Glad it is working now. If you have any further questions let me know.

[Eaglef90]

For future reference, will the loop always be the way to do this or is there a cleaner way of doing it (like in EF 6) in the works?

[smitpatel]

Loop is one way to do this. It was not possible in EF6 but it is in EF7.
Have a look at #214 for future plans around Custom conventions.

[Eaglef90]

I will take a look at it, thanks again for helping me out. I really appreciate it.