Entity Framework Core Update Database - Code First Approach Without Migration

Question

I've been searching for a way, it may or may not be supported yet, I guess I'm looking for a concrete answer.

What I've been looking for is the solution for the following requirements:

EFCore Code First Approach
With existing database table with significant amount of data already in place
Add a couple of columns to the said database table by updating my model
No migrations through PM Console, just using Context with Fluent Api at application start
No database recreation
The approach can be: Check a configuration file or some sort, compare it against the version in a version table in database to trigger the update
Project templates: Web Api 2, Uwp

If this is supported, is it advisable? If not, why? what are the disadvantages?

In my experience with the projects I was part of, either database first approach or code first but with database recreation.

The steps I have in mind are: - Update the model - Create migration objects - Update config file for db version - At application start, check the config version against version table - If versions do not match call Update() or Migrate() or both, with Migration objects/types as parameters

what you should do is create everything in your model of your existing db. fake the migration table information. then add any migrations to revise your database. — Daniel A. White, Oct 20 '19 at 01:24
So you really need the migrations? These can't all be achieved at application start or something like that? — Mac, Oct 20 '19 at 01:28
https://stackoverflow.com/questions/37780136/asp-core-migrate-ef-core-sql-db-on-startup — Daniel A. White, Oct 20 '19 at 01:29
Thanks for the link, I'll try those, but I remember I already did, but will try again. But this should work with Uwp and Web api 2, right? — Mac, Oct 20 '19 at 01:34

score 2 · Answer 1 · edited Jun 20 '20 at 09:12

2

This is quite opinion based, but here are my comments.

EFCore Code First Approach

Are you aware of ~~limitations of EF Core? It's linq provider cannot do everything EF6 does.~~ differences between EF and EF Core?

With existing database table with significant amount of data already in place

That's OK.

Add a couple of columns to the said database table by updating my model

This seems standard practice for EF (Core) apps.

No migrations through PM Console, just using Context with Fluent Api at application start

I don't recommend automatic db upgrades because of the risks of the migration done not when you want it. I'd call it accidental-updagrade-database.

No database recreation

I'm not sure what this means, but yes, EF (Core) can work without recreating a db.

The approach can be: Check a configuration file or some sort, compare it against the version in a version table in database to trigger the update

Project templates: Web Api 2, Uwp

The Uwp part seems irrelevant as I assume that all db access will be done via the api app.

edited Jun 20 '20 at 09:12

Community

1
1

answered Oct 20 '19 at 02:27

tymtam

31,798
8
86
126

Thanks! this is insightful. Yup I'm aware that there are limitations in efcore compared to ef6, will have to recheck what are those. Project templates I mentioned are maybe irrelevant, maybe more of fyi, as I have a separate library for data access. I'll remove the tags. – Mac Oct 20 '19 at 02:33
1

Hi @NicoZhu-MSFT, not really, but this answer is helpful. I guess I'm asking a vague question. Let me try again, I want to have a solution for my Data Access to automatically update my DB when I added a property to my Model, why automatic? because I don't want migration histories in my solution. I know automatic migration exists, but haven't had success doing so in even with a simple project, maybe I haven't found the right guide I'm looking for. But based on tymtam's answer automatic db-upgrade is not recommended. Anyway, this is just a side thought I have while working on personal project. – Mac Oct 24 '19 at 05:03

Entity Framework Core Update Database - Code First Approach Without Migration

1 Answers1