Dropping the working database (NO! NO! NO!)

saral profile image Saral Karki ・2 min read

Today was supposed to the final day for my first project using rails. I had implemented the post page, user authentication and markdown feature for the blog. I had one thing that I felt I needed to do, add a user edit feature. For this. for some reason, I chose to use the devise gem. I thought it would be a good practice working with this gem. So far, I had been working with bcrypt. Since,devise came with all the users related features, I thought about giving it a try.

I made a separate branch on my git repo so that I could work on this feature. At least I thought I had this process nailed down. Working on a different branch would make my working code safe. I did know that regardless of what branch I worked on the database would be shared. However, I decided to delete my users database, and start fresh with devise. This was a big, big error on my part.

I started building the entire user feature using devise. This was a straight forward approach I thought. But, then disaster struck, I started receiving all sort of errors. It was then, I realised, I should have created a separate database for my users and I could have named it anything else. However, my inability to come up with a database name meant that I dropped my working model. I now wanted to go back to using bcrypt, and at least my app would be working. I could then deploy it to heroku as planned.

Instead of adding a feature, I was, therefore, working to fix the howler I had made. In the end, though, I was able to fix it, and have the app working on heroku.

I will implement the app again using devise, but this time, with the experience that I can create a new model and not touch my working database.

Posted on by:

saral profile

Saral Karki


Learning to code, and coding to learn I have a sorta definite plan as to what I want to do, but I am also figuring things out as I go along.


markdown guide

It's a rite of passage. Welcome! And next time use a migration framework (I like sqitch)so you can reconstitute databases when and where you want them :)


Rails already has its own migration framework, which devise uses to set up the database changes needed for it to work.

I guess what Saral did wrong is not that he forgot to use migrations, but rather, to make a backup of the database.

If you are using PostgreSQL (which I recommend, it is way better than MySQL), you can use this command to create a copy of your DB:

createdb -T development_db development_db_copy

And when you want to restore your working copy to the backup, this one liner will drop the current one, create it from your backup and run rails db:migrate to bring everything up to date:

dropdb development_db && createdb -T development_db_copy development_db && bin/rails db:migrate

Yeap. I think this definitely does address my issue and how I could have worked around it. Will give it a go next time I am working with my database.

Thank you Patricio. :D


Thanks. :) I will definitely look into sqitch and learn to use them.