On Sat, Sep 29, 2012 at 1:14 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Fri, Sep 28, 2012 at 8:58 AM, Chris Angelico <ros...@gmail.com> wrote: >> Yes, MySQL has definitely improved. There was a time when its >> unreliability applied to all your data too, but now you can just click >> in InnoDB and have mostly-real transaction support etc. But there's >> still a lot of work that by requirement happens outside of >> transactions - MySQL doesn't let you roll back DDL, for instance. > > Neither does Oracle, for that matter. I don't really see any reason > why DDL *should* be transactional in nature. If your web app is > issuing DDL statements, then you're probably doing something wrong.
I have an auto-update script that ensures that our database is at the correct patchlevel. It's fairly straight-forward: switch on patchlevel, execute the statements required to get up to the next one, at the bottom record the patchlevel in the database. (This relieves us of issues of schema changes done in development that didn't get pushed to production, for instance; our source code repository has _everything_ needed.) If anything goes wrong, Postgres will roll the transaction back. It doesn't matter if the first statement added a column to a table and the second does an INSERT... SELECT; they both get rolled back (as would any change to the patchlevel field, though that happens at the very end so it's not significant here). I can guarantee that the patch has either been completely applied or completely rolled back - exactly what transactions are for. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
