> I'm against auto migrations as there really isn't a way to do things > properly. Let's say you have this schema: > > CREATE TABLE items ( > id INTEGER PRIMARY KEY, > number_of_items INTEGER > ); > > And you want to migrate it to this schema: > > CREATE TABLE items ( > id INTEGER PRIMARY KEY, > num_items INTEGER > ); > > There is no possible way for an automigrator to know to do a column > rename instead of a drop column and add column.
I'm fine with an external extension, makes sense. But just some food for thought: Automatically, stuff like the above is problematic, but that's easily solved with: column :num_items, Integer, :was => :number_of_items So if :was, rename column In practice, we never run into that in reality. You may iterate on your data structure names in DEV, but by the time you're anywhere close to QA/PROD, you have so many views/other models/admin screens/ etc dependent on column names that changing them is rarely worth it. Also, if you're publishing an API (like we do), changing columns == changing your API and that's just not possible (esp in the Web 2.0 scape where others you've never heard of are mashing up your feeds). We use auto-migrations all the way thru PROD and we find the workflow is actually WAY better and more reliable than ordered migrations. Ordered migrations have their own set of problems - there's no unified info for a given table after a few iterations, so mistakes become more and more probable over time. -Nate --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sequel-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/sequel-talk?hl=en -~----------~----~----~----~------~----~------~--~---
