> This is not a problem that I've studied in great detail. However, I > understand that doing it automatically is dangerous and fraught with > peril.
No doubt of that. Automation can't cover everything, and sometimes it's wrong. That said, there's a lot of really simple cases where some automation would be handy - say, adding a new column, existing rows null - and I think it'd be cool if the code for those changes could be generated automatically, as a place to start if nothing else. (I don't imagine folks will be going back and changing old migration scripts very often, so I don't see the code generation causing too many maintenance issues.) There won't be anything that'll interfere with writing things by hand, though. > So, I think the best bet is to not do it automatically. Here's what I'd see: > > 1) a tool to know whether or not a conversion should be applied > 2) a way to express DDL in as database-independent a fashion as possible > 3) a way to express the database-specific portions where #2 can't quite do it > 4) a way to apply the changes in a given environment That all makes sense. I've some ideas on how one might be able to test migration scripts to ensure the script makes the old schema match what would be generated by creating each table from scratch, too. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears -~----------~----~----~----~------~----~------~--~---
