Recently I started doubting in all the migration-stuff in MVC frameworks. Why should we use them? Consider a small application (blog or whatever) using an MVC framework. What are the benefits of using migrations? Not-yet-deployed app doesn't need migrations, because no data is in the database, once you've developed it and consider it quite stable you release it to production and than what? I don't think that this kind of application would need so desperately a mechanism to convert your database schema/data to another format, keeping the possibility to revert the changes. This would require much more complicated schema, a simple script would be ok.
But then, with a complicated schema it gets very hard to migrate the data one way, not saying about reverting the migration. You end up with not revertible migration (raises exception on backward migration).Again, wouldn't a script be sufficient?
Also maintaining migrations is very hard. Let's say you have destroyed your database and want to remigrate it (even in test env). Having 100 migration classes all of which preload and all of which where created in different time you are tied to one, latest implementation of each class in your app.
Say ModelA in revision 1 had an no after_save. We used it in our migration, then in revision 2 we added after save to create 2 ModelB's for each ModelA created. Remigrating database from scratch gives you ModelA _with_ after_save because that's your current revision.
So, knowing all this, and having some experience with bigger application and it's migrations, I say that they are quite nasty mechanism and really not needed. You either have an easy app or it's just too complicated to maintain them, you end up with 2-hour-migration-fix knowing that you will probably never use the revert function.
Friday, July 11, 2008
Subscribe to:
Post Comments (Atom)
1 comment(s):
I've actually started to think that something like migrations might be useful, in the context of a document-oriented database.
That is: I agree that it's fairly useless to force every single schema modification to be expressed in migration form.
However, a document-oriented database has the advantage of not forcing a strict schema -- you could leave records ("documents") lying around in the old schema, and update them on demand. You could even provide a transformation -- I think they're called "materializations"? -- the 'map' part of map/reduce, anyway -- to migrate those old records exactly when the new format is needed (even for the equivalent of a select).
I'm just rambling, though.
Post a Comment