Reverse engineering feature does not honor cascade delete settings for foreign keys.
If FK1 has Delete Rule set to No Action in SQL Server, the following mapping is generated.
```
this.HasRequired(t => t.Entity)
.WithMany(t => t.RelatedEntities)
.HasForeignKey(d => d.EntityId);
```
This implies delete on cascade which goes against what the database was originally designed to do. It should be generating the following...
```
this.HasRequired(t => t.Entity)
.WithMany(t => t.RelatedEntities)
.HasForeignKey(d => d.EntityId)
.WillCascadeOnDelete(false);
```
To work around this I customized the T4 template. I set a bool as follows
```
bool cascadeDelete = navProperty.ToEndMember.DeleteBehavior == System.Data.Metadata.Edm.OperationAction.Cascade;
```
Then added the .WillCascadeOnDelete() method based according to the value in the bool. T4 is attached.
In this situation, the database has over 50 tables and the rules whether to cascade or not vary from table to table. So adding this in manually after the generation would be a huge time sink. I believe this should be defined by default rather than leaving it up to the built in conventions.
If FK1 has Delete Rule set to No Action in SQL Server, the following mapping is generated.
```
this.HasRequired(t => t.Entity)
.WithMany(t => t.RelatedEntities)
.HasForeignKey(d => d.EntityId);
```
This implies delete on cascade which goes against what the database was originally designed to do. It should be generating the following...
```
this.HasRequired(t => t.Entity)
.WithMany(t => t.RelatedEntities)
.HasForeignKey(d => d.EntityId)
.WillCascadeOnDelete(false);
```
To work around this I customized the T4 template. I set a bool as follows
```
bool cascadeDelete = navProperty.ToEndMember.DeleteBehavior == System.Data.Metadata.Edm.OperationAction.Cascade;
```
Then added the .WillCascadeOnDelete() method based according to the value in the bool. T4 is attached.
In this situation, the database has over 50 tables and the rules whether to cascade or not vary from table to table. So adding this in manually after the generation would be a huge time sink. I believe this should be defined by default rather than leaving it up to the built in conventions.