Have people run into issues using db:migrate where you have gone back to using MySQL dumps or DDL? We are a first time Rails development team and are trying to decide if we should use db:migrate in production. What are people''s opinion''s and experience with using db:migrate in production environments? --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> Have people run into issues using db:migrate where you have gone back > to using MySQL dumps or DDL? We are a first time Rails development > team and are trying to decide if we should use db:migrate in > production. What are people''s opinion''s and experience with using > db:migrate in production environments?Absolutely use migrations from day one. I use the mysql console for 1 thing: creating the database. Everything after that is done via migrations. I will periodically dump production and load it into development, so I''m developing on a semi-current set of data, but I never ever ever touch the production database directly. Seriously. Use migrations. They are a Good Thing and will make your life much easier in the long run. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I use MySQL dumps for backups, and I''d never leave migrations. It was a bit of a learning curve to get the team used to the idea, and I seemed to be always going back to the API to get the few options stuck in my thick head, but now that I''ve made the switch, I''ll never go back. If it were just an alternative way to load data definitions, that would be one thing. But it''s also: 1) easier to see the evolution of the data structure without checking out different versions of a single file 2) a whole lot easier to see-saw when debugging model issues (I just rake db:migrate VERSION=12; rake db:migrate whenever I''ve got a problem with the data/models in version 13, say.) 3) quicker to make database changes 4) easier to manage differences between databases (I use PostgreSQL, MySQL, and SQLite for different projects, and the data requirements between these are a lot simpler to manage in migrations than dumps or DDLs.) I''ve heard that all those migrations get unwieldy after a while. I can see their point. I''ve dealt with projects with 50 and 60 migrations. But, that''s easy to fix. Just take a current db/ schema.rb file and convert it into a migration (create a class and up and down methods). Then, you can replace those 50 or 60 migrations with one migration file. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---