From Microsoft documentation:
https://learn.microsoft.com/en-us/ef/core/get-started/aspnetcore/existing-db
When trying to reverse engineer your models and dbcontext from an existing database, you can run a command like this:
Scaffold-DbContext "Server=myserver; Database=mydatabase; Integrated Security=True;" Microsoft.EntityFrameworkCore.SqlServer -OutputDir Entities -Tables FirstTable, SecondTable
This will create me two models and a dbcontext based on my connection details.
If I want to come back later and add another few tables, is it possible to run the same command, or something similar with different parameters that will not create the dbcontext again, as I already have this from my initial scaffold.
Currently we are running the command over and over again and deleting the context each time, or manually building any new models based on the database tables. It seems counter productive.
In Entity Framework 6 and below we would just maintain the edmx diagram but obviously this is not included in EfCore.
It's logged as a request with the EF Core team, but has been pending for a good while now.
Github link
In EFCore, there really isn't support for database first design. The scaffolding feature is only meant to be a one-time operation to build your code first models/contexts so that you don't have to hand code them in order to get started using EF. Once run the first time, you should be moving to EF Migrations instead of scaffolding to deal with additions/updates/deletes to the schema.
Here is MS documentation for migrations: https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/
You can just re-generate the files again, all the generated classes are partial, and you can implement any customizations in parrallel partial classes.
EF Core Power Tools allows you to just generate the POCO classes or just the DbContext.
Related
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?
I created a database by my classes in code-first model of Entity Framework. I am using the migrations for updating database from my model classes.
Now how do change database and update my classes?
I am not sure if i understand correctly but it seems that you should read more about EF migrations. You should never mix CodeFirst and DatabaseFirst approach.
If you are already using EF Migrations you should be aware of the multiple commands that you can run from the Package Manager Console, e.g. Enable-Migrations.
To migrate, you basically use the Update-Database command.
Read more aboput the topic here: https://msdn.microsoft.com/en-us/data/jj591621.aspx
Trying to grasp the big picture here. This is a Web Forms project using Identity + EF for user management. The default project contains IdentityModels file which suggests that I should add custom properties to ApplicationUser class and then use migrations to update my database. I did that and the database was generated/updated. So far so good.
Now I add a new EDMX to my project and import all my DB tables into it. This obviously brings in Identity tables into the diagram as well, which is good because I'll be adding my business domain tables and linking them to Identity tables through the model and then use migrations to update my database. Here are the questions and problems I face:
Am I using Code-First or Model-First, or a mix of both (Does such a mix work)?
Do I have more than one model in my project, namely the default Models file and the one generated by EDMX?
If I have two models, which of the model classes correspond to AspnetUsers table; the default ApplicationUser class or the AspNetUser class generated by the EDMX? I mean which of these classes will be used by migrations to update my table's structure?
Adding new properties to my ApplicationUser class doesn't seem to have any effect when I run Add-Migration and Update-database commands. It generates empty Up() and Down() functions.
Adding a new property to an EDMX entity and then trying to send it to the database through migrations throws error saying that the new property doesn't have a mapping column. Now that's obvious I know, but then how does Model-First approach send changes to the DB?
I know these are more than one questions, but they are tightly related and anyone trying to get a start will most probably face all of them, so I've gathered them in one place for future readers.
In my understanding using both EF Code-First and Model-First can add a burden of keeping them in sync. You may want to check the following sample project which uses only DbFirst approach:
https://github.com/kriasoft/AspNet-Server-Template
OK. After working with the project for a few days, I have figured out a few things that might be helpful for future readers:
As #Konstantin said, as a general rule, you should not use both code-first and model-first approaches in the same project. Personally I prefer database-first over both of them, i.e. create a database design and then import it into my EDMX model. I can then make changes to my DB design later and use "Update Model from Database..." command to refresh my model.
AFAIK, migrations cannot currently be used with EDMX models. These only work with code-first approach.
ASP.NET Identity will automatically create all required tables in your database when your website runs for the first time. You simply need to correct the connection string in your web.config file.
You should generally avoid bringing in Identity tables into your EDMX, but if you really need to do that, do not make changes to these entities through EDMX. Simply use ApplicationUser class in IdentityModels file to add custom properties to your user class.
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 testing with EF 4.3 (beta)
I have some new classes which should generate db tables and columns.
From a old project i have some old tables in my schema, which i want to access via EF.
All Classes are declared. For accessing the old table, there is a poco which is mapped.
The db migrations tries to create that old table, too.
How can it set that this class/table is not part of the migration, but part of the ef model?
xxx.OnModelCreating()
{
modelBuilder.Ignore<myOldTableClass>();
}
removes the entire class from model. finally i can't use it for access via dbContext.
i like to use automatic migrations.
i try to avoid to migrate old db tables completely to EF classes. (Yes, i know there are generators for that)
there are 120 tables, which are still used by an old applications.
some new tables which are only used with EF (new app).
there are 3 common used tables.
those should not created but accessed via ef.
With EF 4.3.1 released there is built in support for this scenario. When adding classes that are mapped to existing tables in the database, use the -IgnoreChanges switch to Add-Migration.
This will generate an empty migration, with an updated meta-data signature that contains the newly added classes.
Usually this is done when starting using EF Migrations, hence the "InitialMigration" name:
Add-Migration InitialMigration –IgnoreChanges
The correct workflow in this case is creating first migration prior to adding changes (new classes), than adding new classes and after that creating new migration where you will have only new tables.
If you didn't use migrations so far the framework will generate migrations for all tables you have in the project because it believes you are creating initial migration. Once you have migration generated you can modify its source file and remove CreateTable code for old classes from Up method. The problem is you will probably have to do this in any subsequent migration.
Edit: I wrote a walkthrough for adding migrations to existing project with EF 4.3.1