ncancelliere wrote: > I have observed that in a few projects (for larger enterpriseish type > companies) that folks prefer to use raw SQL in the migrations instead > of methods like add_column or create_table.
I have seen that too. I believe that is due to not understanding the best practices for dealing with migrations. For example, one argument I have seen for writing SQL migrations is that they will be more resistant to future changes in the model object. That's true, but if you're running old migrations, generally something else is wrong (that's what rake db:schema:load is for). > > The con I see in doing this is that your project is less portable, I agree. More than a line or two of SQL in a migration is generally not a great idea, I think. [...] > So then my next though is, if that's the case then why do it? See above. [...] > The one thing I don't see migrations doing are foreign_key constraints > in the database. Then you haven't looked hard enough. :) See http://github.com/harukizaemon/foreign_key_migrations . I use this on all my projects, and at some point I hope to patch it so it also deals with check constraints. > I suppose a lot of Rails developers depend on the > ActiveRecord associations and validations to enforce these? Probably. But the *good* Rails developers know better. :D > > I'm interested in finding out what other folks are doing in terms of > writing migrations. Well, that's what I think... 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 -~----------~----~----~----~------~----~------~--~---
