Migrations: ModelDiffer should find diff on navigations

[smitpatel]

ModelSnapshot contains navigation information now. ModelDiffer should utilize this info in computing differences.

[bricelam]

Thinking about how this information can be used, I've can only think of one case:

• Detect renamed foreign key columns by looking for the same navigation (or inverse navigation) property names.

Are there any others? @ajcvickers @AndriySvyryd @anpete @divega

[divega]

@bricelam that is the same one I was aware of.

[divega]

FWIW, you mentioned it when you created the original bug #2140.

[bricelam]

Oh good, my brain is deterministic over a duration of at least one year.

[bricelam]

Here is the rule I've come up with.

If a would-be-added property is part of one or more foreign key constraints, and any of those foreign key constraints...

1. Has the same principal entity type, and
2. Has the same number of properties, and
3. Has a would-be-removed property in the same position, and
4. Either
   1. The navigation property name is the same, or
   2. The inverse navigation property name is the same

...then treat it as a renamed column.

Irrelevant information:

• The property's facets
• Whether the navigation property is required
• The principal properties (including their name, position, and facets)
• The inverse navigation's multiplicity

Sound good?

[bricelam]

Here are some simple cases it covers.

 class Person {
     public int Id { get; set; }
     public ICollection<Book> Books { get; }
 }
 class Book {
-    public int PersonId { get; set; }
+    public int AuthorId { get; set; }
     public Person Author { get; set; }
 }

 class Person {
     public int Id { get; set; }
-    public ICollection<Book> Books { get; }
+    public ICollection<Book> AuthoredBooks { get; }
 }
 class Book {
-    public int PersonId { get; set; }
+    public int AuthorId { get; set; }
     public Person Author { get; set; }
 }

 class Person {
     public int Id { get; set; }
     public ICollection<Book> Books { get; }
 }
 class Book {
-    public int PersonId { get; set; }
-    public Person Person { get; set; }
+    public int AuthorId { get; set; }
+    public Person Author { get; set; }
 }

It may lead to unexpected renames and alters if you change the type to a property that doesn't convert.

 class Person {
-    public int Id { get; set; }
+    public Guid Guid { get; set; }
     public ICollection<Book> Books { get; }
 }
 class Book {
-    public int AuthorId { get; set; }
+    public Guid AuthorGuid { get; set; }
     public Person Author { get; set; }
 }

Before this change, you'd get DropColumn("AuthorId") and AddColumn("AuthorGuid").
After this change, you'll get RenameColumn and AlterColumn.
However, if it went from int to long, the new operations are preferred.

[ajcvickers]

Sounds good to me.

[divega]

@bricelam if you try to remove an existing FK and add a new FK that points to a different alternate key in the same entity type as the principal side, what would happen? (I think it is a bit ambiguous in the rules you described, but I hope it isn't in the implementation 😄).

[bricelam]

Closing in favor of doing #6582 instead.