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.
Related
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 am trying to view my Heroku app's schema in Terminal (Mac OS X Lion) and stumbled upon a command that does just that. In Terminal, I run heroku run more db/schema.rb but it seems to display an older schema version. I just migrated the Heroku db and I noticed that none of the new columns are listed.
I can't seem to find anything helpful in Heroku's documentation. Does anyone know a command to view the current database schema for a Heroku app?
By the way, I inherited the code for the app and for some reason all of the migration files are commented out (there are probably 40+ files) so I can't just run rake db:migrate locally to update the schema; hence, I'd like to see the Heroku app's schema directly.
Any suggestions?
You could run heroku pg:psql to fire up a Postgres console, then issue \d to see all tables, and \d tablename to see details for a particular table.
For a rails schema, try:
$ heroku run "bundle exec rake db:schema:dump && cat db/schema.rb"
You can use rateaux:
rake db:view:schema
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.
I have a development database on my computer and a production database on Heroku. I need to run a migration on the production database, to clear certain data, that I don't want to run on the development one. So far I've only been doing migrations that I've wanted to run on both, so I just create it on my computer, run it, then when I upload to Heroku I run it on there too. How can I do a migration only on the production database? Thanks for reading.
Create your migration.
Commit, push, run on heroku with heroku rake db:migrate --app myapp.
Comment out the contents of the up block.
Run the (now-empty) migration locally.
Uncomment or git checkout/reset to get back to normal.
This way both your local db and production db will consider the migration to have been run and not try to run it again.
Migrations are intended to update the structure of your database, not to manipulate data. If you want to manipulate data, you should use the console or a script.
$ heroku console
RAILS_ENV=production rake db:migrate
I transfered a project to a new machine. Everything works. I can run migrations and they update the mysql database. However, the schema.rb file doesn't acknowledge the changes. I checked the read/write permissions for schema.rb are OK. Does anyone have any idea about what could cause this problem. I'm using Rails version 2.3.5. rake:redo rake:rollback don't work because the schema is not aware of the changes in database. running rake db:migrate again does nothing.
The answer was that I had the following line in my development.rb file
config.active_record.schema_format = :sql
After commenting it, everything worked.
I have never encountered this problem but this may solve it:
Take a backup of your current schema.rb cp db/schema.rb db/schema.rb.backup
Delete schema.rb rm db/schema.rb
Run rake db:migrate
This will regenarate your schema.rb file from the current database state.