Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Ruby ActiveRecord Basics Migrations and Relationships Migrations

Ron Chan
Ron Chan
10,987 Points
Posted by Ron Chan
Ron Chan
10,987 Points

Difference between Migration and Git

So I was watching Catlin's video on ActiveRecords and it got me wondering if database migration and git are different ways of doing the same thing (i.e. rollback to a previous version of what you written at some point in time).

I guess this question is going out to more experienced programmers around here since I have just learnt some of these stuffs here, I don't always understand why certain things have to be done one way in some situations and another in others.

3 Answers

Pedro Ruíz
Pedro Ruíz
28,105 Points

Everytime you create a migration using scripts (like script/generate model ...) a new migration is added to the correct directory ready to be synched with the real database.

Actually rake db:migrate just checks which missing migrations still need to be applied to the database without caring about the previouse ones.

When you use rails migrations, a table called schema_migrations is automatically created, which keeps track of what migrations have been applied, by storing the version number of each migration (this is the number that prefaces the migration name in the file name, ie db/migrate/20090617111204_migration.rb). When you run rake db:migrate to migrate up, only migrations which have not been run previously (ie. their version is not contained in the table) will be run (for this reason, changing a migration that's already been executed will have no effect when running db:migrate). When migrating down, all versions found in schema_migrations that are greater than the version you are rolling back to will be undone. (Caution: by doing so your data will be lost.)

Also, data entered in the ruby console (if you connect to the database) is writing changes to your local database, you'll later see that you can have a database for development to use for debugging and another one in production which your users will actually be using and writing to.

Ron Chan
Ron Chan
10,987 Points
Ron Chan
Ron Chan
10,987 Points

Thanks for the explanation Pedro, I appreciate it. I hope to understand what is happening in the background as the lessons focus more on the "how" of getting things done and your response does makes things a little clearer. I will have to write down these questions and see if they are clarified after going through the course once more.

Pedro Ruíz
Pedro Ruíz
28,105 Points
Pedro Ruíz
Pedro Ruíz
28,105 Points

Git is used as a version control system, and it "rollbacks" your repository to a previous state. You usually don't keep track of the database using git. When you rollback on a database you are winding the clock on the data that was written onto it from the last backup you made of it.

These are my two cents but am more than willing to chip in with follow-up questions

Ron Chan
Ron Chan
10,987 Points
Ron Chan
Ron Chan
10,987 Points

Thanks for responding Pedro. I may have gone though the course too quickly so I am a little confused about why certain actions were done. I apologize if I am not making myself clear in my question as I am still trying to piece everything together.

In the video, rake db:migrate was done after changes were made in the files under the model folder, such as has_many and belongs_to relationship. These are coding changes to the files, so it seems to me that rake db:migrate does some form of version control as well. So if rake db:migrate is able to keep track of changes made in the files, doesn't that mean it does the same thing as using Git? In other words, rolling back and forth between different versions of the project. Is it the same goal with different tools, maybe Git does some things better that's why programmers are encouraged to learn it?

Additionally, I don't know if data previously stored get erased after every migration. Wouldn't it be messed up especially after major changes in the schema? Data was entered from the ruby console in the video, so I am also wondering if that is permanently saved somewhere or just a test example that will be erased after every migration?