What to do when changing database on Entity Framework
Hi,
I am using Microsoft Entity Framework with C#. I used a code first method so that entity framework created some magic code for me so that i didnt need to write it. Now, i need to change my database a bit. Need to add columns in the table and so on. How can i do this? Is there any other option that applying code first method again?? I found this solution a little bit cruel so i ask for help. Haven't found anything useful on google so i try here.
Thx
When updating the database using the code first approach, you want to use Migrations.
http://msdn.microsoft.com/en-us/data/JJ591621.aspx
It automatically scans your changes and creates a Migration object for each set of changes.
There is some steps that you need to take, and I think it is better to refer you to the original documentation of it on MSDN:
You can find your solution here:
http://msdn.microsoft.com/en-us/library/jj591621.aspx
look at the parts that talks about Enabling Migrations and Generating & Running Migrations.
Related
I'm trying to set up Entity Framework 6 in my project to facilitate the programming. However, I'm facing some kind of weird trouble.
I tried to follow this tutorial but with my own DB. http://www.aspsnippets.com/Articles/Simple-Entity-Framework-Tutorial-in-ASPNet-Web-Forms-with-example.aspx
As I tried to create an ADO Entity Data Model, everything worked fine and I got my model done. I'm able to see it in the model explorer. However, I'm not getting anything in my "Models" folder, and I cannot add a reference to my model in my using statements.
Which makes me not able to create the kind of functions as described in the tutorial.
Has anyone a clue about how to solve this?
Using EF with Database First or EDMX First will hold you back while learning Entity Framework. The best way to learn it is from the ground up, using Code First. DB or EDMX First only really come into play when you're reverse engineering old databases, and even in these cases, you'd be better to rewrite the database in Code First and phase out the old one.
There is a really good tutorial I've found here: Entity Framework Code First End to End. It teaches best practices, as well as going into detail about how and why it all works. It's one of the best ways you can spend 75 minutes when learning Entity Framework.
Start off small, and build outwards. In EF7, they are phasing out the EDMX, so even when working with Database First, you'll need to know everything about Code First in order to make it all work properly. The scaffolded code generated by Database First is really badly written, and needs refactoring as soon as it lands. You'll be refactoring and adapting the code anyway, so Code First is,in most cases, more straightforward.
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");
}
I have two questions for database handling using Entity Framework. I am using SQL Server 2012/14 web api 2 (VS 2012/13) but it doesn't matter because my question is regarding code first approach for EF6. In code first approach if the table does not exist that EF creates it for you (EF's awesome feature).
1.) Usually when EF creates a table, it uses nvarchar for string datatype but I need to use varchar. How can I specify that in EF? (Also for other datatypes?)
2.) Also I need to create stored procedure using EF (if it does not exist in DB). And also how can I invoke it from EF? Stored Procedure takes input parameter and gives output records.
In case of any change in model or logic, it should be reflected automatically in DB. [Very Important]
Request: Please keep the understanding level of your explanation to be Super Easy. I have just saw some YouTube videos and trying to understand it and implement it on my project. But I don't want to just copy code, I want to understand it so please kindly provide explanation for each line. Multiple solution will be appreciated. (I mean Data Annotation and Fluent API both)
My Last Option: I was thinking of creating script and executing it in "up" function (where migration happens and creates all SQL object) But issue with that approach is that if there is any change in my model, I have to reflect the same changes in that script too as it is hard coded. I am going to use this option when I have no other choice left. I haven't tried this option yet so I might be completely wrong about it.
Thanks in advance.
1) If you want to specify the database type to be used in the actual column of your table, here is the code (using Fluent API) for it:
modelbuilder.Entity<Department>()
.Property(p => p.Name)
.HasColumnType("varchar");
Source: https://msdn.microsoft.com/en-us/data/jj591617#1.10
2) If you want Entity Framework to generate the script that would create your desired stored procedure, have a look at this article: https://msdn.microsoft.com/en-us/data/dn468673. I don't think it would be a good idea to copy the source code from there and paste it over here, so if you have any specific questions, feel free to ask.
If you want to create the stored procedure script yourself and then invoke it using Entity Framework, then have a look at this article: https://msdn.microsoft.com/en-us/data/jj557860. Note: this option tends to have a maintenance cost associated to it. But it is worth doing it if the stored procedure generated by Entity Framework is not as efficient as your version of how the stored procedure should be written as.
Again please feel free to ask any specific questions here.
I'm new to EF Code First approach and got a question.
I've created a sample SQL database using the mentioned approach. It works as expected.
My problem is how to update my tables as the model changes?
I've read and surf the web for that and finally the following solutions figured out:
1. DropCreateDatabaseIfModelChanges
2. DropCreateDatabaseAlways
3. CreateDatabaseIfNotExists
4. Using Enable-Migrations in PM console that unfortunately coped with lots of syntax errors!
I know I need to override the Seed method which could be inherited from DropCreateDatabaseAlways. And I know I have to create objects in this method and add them to the context. BUT... what if my Customer table includes 100 records?
Do I have to fetch them and add them to the context using a loop? I don't know but it seems not reasonable to me!
I appreciate any one could give a good solution. Thanks you
I have to say I personally think the easiest method is to use Migrations. I use the method mentioned here, under the heading "Your First Automatic Migration":
http://weblogs.asp.net/fredriknormen/archive/2012/02/15/using-entity-framework-4-3-database-migration-for-any-project.aspx
(I use EF 5.0 even if the article says 4.3, there is noe difference)
I writing data access layer using ado.net entity. But I want do it by manual (not generate code by tool).
I need help how to do it, how many step and example.
You may want to have a look at Entity Framework Code First. See EF 4.1 Code First Walkthrough