DEV Community

Saral Karki
Saral Karki

Posted on

15 5

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

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.

Sentry image

Hands-on debugging session: instrument, monitor, and fix

Join Lazar for a hands-on session where you’ll build it, break it, debug it, and fix it. You’ll set up Sentry, track errors, use Session Replay and Tracing, and leverage some good ol’ AI to find and fix issues fast.

RSVP here →

Top comments (4)

Collapse
 
dmfay profile image
Dian Fay

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 :)

Collapse
 
suprnova32 profile image
Patricio Cano • Edited

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
Collapse
 
saral profile image
Saral Karki

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

Collapse
 
saral profile image
Saral Karki

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

AWS Security LIVE!

Join us for AWS Security LIVE!

Discover the future of cloud security. Tune in live for trends, tips, and solutions from AWS and AWS Partners.

Learn More

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay