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.
Related
I've removed my migration files thinking that it shouldn't matter since I could load from the schema. However, I'm getting warnings in heroku that it could be destructive.
Is there a safer way to update your db from the schema when your migration files are deleted?
I am just testing the production environment in my laptop. I used the command
RAILS_ENV=production rails console
It somehow drops all tables and recreates them and that too picks up some old schema and does that. Now because of that the latest app doesnt run. Same with unicorn
bundle exec unicorn
Any ideas where is it picking up the schema file from. I have deleted the db/schema files as well. I now only have the migrations.
Not because of anything else but schema.rb file. The preload option in unicorn runs the schema.rb file as well and then we loose the data in the database since in the schema.rb file, it is mentioned force=true. Deleted the file and everything worked fine.
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 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