I'm inclined to agree with Ian on this. I've had very bad experiences with the Rails version of schema migrations, and having to restore db backups, then try them over and over when screw-ups happen (which ALTER statements always seem to cause when attempted in a cross-db way).
Despite how many people are using Rails schema migrations, its not perfect, and when it dies, it dies in a horrid way that leaves you unable to upgrade the db schema. This is typically due to a fault in the webapp as lots of Rails webapp code is aimed at Mysql, so using Postgres almost guarantees a screw-up (and I use Postgres extensively). Since its possible (and perhaps likely in some cases) that the tables can have something impacting them that leaves the script unable to migrate using ALTER properly, structuring the updates as 'insert INTO' syntax as Ian suggests would make it much easier to manually apply any changes should the automatic ones fail. Ideally the migration script should be easily readable so a DBA or someone could troubleshoot a failed migration if need be. - Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
