Bill Walton wrote: > Hi Tyler, > > Tyler Smart wrote: >> Most of my migrations are by number, not timestamp, but 5 or 6 of them >> (the most recent) are with timestamp. These I want to move to number >> based, and now I want to forward the migration table to the appropriate >> number. How do I force the table to update without actually running the >> migration, or should I migrate down to 5 or 6 ago (before timestamp) and >> then migrate up again with numbers? > > The answer to your question is yes: migrate down, change the names of > the time-stamped migrations to be number based, then migrate back up.
If you're going to do that. But don't do it. > > IME, there are good reasons to avoid time-stamped migrations. Not a one IMHO. > The > chief ones are that they allow lazy communication between members of > the development team and poor habits in terms of update before commit. How so? > If you use number-based migrations you will catch problems at the > rake db:migrate level. Using time-stamped migrations you'll not catch > them until your tests or your users do: a much more time-intensive > debugging circumstance. You are making a false assumption here: that every migration in the codebase eventually gets incorporated into trunk. The advantage of timestamped migrations is that they let developers try migrations out on their development branches that don't necessarily get incorporated into trunk. For example, if trunk is at version 9, and I make changes in my branch that require migrations 10 and 11, but the maintainer only takes migration 11, then he will have to renumber it to 10 before running it, and that's silly. It also destroys any meaning that the migration ID 10 might have had in determining the database schema. Timestamped migrations, on the other hand, effectively give a unique ID to each change to the DB schema, regardless of how many changes come before. This is the superior numbering scheme. > I'm not saying there aren't situations where > time-stamped migrations aren't worth the risk. But the fact that you > have a mix of number-based and time-stamped migrations indicates a > possible communication problem. Or a Rails upgrade. > Anything that reduces the need for > proactive communication between team members should be carefully > considered re: the risks. I'm not sure I agree when it comes to integration issues. Yes, communication is important, but the more the VCS and build system can automate, the better, other things being equal. Serially numbering migrations takes away automatability. Don't do that. > > Just $0.02 from someone with a long history of and current > responsibility for ensuring effective and efficient communication > among the team. > > Best regards, > Bill Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
