Category: Python

Django IntegrityError On PostgreSQL

The answer is here:
http://www.chrisspen.com/blog/handling-postgresql-integrity-errors-in-django.html

I was seeing IntegrityErrors while trying to unit test uniqueness constraints within a database table (it’s not strictly necessary, I suppose, but I was just being thorough, so much for trying to do the right thing):

What didn’t make sense was that the exact same sequences of calls would work just fine in ipython, they just wouldn’t work when under Unit test.

Turns out, whenever an IntegrityError happens while using Django and PostgreSQL, for whatever reason you need to close the entire connection to reset the transaction in the exception handler, which looks like:

Django Unit Testing On Shared Hoster

So I’ve been trying to write unit tests for Django, but, as I’m doing a lot of work on a shared hoster, this isn’t working. The problem is that our user account doesn’t have CREATE/DROP DATABASE privileges on the server. This has been documented here, here, here, and here.

Which means I see the following if I try to run manage.py test, I get:

Unfortunately, there isn’t a first-class solution from the Django devs, so after reading that django-nose had a handy REUSE_DB parameter, I tried to install django-nose.

(no-deps because I’m working with Django 1.5 beta 1)

Then, in settings.py, I set TEST_RUNNER=’django_nose.NoseTestSuiteRunner’, and set the TEST_NAME key on your ‘default’ DATABASES entry to the same value as NAME.

Unfortunately, you still get errors, if you’re trying to use PostGIS, seems like transactions may not be a happy thing there:

So it looks like the only option I now have is to write unit tests that just run against a development database, and do a decent job of cleaning up after themselves in the setUp and tearDown methods. Using the standard nose distribution will do this, but if you just do “pip install nose” and try using “nosetests”, it will error out:

The problem is that nose doesn’t know about Django’s settings or modules. You have to make a copy of nosetests into the same directory where “manage.py” is located and change it so the DJANGO_SETTINGS_MODULE is incorporated into the os.environ resource. Like so:

Then you’ll see:

$ ./nosetests
……
———————————————————————-
Ran 6 tests in 4.955s

OK
$

Damn You, Emacs Autoinsert

Emacs can also be annoying when it autoinserts text without checking to see if it’s already there. Case in point, gettext .po files under Emacs 23.1. For whatever reason, my copy kept inserting this header whenever I opened a translation file:

If this header sneaks into a .po file, when you try to compile the file with Django’s compilemessages command, you get the following error:

What seems to happen is that this header is only inserted when you use C-x C-f to open a file. When opening a file directly from the command line, this corruption does not seem to occur.

If you look at the PO Group configuration options, this text is listed there as the default PO file header. I haven’t validated this as a solution, but you should be able to switch this value to be the comment character “#”, and that should take care of the problem.

Also, why the hell does the PO major mode not allow you to destroy entire msgid’s and their translations? This is really annoying. Yes, it’s nice sometimes when programs limit your options, but in this case, Emacs was messing up by inserting the bad header, then refusing me the option of removing it.

Custom Pystache Template And Loader Classes For Django

Update: I’ve posted the code at github here.

Wanting to keep my server-side and client-side templates identical, I noticed there wasn’t a good solution for using Mustache/Pystache/Handlebars templates alongside the Django templating language.

The existing one that I saw used Pystache internals, and I’m not even sure they’re still valid in the latest Pystache versions.

The other existing one that I saw let you do the equivalent of #include “something.mustache” within the Django templates, which wasn’t what I was looking for either.

So I went ahead and wrote a set of PystacheTemplate and Pystache*Loader classes which do it all within the specifications of the Django infrastructure, and, I set them up so that you can specify the exact file extensions you want them to operate on, i.e. just .mustache, .handlebars, and .hbs files by default. This doesn’t mean you can mix Mustache directly into Django templates, which doesn’t make sense (and is mildly redundant), but it does mean you can render complete Mustache template files directly, which is awesome if you’re wanting to share those templates or partials between client and server.

Copy this file somewhere into your project or app folders:

Then you can just update the settings.py file to use the custom Loaders, putting them ahead of Django’s default Loaders in the TEMPLATE_LOADERS setting:

Then if you have, say, a file called index.handlebars somewhere in one of your app directory template/ folders or somewhere else in the TEMPLATE_DIRS list, you can just do this in one of your views:

And all will be good.

Please let me know in the comments if you have any problems with this. (Speed might one of them, I haven’t extensively tested this yet. But I plan to cache these using the Django template cache loader.)

Language Names, In Those Languages

While looking around for a decent spreadsheet containing a map between the ISO 639-1 two-letter language codes and localized versions of language names, I could not find a straightforward version of this information published in a sensible form like CSV or as a JSON object.

What I’m looking for is something like:

This way, when I want to display the name of a language in a particular locale, I can just do a simple lookup: languageNameMap[localeCode][languageCode].

So here is my attempt at putting together something like this, using reference material from the Unicode Common Locale Data Repository.

Inside of the core.zip file, a number of locale definition files are located under common/main/*.xml:

Each of these files contains a list of the world’s languages, as they would be named in that locale.

For example, in the German language locale definition file “de.xml” and many of the other files, there’s a “languages” list that looks like:

Now, let’s say we want the names of of the German language and the English language, in those languages, respectively. The output should be a grid of 2 x 2 language name pairs.

I’ve written a PHP script to parse the necessary locale definition files and to create a JSON object containing this information:

When it is run from the command line (and with a little help from Python, since OS X doesn’t by default ship w/a pretty-printing PHP) the following should pop out:

So if you want to use this later to display the name of the English language in German, you just do something like languageNameMap[‘de’][‘en’]; (I realize it might even be easier to rewrite the script so it’s LNM[‘en’][‘de’] instead, but I’ll leave that as an exercise to the reader.)