You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A hard decision but one worth making. I've supported Sqlite throughout v1 alpha and betas, the benefits of using Sqlite include:
out of box user can just run the app, there is no db requirement whatsoever on users part, it just works.
it works out of box on all the OSes, Win, Linux and Mac.
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:
easy upgrade, user can just run the new version of the app and all new db changes are applied through migration automatically
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.
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.
The text was updated successfully, but these errors were encountered:
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
select "src\Fan" as the Default project Add-Migration FanSchemaV1
This will add a new folder "Fan/Migrations" with a migration named FanSchemaV1
ctrl + f5, the site is up running with db automatically created
Add a property to Post class, say public int SortOrder { get; set; } Add-Migration FanSchemaV1_Add_SortOrder
This will add a new migration.
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.
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:
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:
How to support multiple DbContext
So far I'm able to use multiple dbcontextes, one for Fan named
CoreDbContext
and one for Fan.Blogs namedBlogDbContext
, however I have to carry an over-all dbcontextFanDbContext
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.
The text was updated successfully, but these errors were encountered: