I have a Rails app that mounts 3 engines. Each engines has their own db migrations with timestamp in the naming of the migration dating back in 2010xxxxxx-migration-name.rb. After i run bundle exec rake railties:install:migrations, all migrations are copied to my app db/migrate but the timestamp of migrations are not respected, they are all re-named to 2011xxxx-migration-name.rb. Any idea?
The migrations are automatically renamed to cause them to not conflict with the migrations in your application. They will all be grouped together in one cohesive series of migrations rather than split out through your application.
We ran into this problem today while upgrading an old rails app that uses a pre rails 3.1 engine. That engine used the old engine plugin from lazyatom.
This engines plugin brings it's own migrator class and did not copied migration files into the apps db/migrate folder.
If one now uses the rake task to install the plugin files into the app, the timestamp gets updated and rake db:migrate tries to run all old migrations again.
Easy fix:
Copy all old migrations via rsync into the db/migrate folder without using the rake task:
rsync -ruv FULL_ENGINE_PATH/db/migrate RAILS_APP_PATH/db
For all engine developers that came from pre rails 3.1 times:
We added an upgrade rake task into our engine to handle this. So our users can easily run:
rake alchemy:upgrade
I had the same issue, took way too long to figure it out:
If a previous migration's timestamp is bigger than current timestamp, new migrations will not use timestamps.
In our case, this was caused by someone who created a migration manually without using the generator
Related
How do I undo bundle exec rake db:setup?
I ran it in the wrong rails app. I ran it in the blogger when I should have ran it in the blogger_advanced app.
You can do rake db:drop
.
It will drop all tables (thats any tables created by setup, any migrations run by setup and any seeds created by setup)
You may use rake db:rollback and it'll rollback migrations one by one, but if yours apps have same named models (User for example) it'll be lost. So you need to dump this tables first and recreate them later using database administrator tool.
And also it'll broke your schema_migrations table and you'll need to refill it by hands from your migration file names.
So if there is not much useful info, it's better to use #Alexphys approach.
Is there any way to take a running database and generate a migration file from it? If not does anyone have any advice on how to approach that?
Background: Have a new project where a PHP developer jumped into a rails project and starting adding tables and columns though PostGres admin tool.
Created a directory called "log" then ran this command
RAILS_ENV=production rake db:schema:dump
I deployed a new feature to Engine Yard that had migrations. Of course I passed the migration flag and it worked successfully. But then I decided to take the feature out.
Note: These migrations removed some columns
I then rolled back on github and deployed again, but now I'm getting a postgres error that a column doesn't exist (this is a column removed in the migration from before)
How do you rollback migrations on Engine Yard?
TMP,
While there is a rollback command built into the engineyard gem, it would be better to just deploy with a new migration that effectively adds the columns back in or update the code to not use the missing columns.
Evan
I've discovered that when you ssh into your engineyard app you can go to the current deploy's directory and run bundle exec rake ... thus you can run probably run bundle exec rake db:rollback
I started building my app in PHP but was convinced by some developer friends to change to RoR instead. Since I already had my database structure designed and created in mysql, I never used any rails migrations to create tables; I just created the appropriate models to match the existing database schema.
So, now I am at the point where I want to test deployment and, of course, I have no migrations to rake to recreate the db on, for example, Heroku.
I know that I can simply go back and recreate the database by creating migrations but my app has dozens of tables with hundreds of fields in total.
Is there any way to create a set of migrations based on my existing db schema, or will I just have to knuckle under and build the migrations one by one to recreate the structure via rails' migrations.
Actually, there are some rake tasks to do the work:
rake db:schema:dump # Create a db/schema.rb file that can be portably used against any DB supported by AR
rake db:schema:load # Load a schema.rb file into the database
You can run: heroku run rake db:schema:load.
I'm a newbie in Rails and I'm trying to deploy my first project.
I'm using rails 3, ruby 1.8.7, Passanger, Mysql and Git
I followed a lot of tutorials to learn about deploying with capistrano and there is a question that i can't figure out.
In the tutorials they never talk about schema.rb
If this file is the responsible for the migrations that i already done and when we deploy the application, capistrano copy all files to the "current" folder (schema.rb to), how can it do the right migrations on production server. Should i tell capistrano to make a simlink to the right schema.rb file for the "current" folder? if yes how can i do that?
Tnks.
The schema.rb file contains the database definition. It is not responsible for any migration.
The migrations are contained in the db/migrations folder. When you deploy a new release and ask Capistrano to migrate the current database, Capistrano invokes rake db:migrate. The migrate task doesn't rely on the schema.rb. It connects to the database, reads the list of executed migrations from the schema table and execute all the files in the db/migrations for which a record doesn't exist in that table.
The schema.rb file is only used when you invoke rake db:schema:load or when you bootstrap Rails. In the latter case, Rails will use the schema to prevent inspecting the database structure every time you access a Model.
That said, the schema.rb file must be versioned in your SCM and you have to include it during deployment. You don't need to do anything special. Capistrano checkout the file from your SCM like all the other files, unless you ignored it.