My team has inherited a database application that contains hundreds of tables. The application uses Entity Framework and takes a database first approach for development. Our current process is to pull a table or two at a time into the edmx using the Update Model From Database... tool.
We are considering making a new API with .Net Core, but as far as I can tell from the research I have done, there is no equivalent process in the Entity Framework Core tools. The closest thing I can find is to reverse engineer the entire database with Scaffold-DbContext, and then use migrations for all future database changes. We can't scaffold the entire database, because some of the tables have errors, and fixing all those errors is not a viable option for us right now.
I have found that I can supply a list of tables that I want scaffolded with the initial Scaffold-DbContext call, but I'm not sure if migrations can be used in a similar way to the Update Model From Database... tool. Can I use migrations to add tables that already exist in our database? If not, what other options should I be looking at?
Related
We're just starting to move off of a legacy codebase and begin using .net and Entity Framework Core for most of our new software.
We've migrated our database from our old platform to SQL Server, but the data is old and poorly normalised. We cannot undertake a normalisation project all at once because of the potential impact on the (large) existing codebase in the legacy language, so we are adding primary and foreign key definitions to our database as we go, and regenerating our Entity Framework Core model from scratch as more tables become valid for the framework.
I feel like we're missing some important capabilities of Entity Framework Core by doing this, but I don't really know enough about the framework to identify what it is. I know the generated model lacks completeness (my question was prompted because a table with an Identity column did not have the column marked as ValueGeneratedOnAdd(); in fact that table does not appear in the OnModelCreating method at all) but I don't know whether that's an issue with the database or another mistake I'm making.
My question is: what capabilities are there within Entity Framework Core to manage a rapidly-evolving database model? What should I be doing for myself, and what should I be relying on the Scaffold-DBContext command for?
With EF Core, most of the things you will need will be done by Scaffold-DBContext. The only things it doesn't handle right now is DBQuery sets. You will have to manually code those. Other than that, everything else is handled pretty eloquently by the command.
As far as ValueGeneratedOnAdd(), the only time I have ever seen this as a problem has been Versioned tables. If you have a versioned table, Scaffold-DBContext will not add that to those fields and you must have those so you will have to manually add those to your code.
I've currently got an ASP.NET MVC project, with three C# Class Libraries for Data Access, Settings and an Entity Framework Code First project.
I am currently trying to add a SQL Database Project to my solution so that I can manage my database more closely and add extra items that entity framework doesn't deal with.
I have searched around for integration options and can't find anything more helpful than going the DB first route and updating an edmx model from that.
How would I go about integrating my code first entity framework project with my SQL database project in a way that lets me edit the tables with code first and manage stored procedures and the rest with the database project.
If this is possible, is there any particular way to get these to deploy without conflicting?
Thanks!
I understand database migrations might not be the best method to deploy this solution, so any suggestions would be greatly appreciated.
I have x identical database schemas, one per client.
I also have models for each one of these databases and am able to deploy a migration which creates a new clone. Up until this point, I had been using PHP and scripts to loop through all the schemas and update any changes to the structure. We are moving over to C# and EF6 due to Web API 2 and attribute routing.
My question is; Is there a way to:
Deploy a build command which will do what update-database would do for a migration, and pass it a database name (in order to create a new clone schema of the account database?
Deploy a build command which might do what update-database would do recursively through each one of the target databases?
"I have x identical database schemas, one per client "
and
"I also have models for each one of these databases"
Did you mean I also have models for each one of these Schemas?
Ef model entities are linked to a Schema/TableName.
entity.ToTable("tableName", "schemaName");
So if each client gets their own schema, then each model has all tables in that schema and the client gets their own model.
So how do I run update-database on each Context model. I another way of looking at the issue.
So the answer lies with how you are tracking the schema per client info.
Powershell migrate.exe approach might be interest for your so that you can trigger migration on many context models.
Custom migration operations might also be interesting. Rowan is an EF developer.
EDIT: based on Auto Migration comment, this is worth a look
Managing migration triggers in code
I'm following the Entity Framework tutorial on:
Link
I've downloaded the source code, and ran. The project works fine (using the default connection string).
<add name="SchoolContext" connectionString="Data Source=|DataDirectory|School.sdf" providerName="System.Data.SqlServerCe.4.0" />
Next i've changed the connection string to connect to a remote server (which successfully connects). However the tables aren't created and when running the application and accessing the controller I get the following error.
Error:
Model compatibility cannot be checked because the database does not contain
model metadata. Model compatibility can only be checked for databases created
using Code First or Code First Migrations.
My database user is 'dbowner' so I wouldn't imagine it's database access issues.
I'm new to EF, and don't know much about Code First Migrations. Have you come across the above error, and would Code Migrations solve this issue? If so why?
From my reading (please correct me if I am wrong) the scenario here is that you have an existing (perhaps empty) database on a remote server that you wish to put your EF code-first work into.
The error is coming about because, I think, EF is looking for a _MigrationHistory table (metadata about what EF code-first migrations have been run against it etc) and can't find it. There is some reasonable coverage of this table here for some background/interest reading.
So to resolve the issue, I think the steps to take are:
Initialise your database so that it acknowledges the EF code-first stuff
Update the database, rolling forward all your migrations to date
I found some good coverage of how to do this here. This blog also has some good coverage of EF topics in general
PS. I am guessing that your .dsf/SQL Compact Edition database wouldn't have had this problem because EF code-first would have created it for you on first run so it was already acknowledged as being a code-first database.
Here is a link to Entity Framework Power Tools. It is made for creating models by 'Reverse Engineering' your Database on a remote server. You can then easily access this database using EF.
Reverse Engineer Code First - Generates POCO classes, derived DbContext and Code First mapping for an existing database
Both of the initializer methods which I had tried fail when the database already exists:
Database.SetInitializer<Context>(new Initializer());
Database.SetInitializer(new DropCreateDatabaseIfModelChanges<Context>());
However it is possible to force the database to be dropped using:
Database.SetInitializer(new DropCreateDatabaseAlways<Context>());
The following SO post provides the answer to my question:
Setting up a Entity Framework Code First Database on SQL Server 2008
I've tried a combination of the two, and have decided that the best solution is to manually go into SQL Management studio and DROP the database, and re-create it using the initializer as this allows me to Seed the contents of the database.
Database.SetInitializer<Context>(new Initializer());
See here for more information on Seeding the database as it is also quite an unstable processess!
How can I get my database to seed using Entity Framework CodeFirst?
Suppose I have an existing database set up using Entity Framework. Is there a mechanism through which I can safely add or remove entities (or their properties) such that the database is altered automatically?
I know there's an option to "Update Model From Database". Is there an equivalent "Update Database From Model" ? Is there a way to configure Visual Studio to do this automatically?
Entity Framework 4.3 has Code First Migration support.
EF helps you with checking the differences between your code and database and then generates code for you that handles this changes. You can use the NuGet package manager console to enable migrations, add a new migration and run them against your database (or create a sql script).
This blog explains how the Migrations work and this blog shows how you can use it with an existing database
Altering the database schema isn't a straightforward operation (has a column been renamed, or is it new column? Can the old type be converted to the new type?) that you can easily infer from the model.
EF doesn't alter the tables for you - it can Drop-Create the DB for you when you change it. However, if you change the existing database by hand to suit the model, EF doesn't seem to mind. It looks like what they check for is Hash(Model) = Hash(Tables).