Finalize EF Migration strategy

[rayrfan]

Dropping SQLite support

A hard decision but one worth making. I've supported Sqlite throughout v1 alpha and betas, the benefits of using Sqlite include:

1. out of box user can just run the app, there is no db requirement whatsoever on users part, it just works.
2. it works out of box on all the OSes, Win, Linux and Mac.
3. for user running just a personal blog sqlite is sufficient, no need to spend extra on sql server.

However, supporting both Sqlite and SqlServer means I cannot easily maintain migrations in my code, because there has to be one set of migrations to keep for each db vendor I support, this is messy.

Coming back to supporting only Sql Server, means user needs to have Sql Server pre-installed on their machine, and possibly adjust the connection string, before running the app. This is a minor inconvenience compared to having migrations in my code, benefits include:

1. easy upgrade, user can just run the new version of the app and all new db changes are applied through migration automatically
2. if other decides to add a new app or plugin, they can add their migrations along, user running that code base will automatically have the necessary db tables etc ready for the new app or plugins.
3. one less db vendor to support; sqlite migration has limitations, e.g. rename a column, which I don't have to live with

How to support multiple DbContext

So far I'm able to use multiple dbcontextes, one for Fan named CoreDbContext and one for Fan.Blogs named BlogDbContext, however I have to carry an over-all dbcontext FanDbContext in Fan.Web which is needed to do migration in startup.

Every time I add a new app or plugin I have to update startup.cs, this is not really convenient, I need to find a way to use reflection and do this part automatically.

[rayrfan]

I have dropped support for sqlite, I can concentrate on development more, don't have to switch between sql server and sqlite to test both.

I have come back to a single dbcontext that controls every entity in the entire solution, but this time I used reflection to find and load these entities, mappings dynamically.

To add a migration, open Package Manager

1. select "src\Fan" as the Default project
   Add-Migration FanSchemaV1
   This will add a new folder "Fan/Migrations" with a migration named FanSchemaV1

2. ctrl + f5, the site is up running with db automatically created

3. Add a property to Post class, say public int SortOrder { get; set; }
   Add-Migration FanSchemaV1_Add_SortOrder
   This will add a new migration.

4. ctrl + f5, site is up running with Post table have new column SortOrder added automatically in db

Any changes to db can now be down with Add-Migration and just run the app. If I want to get the sql script running behind each migration, I can run Script-Migration [-Idempotent] to review.