For my past Asp.NET MVC projects I have used the Code First approach to create my web applications.
Here I got a new one, there is an old system with an already created SQL Server Database.
I need to recreate a system for the existing database.
So I have started to use Database First Approach.
I connected to the database and models & datasets generated according to the tables.
So I want to know If I want to add a column to the table which I used earlier, update it on the model, and do migration and update the database.
So I can't use it here, right?
If I want to change something, I have to change it from the database from the SQL server side, and then how I updated it on my project?
Personally, I found their database structure is somewhat wrong for certain cases.
But there are already 5000+ data on the tables and they don't wanna lose it or they have not agreed to maintain two databases for their operations.
Ideas for this matter are highly appreciated.
This is a very common scenario. Microsoft calls it Code First with Existing database. You create scaffolding that builds model out of the database. You probably want to apply constraints and generally improve referential integrity in the database and scaffold the model a few times.
Once you are happy with the model - you stop making changes in the database! You are switching to Code First approach, where you make all the changes in the code, create migrations and apply migrations to the database.
I think, Database First referred to the approach in early versions of Entity Framework that created .edmx file. I don't think this approach is even possible today. Certainly, not recommended
So what I have done here on my end using .net core and above was, that I initially created a migration before applying changes to the entities. Then after that, I removed the code inside the initial migration script. e.g.
public partial class InitialDbCreate : Migration
{
protected override void Up(MigrationBuilder migrationBuilder)
{
}
protected override void Down(MigrationBuilder migrationBuilder)
{
}
}
so that It will not re-create the entities/tables to the existing database, and you'll not have now a problem in applying new changes to your entities.
Related
I'm working on an ASP.NET project. I migrated my database named "youbay" with
reverse engineering. It worked. My database contains tables (picture, user, product...) but when I try to change something on the code and then update my database it with code first other tables are then created named youbay.picture,youbay.user...
What do you concretely mean with RE? Creating ASP.NET Models by guessing the mapped .NET types of the table scheme? Maybe your db-structures are a bit different from the ones EF would genereate itself, so that EF will see a conflict. Or EF keep track of the changes itself, so he isn't touching the tables because he won't recognize that he created them.
Whatever happened, it seems like your way of migrating was not very clean. You should tell EF use an existing database like explained here. This will prevent conflicts and also save work/time, because EF will automatically generate your models based of the database-scheme. So no RE is needed.
I am new to Entity Framework 6 Code First and am trying to perform what I thought would be a simple task. I want to create a SQL View and then have an Entity in my database context that I can use to query the view.
I have tried articles such as this but the key difference in my case is that the SQL View is not an existing view coming from another existing database.
I examined the proposition made in this article but it seems like overkill to me that I would need to create some extension methods to do something as simple as create a view/entity combo and use it in my database context.
Am I missing something? I know it would be much easier if I weren't using Code First but please keep in mind it's Code First and I am trying to create a view, not reuse one from an existing database.
Colin and Kevin, Thank you for the link to your answer on the other post and your concise answer. I have used several resources to finally create a queryable entity based on a new SQL view. Just in case anyone else is new to EF 6.0 Code First and is just getting their feet wet, I do have a few steps that will hopefully benefit others in the future.
It may seem obvious to more seasoned Entity Framework developers, but in order to execute the 'Migration' approach you need to disable automatic migrations and actually dive into the guts of the Code First Migrations inner workings. Since automatic migrations is turned on out of the box, I had already created a fairly complex database with seed scripts all relying on automatic migrations and rebuilding the database on every run of my application. This post helped me wipe my migrations history and get to square 1 with automatic migrations turned off (I went with the web.config approach in case you were wondering)
After I had cleared my migrations information, I deleted the mdf from within solution explorer. That guaranteed that I wouldn't run into any problems when running Update-Database (further down the list of steps).
In the Package Manger console, I then executed Add-Migration Initial to generate an "Initial" migration. The result of this was the editable Up and Down methods as described in Colin's answer. I then followed the steps in Colin's answer by commenting out the table create statement (Entity Framework tries to create a table but we really want to create a view and map it to the Entity) and inserting my own view create sql statement at the end of the Up method. It's important to put the create statement after the creation of any tables that it may depend on. I also performed my Seed activities in the Configuration.Seed method instead of in my Context's Seed method. I see how this would be important if you were dealing with multiple migrations. Finally, as Colin suggested I added the table mapping to my context's OnModelCreating event.
The final step in this was to actually apply the migration to the database. In order to do that, in the Package Manager console you execute the Update-Database command. That statement will rebuild the database with the "Initial" migration you created and edited in earlier steps.
It still surprises me that I need to do all of this custom work to create a view and map it to an entity with Code First, but at the end of the day it was helpful in getting me started on migrations as you can only rely on the "automatic migrations" for so long anyways.
You can manually add the sql to create the view to a migration then consume it as per your first link.
The answer in the link provided by Colin does the job.
In case there are lots of views to be created, it can be a good idea to save the view queries in separate files and add them in a resource (.resx) file instead of hard-coding the sql queries in the Migration Up() method.
For e.g.
public override void Up()
{
Sql("ResourceFileName.ResourceName");
}
instead of hard coding like
{
Sql("EXEC ('CREATE View [dbo].[ClientStatistics] AS --etc");
}
As you're about to learn, I'm inexperienced with building applications using ASP.NET MVC, I'm deliberately coming out of my comfort zone in order to learn.
I'm using code-first migrations with Entity Framework, and I created a Train.cs model and used the Enable-Migrations command. For some reason I thought it would be a good idea to enable automatic migrations in Migrations/Configuration.cs and I continued developing with automatic migrations enabled for a while.
Then I read somewhere that automatic migrations are generally a bad thing, so I disabled them. My Train model needed a new field called Description, so I added it. I ran Add-Migration AddDescriptionToTrains, then did Update-Database. It's throwing me back this error:
Cannot find the object "dbo.Trains" because it does not exist or you do not have permissions.
I think this is happening because I deleted the mdf file that was under App_Data in order to wipe out my database and start fresh, and it doesn't have a migration to create the Trains table before it tried to add a Description field to it.
Basically my question is, can I delete all of my migrations down to InitialCreate, and then just generate one from my model? I only have one model so it should only create one migration. I just want to create the migration from the entire model, not what it thinks has changed in the model.
In short, yes you can. In my experience, anytime you can delete the content of the _MigrationsHistory table and restart generating migrations.
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.
We're in the process of converting a 15-year-old application into C#/Entity Framework Code First.
I've been able to create a migration for the table structures that I'll need, and I'd like to fill them with the data from our old application. Of course, it's possible to simply create a script using Management Studio, but I'd like to leverage Code First if possible.
I see that it's possible to reverse engineer a database schema. Is there a simple way that I could generate a migration or Seed method from existing data in a database? I'm not too worried about performance - it's enough data to be a pain to recreate by hand, but neither are we talking about thousands of rows.
Entity Framework itself should not be used for mass insertion/deletion/updating of records since the performance is really poor. If you want the seeding to be part of your migrations then you could include your SqlCommands inside your Seed method:
protected override void Seed(Context context)
{
context.Database.ExecuteSqlCommand("Command Here");
}
base.Seed(context);