Quick Notes: EF Core Tools (VS)

** Brackets should not be included, they indicate a parameter. **

These commands work in visual studio. The CLI tool has slightly different arguments.

Migrations:

• Add Migration: Add-Migration <migrationName> - will build the project, then create a migration file for the set of models. NOTE: If build fails, this will not work. Program must be compilable for this to work.
• Remove Migration: Remove-Migration - will remove the last migration.

Database:

• Update Database:
  • Update-Database - this will update the database to the current Migration file (I believe it "plays" the migration files after checking the DB migrations table for what's missing).
  • Update-Database <MigrationName> -this will downgrade a server to a specific migration
  • Update-database -Migration 0 - This will basically remove all applied migrations from the server

Play Book/Issues

• Scenario: DB can't make key field changes on Update DB command after you changed key attributes or identity attributes in your model class. In this case, use the "Remove Migration" command repeatedly until your migration files are empty (or until it is appropriate). Then run "Update-database -migration 0" to wipe out the database. Finally, re-add a migration with something like "Add Migration NewStructureChanges" and finally "Update-Database".
  
  WARNING - this is data destructive and should be performed in your dev environment. If you happen to be doing this directly in Prod and you don't want to lose the data, backup the data for reimport.
• EF tooling will also auto-handle foreign key constraint creation and insertion on nested model collections within a model. Suppose you have a Vendor class with a list of Addresses (something like List<Address> Addresses). When you build the migration it will create a foreign constraint on the addresses table, and add the key field from the vendor class to the database. When you use the DB context to add a vendor, it will automatically insert that vendors addresses into the addresses table, automatically with the foreign key of the vendor.
  This may not be desired if you are wanting to use a generalized Key that happens to span multiple tables (suppose you want a contact key that might be a vendor key, a customer key, or an employee key). It appears this can be done, but must be done with foreign key mapping.