Views handling

[daiplusplus]

See issue #431

This change introduces two separate, but complimentary, features:

• Settings.ViewProcessing - a callback modified by consumers to manually define primary-keys in VIEWs to override the default behavior of setting all non-null columns as primary-key columns.
• Settings.AddForeignKeys - a callback modified by consumers to add additional foreign-key relationships so that strongly-typed navigation properties are added by the T4 template.
  • AddRelationship - a helper function called from inside AddForeignKeys that simplifies the definition of foreign-keys, especially when VIEWs are involved.

It also makes a few other changes:

• Adding __RefactorLog to the list of tables to exclude from POCO generation.
• Removing the unused property ForeignKey.FkTableNameFiltered

I think it's ready to be merged into master, but I did leave a TODO in there because I feel the code could be simplified, for example do we need PkTableNameFiltered?

[sjh37]

Thanks Jehoel.
Many thanks.
In the EF.Core branch, I've done extensive refactoring into a project named 'Generator'. This is a plain C# DLL which will be used to develop the tt going forwards. Not yet, but I plan as part of the build process (via cake or something similar) that the .tt and .ttinclude files to be completely created from the 'Generator' project.
The 'Generator' project will support EF6+7 initially, then eventually multiple databases.

[sjh37]

Yes, ForeignKey.FkTableNameFiltered is unused and can be removed. PkTableNameFiltered is used an cannot be removed.

The 'Generator' project on the ef.core branch is not on it's feet yet, and still needs time to stabilize before I could accept merges into that.

[sjh37]

Amazing work. Thanks Dai.

[daiplusplus]

Thank you for the kind words :)

I'll say I feel a bit uncertain about the defaults I chose where ordinal: Int32.MaxValue, cascadeOnDelete: false, and isNotEnforced: false - I'm not entirely sure if they're correct and/or how they even work. Given that rows in a view would be removed if the source data is removed then does that constitute a cascading-delete and an "enforced" relationship as far as EF is concerned, for example?

[sjh37]

Released in v2.37.0