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
Related
I was trying to create a rails project with postgresql
I use this
>>rails new ReadingList --database=postgresql
>>rails s
However, it shows this error
Then, I jump to psql and create readinglist_development by myself, but it still show the same error.
In Rails practice, run rake db:create to create the database after creating new Rails project.
I believe the name of the database(readinglist_development) is not matching the database name of ReadingList_development as in database.yml which Rails does not recognize the database created using psql.
Its better not to create databases form db workbenches, better to use rails db commands.
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 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 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