Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!goblin2!goblin.stu.neva.ru!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.004 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'subject:Python': 0.05; 'repository': 0.05; 'schema': 0.05; 'column': 0.07; 'instance.': 0.09; 'postgres': 0.09; 'sep': 0.09; 'wrong,': 0.09; 'pushed': 0.13; 'sat,': 0.15; '*should*': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'here).': 0.16; 'instance;': 0.16; 'statements,': 0.16; 'wrote:': 0.17; 'app': 0.19; 'changes': 0.20; 'fairly': 0.21; 'received:209.85.214.174': 0.21; 'back.': 0.22; 'statement': 0.23; '(this': 0.24; 'patch': 0.24; 'second': 0.24; 'script': 0.24; 'header:In-Reply-To:1': 0.25; 'am,': 0.27; '(as': 0.27; 'message-id:@mail.gmail.com': 0.27; "doesn't": 0.28; 'correct': 0.28; 'chris': 0.28; 'record': 0.28; 'issuing': 0.29; 'statements': 0.29; 'source': 0.29; 'probably': 0.29; 'field,': 0.30; 'fri,': 0.30; 'code': 0.31; 'switch': 0.32; 'goes': 0.33; 'to:addr:python-list': 0.33; 'received:google.com': 0.34; 'done': 0.34; 'doing': 0.35; 'table': 0.35; 'received:209.85': 0.35; 'something': 0.35; 'there': 0.35; 'next': 0.35; 'really': 0.36; 'but': 0.36; "didn't": 0.36; 'anything': 0.36; 'execute': 0.37; 'one,': 0.37; 'does': 0.37; 'why': 0.37; 'received:209': 0.37; 'data': 0.37; 'subject:: ': 0.38; 'to:addr:python.org': 0.39; 'received:209.85.214': 0.39; 'header:Received:5': 0.40; 'end': 0.40; 'your': 0.60; 'bottom': 0.60; 'skip:u 10': 0.60; 'matter': 0.61; 'first': 0.61; 'back': 0.62; 'our': 0.65; 'matter.': 0.65; 'click': 0.76; 'relieves': 0.84; 'production,': 0.91; 'transactions': 0.91 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Z3X9vVU6vNSGetZ/Y94ByPEyXdRSyDicAKp6M/eMwOg=; b=kVr686US2N8H1ZDxRxla9VX47H1oNDRCXXSs9l2BhXVoxV6x94vkhXyU/K/kWSp/9I +dONaflSUWu6LTeysoNrDFT8wDBnHSsm3tBeM5xriwAwf2BMJRgj4TaMLnjJMK49pma3 ZJBnWmYQgw3D3rLTmfa/r9Dbsymmadyee2IcSVoQsISWLsTLjWAmBY1yEoGhYUTQpbVa Pz4UExC8yZGAm6YbInwQHGu4xcJPJFjV7G7a9ns2e5AovhE41HFzJKuh8fuWBaakyO6A 1yuVYMrhWhralWhRtxNHQGAs0Q8N9iCOtkqHj90MAr6wX2IZ479Y0/58LHVoFr7qQwDp GWZQ== MIME-Version: 1.0 In-Reply-To: References: <506515F8.9020606@tysdomain.com> Date: Sat, 29 Sep 2012 01:20:45 +1000 Subject: Re: Article on the future of Python From: Chris Angelico To: python-list@python.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 27 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1348845647 news.xs4all.nl 6868 [2001:888:2000:d::a6]:35893 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:30403 On Sat, Sep 29, 2012 at 1:14 AM, Ian Kelly wrote: > On Fri, Sep 28, 2012 at 8:58 AM, Chris Angelico 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