Migrations: Improve existing database support

[bricelam]

We need to create a good experience to bootstrap an existing database with Migrations.

Things to consider:

• The database may have been using Migrations in EF6
• The first migration should be able to re-create the starting database schema
• The user shouldn't have to jump through hoops like commenting out code or only running part of a script.

[divega]

This need came up while prototyping the solutions for aspnet/Identity#457. In that particular scenario a few new columns need to be added to the database as part of the upgrade, which may or may not pose an additional challenge.

In general EF Core Migrations cannot predict the current schema of a database regardless of how it was created and whether there are additional model changes in the upgrade. Even if the database was maintained using EF6 Migrations there are functional differences between the stacks that will make the database look different.

Here is a set of ideas we talked about that could be used to address this:

1. We add a way to point our reverse engineering engine to the existing database to obtain a model snapshot (and possibly an accompanying initial migration).
2. The user creates a migration based on the current EF Core model and the snapshot obtained in the first step.
3. The user looks at this migration and decides which adjustments should be made to the model (e.g. column and tables renames in OnModelCreating()) to better match the existing database.
4. After each adjustment to the model the user can go back and re-scaffold the migration created in step 2, iterating over steps 2 and 3 as many times as necessary until a migration representing the desired diff is obtained (the migration should be empty if the model was made match the database completely).
5. If there are outstanding changes and the database needs to be upgraded the user can make any necessary manual edits to the migration and apply it.
6. At this point the database in the model can be considered in sync and the user can proceed using Migrations normally.

As @bricelam mentioned above, the database could have been created using EF6 Migrations in which case we will need to do something with the migrations history table, i.e. we either make the EF Core table compatible with the EF6 one in which case we can simply add a new row or we may have to drop/move the table and existing migration history rows somewhere else.

[divega]

Noticed this issue has the pri0 but hasn't been assigned. Assigning to @bricelam since he owns our migrations story.

[divega]

Also, note that the proposal described in a previous comment should be much easier to implement if the IModel that is the output of the reverse engineering pipeline used the same annotations and other constructs that a regular model produced by code first would use (see #2714).

[rowanmiller]

Decided we will handle this with docs. Because there are so many nuances to how you might want it to work, we don't think we can build a high level feature that just works. We may drive improvements to the building blocks as we write the docs.

dotnet/EntityFramework.Docs#91