Actually, migrations on DM differs a little bit from AR. At development environment, always uses db:automigrate. On production, uses db:autoupgrade. And when you need to change a column name add a migration to it. But, migrations on DM aren't supposed to last long. The migration is there only to apply things that autoupgrade can't. You actually never rollback on production, right? Actualy, you shouldn't.
Please, watch the video from Yehuda's keynote on MerbCamp about DataMapper to get into it. http://merbcamp.com/video Arthur Zapparoli http://merb-br.org http://arthurgeek.net On Wed, Nov 26, 2008 at 9:45 AM, baaz <[EMAIL PROTECTED]> wrote: > > Hi merbers/merbists, > > Learning about migrations through doing, I created a migration that > adds a name field to the users table. I also added a property to the > model class and then I realized that I am violating the good old DRY > and in a very bad way. (I use DataMapper for ORM) > > One way to prevent repeating myself is not using migrations. However, > I suppose migrations have their role in a production env. since the > db:automigrate task drops tables first and db:autoupgrade can not > alter table columns. I now realize making db:autoupgrade work might be > the solution for this problem but I am very interested to hear your > thoughts. Is there another way? Maybe there is a way around the update > problem in prod. env.-s and so migrations are simply not needed? > > Thank you, > Balint > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" 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/merb?hl=en -~----------~----~----~----~------~----~------~--~---
