I am working on a project using Entity Framework 5 with MVC5. My Project is currently running.
I am trying to add a column in a table. But as we know that in EF when we add a field in model it drop and recreate the database, which i can`t do.
One method for this is found code migration. But my manager is not allow me to use that(because its a big database project).
Please help me and suggest something for it.
When I start using code first with Entity Framework, I was in the same situation as you. I was always running Update-Database -F and then watching all my tables get dropped and recreated, even for something as simple as renaming a field.
Versioning databases is hard, but it's much easier with named migrations (which I think it what you mean when you refer to code migrations). I know your boss is against the idea, but it's very flexible.
Essentially you run Add-Migration -Name xxx in your Package Manager Console and Entity Framework will scaffold a configuration class for you with the default commands (both for versioning Up() and Down()) it will execute when you Update-Database. If you don't like the commands, you can change them. You can even move data around if you need to (it's a bit fiddly though).
I think you have four options available to you;
Use code-first automatic migrations: This is what you have at the moment, and doesn't give you enough control over what happens when you update your database. It's good for getting started in the earlier stages of a project, but becomes unwieldy after production.
Use code-first named migrations: Gives you the control you need via Configurations - but your boss has prevented use from using it.
Use a database-first approach: Database First allows you to reverse engineer a model from an existing database. So if you need to make a change, you would change your database first, and then regenerate your models using EF. This is usually favoured by DBA's, but it may mean that you have reimplement some aspects of your existing project.
Dont use entity framework: It's possible that you could revert back to SQL queries, which your boss might accept and gives you the flexibility you need - but who needs that kind of pain?
Let me know if I can help further.
Related
Hopefully what I'm after is possible at all. I'm currently looking at a way to do what Entity Framework Code First migrations does when you use Package Manager Console in Visual Studio but do it in runtime. The two processes I'm after are Add-Migration and Update-Database.
To explain a bit more, I want to be able to construct custom meta data for the Model and compare that against existing or non-existing database. This should output the same migration file that you get from Add-Migration command in Package Manager console.
After I've got one or more migration files I want to run the Update-Database command again in run-time, programatically to apply Up / Down changes to the database.
The key point is to be able to provide a completely custom (virtual?) model meta data to the Add-Migration procedure, not one based on actual poco classes.
If anyone has done something similar before, I'd appreciate any pointers on where to look as I didn't have much luck with Googling / EF documentation.
EDIT:
To address the WHY: I want my users to be able to define their structures in run-time. They would define the structure as part of a changeset and then be able to apply one or more changesets to the underlying database. Essentially, users would do from web-ui what a developer does from visual studio, except that the classes won't be .cs files but instead a class description in a relational database.
EF seems like a perfect fit to do this because it already does everything I need it to do. I've done schema comparison and run-time change mechanisms in the past. Since EF already does this, I don't want to reinvent the wheel. The migration files that EF Code First outputs are also a perfect fit fro what I'm trying to do.
The reason I haven't yet dug into the EF source is I wanted to check if someone else has attempted this before and if they can share and pointers. Some concrete questions:
What class / method do I need to be able to run schema compare?
How do I hook into that process to supply my own meta-data for "POCO" classes?
What are the options for outputting the detected schema changes (the Up, Down and Seed methods)? Ideally I'd like to compile a change set into a satellite assembly when user chooses to apply changes.
How can one run DbMigration instances in run-time?
I'm after some concrete examples.
We are building this .NET application using Entity Framework as our DB connector. I know all about the stuff of picking the right approach based on your circumstances like "do you have an existing database?", "do you prefer modelling instead of coding". But after some reading I've found that it's not the only thing to think of as the upgrade process of the database when it's already in production is really important, espacially for us.
So which approach is best for production use with Entity Framework. For the moment we have an existing database. I prefer to use the model and update the database from it but then we have lack of functionality in default values of columns and the model can be hard to work with in teams so what we need is basically some best practice here.
For production use: Database First, Model First or Code First?
Someone else might chime in here and tell you to use model migrations with the code first approach. That may be a solution, it's just not my preference.
We manage an in-motion database using EF code first, however I would not be able to do it without one hugely beneficial Visual Studio feature: SQL Schema Compare. I believe this feature is only available in the Premium and Ultimate versions of the product.
Each time our model changes, I put 2 copies of the database schema on my local machine: the new version, and the current production version. If you run Schema Compare using the new version as the source and the production version as the target, it will generate a SQL script that you can run against your production db to bring its schema and data in line with the changes.
The SQL it generates often needs some editing before it can be run in production, but it will do a lot of the hard work for you -- disabling constraints, add / drop indexes, and moving data from an old table into a new version of it. It will also warn you of potential issues when changing the schema.
I have a solution which uses Entity Framework model first approach.
The problem I am facing is that whenever I change something on a table, add a column or change a relationship,I right click and go for "Generate Database from Model", which re-generates ALL the code for the solution even if I just changed one table..and that generated code is useless for a production database since it drops every table and then re creates them..
I am wondering, isnt there be an option just to generate the T-SQL with the changes I made ? Otherwise model first would be useless after your app goes into prod.
I am using entity framework 5.0
Personally, I would suggest you to use Red-Gate SQL Compare when you need to sync your databases at Production environment.
This tool helps you to compare and synchronize databases using sync scripts without losing data (it will alert about if so) and its UI is just awesome.
Could someone explain the concept of Migrators (specifically fluentmigrator)?
Here are the (possibly confused) facts Ive gleaned on the subject:
Is it a way to initially create then maintain updates for a database
by way of versioning.
The first migration (or initial version of the
database) would contain all the tables, relationships and properties
required (done either fluently or using a chunk of sql in a script).
When you want to push a change to a database, you would create a new
migration method (Up and Down), something like add a new table or modify a field.
To deploy one of these migrations, you would use a
command line specifying the dll containing the migration, the
connection string and the required version.
If you had a rather complex set of data models, wouldn't it be rather difficult and time consuming to create a migration definition for all of that?
I know with nHibernate/fluent you can easily generate tables for a database without having to define anything other than the models and map files. Is there a way to make this configuration compatible with the Migrator/Versioning?
When nhibernate/fluent is in charge of generating a database, I do not necessarily need to define every thing aspect of the tables. Its done either via convention or via the mapping files. With the migrators I would need to define this level of detail?
Lots of questions here. I'll answer the questions with a focus on FluentMigrator.
Is it a way to initially create then maintain updates for a database
by way of versioning.
FluentMigrator is a way to version control your database schema. Everyone does it in some way. Either manually, with sql scripts, with a tool like SqlCompare or a Visual Studio Database project. All these methods are easy to mess up. It is so easy to make a mistake when releasing a new version and cause the system to crash. Migrations is a better way to handle this.
FluentMigrator allows you to define a change to the schema as code and this is usually checked in to your source control with the other code changes. Meaning that you can say version 1.XX of your system should have version 123 of the database. It means if you roll back your code to the previous version you also know what version of the database to rollback to as well.
It can be used both to create the database schema from the beginning or to start with version control of the schema for an existing database.
A Migration is a way to describe a change to your database schema. FluentMigrator creates a VersionInfo table and stores the unique id (version number) of the Migration after is has been applied.
For example, if I have two Migrations one with Id 1 and one with Id 2. If then I execute the first Migration then Id 1 will be stored in the VersionInfo table and I can look there and know that the version of the database is 1 and that version 2 has not been applied yet.
Being able to know which version the database schema is very useful when pushing changes from Test to Production or if you have multiple copies of the database in Production. For example, I have a customer with offices all around the world and each office has their own copy of the database and all of them are on different versions. Without knowing the database version it would be very difficult to update them safely.
Most of the time I do not need to actually look in the VersionInfo table, FluentMigrator handles this automatically. It compares the assembly with Migrations to the VersionInfo table and figures out which changes have not been applied yet and then executes those.
The first migration (or initial version of the database) would contain
all the tables, relationships and properties required (done either
fluently or using a chunk of sql in a script).
The starting point is up to you. You can have a first migration that is an sql script that you have generated from the current database. You could could also use one of the contrib projects like FluentMigrator.T4 to generate a Fluent Migration. Or you could just decide that the existing database is the starting point and save a copy of it to be able to restore it as version 1.
I have introduced FluentMigrator to a lot of legacy databases without any major problems.
When you want to push a change to a database, you would create a new
migration method (Up and Down), something like add a new table or
modify a field.
Yes, Up is used to apply the change specified in the Migration and Down rolls it back. So Up could be to create a table and Down could be to drop the table.
To deploy one of these migrations, you would use a command line
specifying the dll containing the migration, the connection string and
the required version.
There are three runners available to execute migrations. The command line runner, the Nant task and the MSBuild task. There are usually executed as part of a build script.
The MigrationRunner class can also be used in code. You might do this if you wanted to build your own runner or if you have other needs (like building databases dynamically or automatically updating the database if a new migration is added.)
If you had a rather complex set of data models, wouldn't it be rather
difficult and time consuming to create a migration definition for all
of that?
I have mostly answered this already. It is usually quite easy to generate an sql script for a database. For Sql Server it takes less than a minute to generate the script even for large databases. This script can be saved in a .sql file and executed as the first migration using the Execute.EmbeddedSqlScript expression. It works a treat.
I know with nHibernate/fluent you can easily generate tables for a
database without having to define anything other than the models and
map files. Is there a way to make this configuration compatible with
the Migrator/Versioning?
At the moment, there is no such integration and in practise I, at least, don't miss it. There was some discussion about connecting Fluent NHibernate and FluentMigrator but it would be a lot of work. It would enable scaffolding to generate changes to the model like EF Code First migrations do. It's not on the roadmap at the moment however.
When nhibernate/fluent is in charge of generating a database, I do not
necessarily need to define every thing aspect of the tables. Its done
either via convention or via the mapping files. With the migrators I
would need to define this level of detail?
Yes, you would need to define at that level of detail. FluentMigrators' migrations are a DSL (own little language) for defining schema changes that are translated to sql. You can write sql directly as well using the Execute.Sql expression. Entity Frameworks migrations have that sort of integration which has both advantages and disadvantages.
Check out the wiki or one of the tutorials here, here (part 1) or here (part 2) for more help getting started.
I'm just starting to dive into ASP.net MVC3. I come from a Django background. One of the things I love about Django, is the add-on called "South". It lets me modify my Models in code, and then I run a command, it figures out what has changed, and it updates the database accordingly.
If I add, remove, or rename a field with the "code-first" approach in EF4, what happens? Does it just add or remove the field, and that's it? What if I want to do something like add a new field, and then perhaps run a Linq-to-SQL query to populate the new field, and then remove the old field? And I want a record of this so that when I go to deploy the change on my production server, it will run those 3 commands in sequence.
Is there something like that? Or how do people tackle situations like this? (It is pretty common...)
Edit: Found some links.
https://softwareengineering.stackexchange.com/questions/76082/is-entity-framework-code-first-a-bit-meaningless-useless-in-production-and-what
http://blogs.msdn.com/b/efdesign/archive/2010/10/22/code-first-database-evolution-aka-migrations.aspx
Using EF4 Code First: How can I change the Model without losing data
Deploying database changes with EF 4.1
https://github.com/dradovic/MigSharp
http://blogs.msdn.com/b/adonet/archive/2011/09/21/code-first-migrations-alpha-3-with-magic-walkthrough-automatic-migrations.aspx (Woo!)
Here's an excellent tutorial from Microsoft MVP David Hayden:
http://www.davidhayden.me/blog/asp.net-mvc-4-and-entity-framework-database-migrations
Not sure about 4.2 - but I installed the latest EF (4.3.1) and it worked like a charm.
Pretty impressive - and I'm a Rails guy :P
What happens depends on your initialisations, i'll discuss the "standards" using the dot net ways.
Take a quick-deep dive into:
Database Initialization Strategy
- Look at the top, here the "DropCreateDatabaseAlways" is used, so it will always drop the Database and recreate it (you have other possabilities). - It says how EF should react on database changes.
Here are the possible Database Initializations
If you want Migrations, there are 2 ways:
- Magic
- No-Magic
What you should know, is that Migrations is actually 1 week old (EF 4.2), it has been implemented in EF 4.1, though not with full support (Different DB, ...), but it's improving.
It depends on how much time you have, but i'm waiting to implement 4.2 and EF Migrations, i'll implement it in a "test-project" on the end of the week, see if everything goes well and respond to the Ado.Net Team Blog (see links on Magic - No-Magic). Although i don't think there will be any problems.
Best of luck on your choice :)