EF Code first DropCreateDatabaseIfModelChanges is a very nice feature for development, but what if I want to distributes my application to the customers?
There might be future changes to the database design.
What is the best method to deploy code first application using ClickOnce?
The database I am using is SQLSERVER CE or SQLITE.
Thank you.
When deploying applications to run on a users pc with their own database its useful to upgrade the database instead of just blasting it and starting again (which is easier for us devs).
Fortunately EF provides an upgrade mechanism called migrations. see http://msdn.microsoft.com/en-US/data/jj591621
This is available in EF 4.3+
Related
We are developing a large ASP MVC web application EF6 Code First (100+ entities) and we have some doubts about migrations.
If we enable migrations while we are developing but not yet in production, we are going to end up with tons of migration files, since it is recommendable to do small migrations. Is this a correct approach or we should enable DropCreateIfModelChanges for developing before the app is in any client?
Also, we need to seed the database with common data all the clients using the app are going to need, like countries, states, a few super users...
Where do we have to seed this data so it is always in every client we install the web app?
I have seen a few different approaches:
- Seed data in the Seed function of Migrations Configuration, with a AddOrUpdate command, but I have seen in some places that this is a bad approach.
- Seed data in a Add-Migration using Sql("INSERT INTO....");
Thanks in advance.
I usually start development just using the initializers. There is a seed method specifically for initializers that only runs when the database is created which is ideal for security and lookup tables. (Migration initializers run with every update-database).
When I get to the point where I don't want to lose other data, I switch to migrations. As you mention, these can accumulate so I use Chris's technique to roll them up before deployment.
You should also be aware of the issues working with migrations in a team environment.
I am building an e-commerce application using spree in rails. The application uses PostgreSQL as database. I want it to be changed to MySQL. How do I achieve this?
The short answer is, you don't. I've been through three Spree migrations where we were either using legacy data, or switching databases and trust me; you want nothing to do with this.
If you don't need to take the old data with you, you should be fine just running the migrations on a fresh MySQL database. If you need the legacy data, God be with you...
Converting Spree database schema is nothing nice, and it's hard to just pull what you need out of the database since because almost every data model depends on a foreign key from another. There are dental procedures I would go through voluntarily before attempting what you are proposing. This also begs the question; why do you need to go to MySQL from Postgres?
While reading about the database migration plugin in the book "The Definitive Guide To Grails 2", I came across a question. I understand this plugin is used to migrate an older schema to a newer one that the code base might be expecting to work with. Immediately, the one scenario I could think of why this might be necessary is that a code base expecting to work with a newer schema might try to access properties in domain classes that might not be there (null exceptions). I wanted to know if anyone can help me as to other reasons for migrating the schema so that I can better my thinking on this. Thank you.
The Database Migration Grails plugin is a convenient way to update your database schema. It's not necessarily just to migrate to a completely different schema. The plugin is actually just a wrapper around Liquibase. It aims to integrate the database management into your codebase which makes it easily versioned and tracked with the rest of your code. It also allows for you to easily update your database in a controlled way (dbm-update on start). This works great for continuous deployments.
Perhaps a stupid question, and without code, so I'm not sure I'm on the right StackExchange site. If so, sorry and give me a comment please.
I begin programming in Sinatra (only intranet until now) and in the samples they almost always use migration with activerecord, the same with RoR.
I have experience enough with activerecord itself and it is very helpfull but I'm not sure why migration is always used ? If I create a project I just create a SQL script or a Ruby activerecord script that does the creation of the DB for me and that's it..
If I need the site or script somewhere else I just need to execute that script and ready.
Obviously I'm missing here a lot, so who can me explain the other benefits or point me to a good explanation ?
From Rails docs:
Migrations are a convenient way to alter your database schema over
time in a consistent and easy way. They use a Ruby DSL so that you
don't have to write SQL by hand, allowing your schema and changes to
be database independent.
So, the main two benefits are:
It's like Git for db schema, you won't know how that's useful until you are in a mid-size or big project with many contributors and someone makes a bobo :)
You write ruby code to build your db schema, this way if you decide to move from mysql to pg for example, you don't need to open up pg manual and check code compatibility
Update
In the api docs of migrations, you will find many nice use cases (to be honest i didn't know about half of them) ... check it out (http://api.rubyonrails.org/classes/ActiveRecord/Migration.html)
Building a creation script for your database is great, provided two things:
All your database deployments are on new machines
You get your database schema exactly right the first time
In our modern agile environment we not only don't believe it is possible for a project larger than a few lines of code, we also don't encourage aspiring to it.
Active Record's Migrations offer a way to describe your database incrementally. Each "migration" defines how to add its features to the database ("upgrade"), and how to remove them if necessary ("downgrade").
When running migrations, on top of actually running the scripts, Active Record also maintains its own table (schema_migrations), to remember which migrations have been applied to the database, and which are pending.
This enables you to build your database alongside the features as you develop them. It also facilitates working in teams, since each team member develops her own migrations, and Active Record "stitches" everything together, so you don't have to maintain a monolithic creation script.
I'm switching to RoR from ASP.NET MVC. Yeah, migrations are cool, but I do not need to use different databases in my web applications. Postgresql will do just fine.
So is it okay if I use PGAdmin to create and administer my databases and schema and avoid all these fancy migrate, rake etc?
Update
Thanks everyone! Now I better understand what migrations are, and why I should use them.
I don't think that's what migration means.
Migrations in rails (and in other frameworks) is a method by which you can use to update your database schema when there are multiple versions of the same database running
For example, you may have two databases, one running on your production server, and another running locally for development. After a few days of coding, your local development database may looks a bit different. With migrations, you can simply push your code to the production server and then run the migrations to automatically update your production database so it is up-to-date with the one you use locally for development.
So, to answer your question, Yes it is OK but you might not get a few of the migrations niceties when the time comes that you'll have to maintain multiple versions of your database.
Have to agree with charkit but one (rather two) important note why you should use migrations: Migrations don't make up the model definitions. They are stored seperately in a file schema.rb. This defines the rows and tables of your database. When looking into the file, you find these lines:
This file is auto-generated from the current state of the database. Instead of editing this file, please use the migrations feature of Active Record to incrementally modify your database, and then regenerate this schema definition.
The second reason is for testing: you can easily set up a test database to run all your tests against without the need to touch the "real" database. I know when developing, this is not a big problem but this will get more important after some time.
So, yes, it is possible to use PGAdmin to create all your database related stuff but you should not forget to always keep the schema file up to date and come up with a solution for testing.
With migrations you're able to develop your database schema in Ruby and this is usually database indpendent.
In short, spend the 20 minutes or so to really get migrations and the value they add. Then determine whether or not you want to ditch them. Strangely for me I learned Rails before I started my first MVC project; one of the things I missed most was migrations.
From a technical standpoint you should be fine without them.