I am curious about the implications of Rails migrations here. It seems that migrations give you a pretty good level of softness in your data models when you need it. Of course, I think a lot of Rails apps do end up with much of their logic in the M part of MVC. And understandably, some folks are not very comfortable with that.
Can anyone speak from experience on this? Talking about mature Rails apps now. Are Rails migrations a help or hindrance in terms of 'app aging'?
In a number of the apps we've worked on, we've found that migrations are no longer useful in order to build a database from scratch (say, you're getting a new employee started and are setting up his development rig).
Mainly because the actual Model code changes so much in between someone running the "rails" command and the "mature app" stage - the validation logic and callbacks being the main culprit.
Eventually, it's easier to bootstrap the schema from schema.rb (rake db:schema:load IIRC) than it is to maintain migrations from a zero state.
Then you've just got to make sure you keep up with the deltas :)
In rails the database is mostly a storage space for freeze-dried model objects. Your typical enterprise RDBMS woes don't apply.
Migrations just make sure that the database scheme is consistent with your actual model. As far as writing Rails applications is concerned the actual technology used to persist objects is (mostly) abstracted away from the task of application design and development.
Can anyone speak from experience on this? Talking about mature Rails apps now. Are Rails migrations a help or hindrance in terms of 'app aging'?