I am a newbie rails dev coming from .net mvc, we don’t have a concept of db migration as is done in rails. So in going thru this, I can see how this can become messy quickly. How do the more experienced devs handle this? I also have been using nosql db’s a lot and prefer to use them whenever practical. I realize I need to understand this and how sql db’s work in all of this, but I would like some practical advice and perspective if possible?
Thanks
Steve
I can see how this can become messy quickly.
Can you explain what you mean? It’s hard for me to address your concerns without knowing what they are.
Migrations are version control patches for your database schema. Before I was working on Rails, I would often re-invent something similar - generally only operating in the ‘up’ direction - so migrations were a welcomed feature when I came to rails. I’ve seen people complain that the number of migrations in a long-running rails application starts to bother them, but you could always opt to collapse older migrations if you’re confident you’ll never want to undo a given one of those older migrations on its own. That seems more trouble than it’s worth though.
Derek,
Thanks for responding, I was wondering more on this, where I come from we do not have this notion, and as I was hacking thru it, it had ocurred to me that you could screw things up pretty easily. I understand its purpose and agree that its quite useful. But how do things go when the db is up and running, has lots of records, and you can’t blow it away and fix things so easily, or is that part of the challenge from time to time? I also don’t fully grok this yet so my questions come from trying some basic things before I really understand how it works. I do have one client I do work for in .net and having this would have made my life much much easier in dealing with their database issues for sure.
Yes, you must be careful when changing production data. You should become familiar with rake db:migrate and rake db:rollback as a means for testing your migrations to ensure they apply cleanly up and down. Be sure to inspect data if you’re doing anything destructive. And make sure you’re taking db backups in production (and that you can restore those backups).
These issues exist whether you are using rails migrations or developing any other database-backed web application. At some point you will need to change your production schema. I would say Rails Migrations have a way of making people think about both the application and the rollback steps in all database changes.
Thanks, I am doing things now like building, breaking, fixing. I tend to learn best having to fix stuff after i break it. I have some db’s I can play with and hose, so I will run thru some things to see exactly the effect on this. I need to do this to get familiar with postgresql anyway, since it seems to be used quite a bit.