There’s a fairly long-standing bug in Django where initial SQL files break if they contain a double hyphen in a quoted string when you run manage.py syncdb. This bug also causes problems if you’re trying to create stored procedures in MySQL and need to change the delimiter to allow multiple statements.
Seems the problem is some overly naive code to split the SQL file into individual statements. Unfortunately there’s no easy fix without at least partially reinventing the SQL parser or spawning a separate mysql command line client process. Best approach in the meantime is to avoid using stored procedures and check any scripts that you do have using Django’s unit test framework.
Over the weekend I was doing a bit more Django development, and I ran into a rather strange problem. I had written a custom command for manage.py whose last task was to update some rows in a couple of database tables using some raw SQL commands. Strangely, the changes weren’t showing up when I looked at the data in MySQL Query Browser afterwards. Even more strangely, when I copied and pasted the raw SQL and ran it in Query Browser, it worked fine.
A little bit of extra code revealed that the SQL commands were being run, which absolutely screamed that the code was being run in a transaction that wasn’t getting committed. Fixing it was simply a case of adding these two lines at the end of my custom command:
from django.db import transaction
transaction.commit_unless_managed()
I’m not sure whether this is a bug or a feature. Django’s default transaction behaviour — in HTTP requests at any rate — is the autocommit model: every change you make is automatically committed as soon as it is run. I’d have thought it would be the same in management commands, but clearly it is doing something rather different here. If anyone can enlighten me, I’d be interested to know.
I came across this error this morning on a Django project that I’m working on in my spare time. I was trying to add some custom permissions to one of the models, as outlined in the documentation, only to have it choke with this message when I ran manage.py syncdb.
A bit of Googling got me to this site, but unfortunately it’s in Polish. Never mind, Google Translate managed to give me enough information. Turns out that I had missed out a comma that I didn’t think was necessary:
class Meta:
permissions = (
("can_drive", "Can drive"),
("can_vote", "Can vote in elections"),
("can_drink", "Can drink alcohol"), # <== This comma is important!
)
Hmmm, I always thought that last comma in Python was only an optional extra in case you decided to add an extra item to the end of a tuple and forgot to add it in to the previous line. Seems it does have some obscure but significant semantic importance after all.
I’ve been fiddling with Django a bit in my spare time recently, with a view to possibly using it for some side projects. It’s the Python web application framework, similar in many respects to Ruby on Rails but with a distinctive flavour of its own.
It looks fairly promising. I particularly like its built in administration interface — it’s better than Rails’s scaffolding, giving you an integrated interface to pretty much all the models that are mapped to the database straight out of the box. It also seems more flexible than Rails — there are a few decisions that it leaves up to you, such as which JavaScript framework to use, or how exactly to structure your application.
I first started learning Python about three years ago when I used it to write some maintenance scripts for the Kingdom Faith podcasts, and since then I’ve used it for various random odds and ends (our daily build script is written in Python for instance) but nothing majorly extensive. As far as scripting languages go it has a lot to offer — it is relatively fast, has pretty good Unicode support, and fully supports procedural, object oriented, aspect oriented and functional programming paradigms, though it could do with better support for multi-statement lambdas like in JavaScript, Ruby and C#. I also like the way it forces you to write code that is clean and easy to read and follow, by making indentation syntactically significant and by making package and module names follow filesystem names. It is also fairly well documented, though the index in the .chm help file on Windows is a bit quirky at times.
Another good thing about Python is that it is very much an all-rounder: like .net or Java, you can write web applications, console applications, services, GUI applications, maintenance scripts or whatever else takes your fancy with it. This is in contrast to PHP and Ruby, which tend to be dominated to a much greater extent by web development, though they are capable of being used for other things. Python also has fairly mature support in the .net ecosystem — IronPython is the most mature of the DLR languages, so integrating Django with .net framework code is a real possibility. It also seems to have a much smarter contingent of users on average than either .net, Java or PHP. I think this is because it is only infrequently the first programming language that people learn, and most Python developers already have quite a bit of experience with two or even three other languages.
RSS feed
Comments (1) » 
Posted at 08:00 in Python 
Feel free to take a look round the site — if I
say anything that 
