Recently I had an issue where my db scheme change wasn't being reflected on Heroku PG. I double checked to see that both migration and seed succeeded. What was even weirder was that the db scheme change worked fine on a staging heroku deployment (after the exact same migration/seed). After some searching around, I learned that you are supposed to restart heroku after migrations via:
heroku restart --app=app_name
I've never had to do this (I'm not exactly a veteran, but I've run a good amount of migrations before and have never had to restart heroku for this particular reason).
Do I actually need to be restarting heroku after each migration? Or is this more of a case by case thing?
If you make changes to your DB via migrations then you will need to restart the application on Heroku. When Rails starts in production mode it caches the DB schema. Migrations run in one off processes which the running web process is not aware of. So for it to pick up the changes you need to restart at least your web processes. If your application was idling when you deployed and you ran the migrations it would pick up the new schema as the app started.
You need to get your app to pick up the new migration. Restarting the app works just fine. Or you can clear the schema cache:
heroku run rake db:schema:cache:clear --app=app_name
It depends i guess. Speaking generally, the answer is NO. If you restart your app locally after every migration, then it is needed else i don't think it is required .
Related
I'm new to rails, and I accidentally ran rails db:rollback command in a development.
Next I did rails db:migrate:up VERSION=XXXX to change status of the file I rolled back from down to up.
The migration file was about images. However my images were gone in a development mode due to rollback, files status the same as before I ran rails db:rollback.
In this case, if I pushed this to remote repository, and it's merged in production, the images already there will be gone as well as mine in development?
When add_column method in migration is run you just add column in migration so it will run for production & development environment. Now you added images through localhost to your application and stored in database. So those will be stored to database regardless migration.
Rollback will remove column running remove_column so it will hamper your development as removing column will make you loose all data inside column of table. So on production it does not deal same.
Images are getting pushed to production database or remote repository, it is just to add or remove column only so rollback will affect only your local/development
Unless you're doing something wacky in your migrations, any goofs like this you make to your development database will not effect production. That's why dev and prod databases are separate.
The general problem of "is it safe to push to production" can be mitigated by adding a staging server which runs in the production Rails environment, but is used for additional manual testing of new features. Once everything checks out in staging then push to production. Many services provide a "pipeline" to do this for you, for example Heroku Pipelines.
My app runs properly locally and has a crash when it runs on Heroku. The app does fine until I run a new_post_path call. I tried git push to see if a change to the new.html.erb file or the _form.html.erb file was the issue - but I think during the last push to heroku - my database may have taken a hit. At the time I was adding a t.text field (longtext) and it seems to be the issue.
So I wanted to roll back or totally re-start at heroku. But I have not found anyway to do it. Since this is not near production yet. Is there anyway to just create a new instance at heroku and push up to it?
Again, local version runs perfect. Thanks in advance for any ideas.
I would say there are several ways to handle this problem
restarting heroku
Run $ heroku restart in the rails dir. Sometimes I believe in magic.
debugging
Use $ heroku log to debug what is causing the error.
migrate database
Perhaps you made a database change in local rails, while heroku rails didn't.
Run heroku run rake db:migrate
drop database and remigrate database
See this thread. Sometimes old migration might be in conflict with current migration. Do a clean migration, if the data in your database isn't important.
recreate heroku instance
run $ heroku apps:destroy –app appname and replace appname with your appname. Then delete the current heroku remote repository location from git. git remote rm heroku. Then recreate heroku. run $ heroku create. go through pushing your code and migrating database like usual.
Relaunching might be the least of your problems, so I suggest a few things:
Review this Heroku article on releases, including the Heroku rollback feature.
Add the PG Backups add-on to your app.
I also recommend using something like the exception_notification gem in combination with the SendGrid add-on, so that you can get an email with details on the error as well.
I have successfully managed to set up a VPS production server (Ubuntu 10.04 LTS) from the excellent Railscasts episode. It's an "internal" server (not live yet), so I've been building my app locally and doing a cap deploy at regular intervals to check that things are running smoothly.
However, what I'd like to do now is delete all records on the production server (as I've just been testing stuff) - that is, to start with a completely empty database for when the site actually goes live to the public.
Obviously, I can do this locally by running something like rake db:reset, but how do I do this on the production server? Should I be adding some code to my deploy.rb file?
I'm a bit of a noob at this, but I've been unable to find anything via a Google search.
** EDIT ** Oh, and obviously this is a one-off - once things go live, I'll remove any code which deletes records!
You can ssh into the server and run any rake command from the application directory. You could create a Capistrano task just to run this one rake task, but since this task is obscenely dangerous with any real system I would not recommend it. The last thing you would want is to accidentally run it.
I've been having problems yesterday with Heroku shared Postgres DB. It looks like my db is not correctly 'pushed' to my heroku DB.
Configuration
Using 'pg' gem for both development and production environments.
Using Heroku's 'shared-database' add-on.
Running Rails 3.1.1.
What I'm trying to do
Push my source code to Heroku and then synchronize my postgres DB with Heroku's one. No problem for the source itself, but I can't get my DB up and running.
What I've tried so far
1: Source code push : git push heroku master. OK. This works.
2: Then I try to run : heroku db:push. Seems to be running normally, no error, the schema is sent to Heroku, the different tables are correctly detected and seem to be sent as well :
3: Let's check it out, is everything allright ? heroku info :
Doh ! The database is still empty (and therefore I get DB-related errors when accessing dynamic pages). Can't understand what's happening, I've spent time on this issue yesterday evening but only been mpessing with Heroku for a little while and never encountered this issue. Any clues ?
I'm not convinced that the Database size figure is a live figure. Here's a clean deployment of an app to Heroku and the output of heroku info at each stage. The first run is post application creation, the second after a push of the code, the third after a heroku db:push.
The database was uploaded before the third output and the application is running however the DB:size is not reporting the figure.
Is your application actually erroring because the database isn't present?
The problem is in the commit process.
You should run manually after each commit from your console :
heroku run rake db:migrate
Enjoy
daniel
I've setup my app to run on Heroku with a staging and production environment as according to their documents. http://devcenter.heroku.com/articles/multiple-environments
It seems pretty straightforward to manage with the staging app, push entire deployments or new branches up to test in staging. What I wonder is how to manage the production version.
How do I keep my production up and running when deploying new code? Do I pull in the changes from staging or do I redeploy the entire app with the changes merged in?
Secondly, how do I manage and keep my database intact during all of this? I'm used to running locally where if you do a new deploy and a new rake :db:migrate, you lose all your database data. How is this done in production to not lose your records?
Thanks you and ANY other tips regarding heroku management is welcome.
Typically, you make changes locally, including migrations or whatever. Before pushing your changes to your production app, push changes to your staging app to double-check things are okay.
If you added migrations in your changes, be sure to run heroku run rake db:migrate to migrate your staging database. Running rake db:migrate should not destroy any data so long as your migration is proper - i.e. no weird tampering with data, just the standard addition/renaming/etc. of columns or introducing new tables. (Obviously if you drop a table in a migration it'll be gone.)
Then, if everything is okay with your staging app, push changes to your production, and again run heroku run rake db:migrate if you had any new migrations. If things are not okay, run heroku help to get a list of commands you can use - particularly ones with regard to releases so you can revert back to a previous release. Also heroku logs is really useful, and heroku console (actual command might be slightly different), though when you start a console, be really careful not to tamper with data too much.
With Heroku, there's no deploy command needed - right when you git push, your updated code is there. No "cap deploy" with capistrano, if you've used that before.
Hope this helps.