Friday, April 18, 2008

Searching for a better migration

Started scouring the net for a decent project path which will enable me to implement migrations in the middle of a development lifecycle and found that there were some great plugins in the Rails world but none of them suit my purpose in a sufficient way.
So, what was I looking for.
I was looking for
1) A way I could start using Migrations in the project. Which primarily leads me to decide on how migrations could be managed. Working on a large scale product, I thought that using stock migrations would not be helpful. Especially when database changes become decentralized and then we start having problems with migrations not working because their numbers do not match. (Of course one can argue saying that we could have a hook at source control to handle that but remember that is an extra effort). Then of course there is this ever looming problem of migration decay. For the uninitiated, migration decay aptly worded simply means that running migrations of a fresh DB could fail because the lower migrations run into problems as the models have evolved. The earlier migrations expect a different model and boom! Very typical when data migrations are mixed with schema migrations. Intuitively, I thought that it would not be a great idea to have to run a lot of migration files to get the instance to speed.
So, what was my other option that generating migrations for every DB update?
I think the best bet is to use schema.rb
Schema.rb generated when you run a rake task, can contain the entire schema dump.
This was attractive and sweet. So the intention was to have a single source controlled file which makes me feel safe.

Coming soon
2) How to handle foreign keys/views
3) Was there a better way to make life (more) hassle free?

No comments: