almosteffortless.com | djangoproject.com | python.org | linux.com
demongin.org - Error Log

Error Log

Three mistakes I made today and how I corrected them; posted for posterity.


Saturday, 2010-01-16 | Django, Programming

"A woman may very well form a friendship with a man, but for this to endure, it must be assisted by a little physical antipathy."
Nietzsche

I spent most of this weekend working on a top-secret django project.

As usual, I screwed a bunch of stuff up before finally brute-forcing my ideas into print and getting my applications and views working correctly. What follows are three things I learned about python, django and postgresql today:

Automatic thumbnail width/height resizing with PIL

If you're using the python image library's built-in thumbnail function to resize images, you might not know that you only need to specify the width or the height when resizing. Say, for instance, you've got some thumbnail-creating code that looks like this and creates thumbnails 30 pixels wide and 50 pixels high:
    im = Image.open("/path/to/image")
    im.thumbnail((30,50), Image.ANTIALIAS)
Now, say you're not 100% sure that everything which could potentially get thumbnailed by that code is going to be at the same aspect ratio. All you've got to do is use the special "auto" value in your size tuple:
    size = (30, "auto")
    im.thumbnail(size, Image.ANTIALIAS)
And voila: the width is 30 pixels and the height is resized at 1:1. Nice.

'duplicate key value' violations in django

If, while working on a django project, you run manage.py syncdb and get an error that looks like the following: 
psycopg2.IntegrityError: duplicate key value violates unique constraint "django_content_type_pkey"
And your logs look like this:
/var/log/postgresqltoconnell@jane:~/$ sudo tail -f /var/log/postgresql/postgresql-8.3-main.log
[sudo] password for toconnell: 
2010-01-16 09:21:39 EST ERROR:  duplicate key value violates unique constraint "django_content_type_pkey"
2010-01-16 09:21:39 EST STATEMENT:  INSERT INTO "django_content_type" ("name", "app_label", "model") VALUES (E'artist', E'disco', E'artist')
You've got two options: 1.) roll up your sleeves, fire up the psql monitor and start manually tampering with table data or 2.) drop the database, load a backup and start over.

Basically, what happened here is that you ran django-admin startapp appname twice; i.e. you started an app of the same name twice and, when you went to add it to your application, with that syncdb command, you tripped a unique key constraint intended to prevent ambiguous calls to the database.

My Advice: drop the table and load the back-up--automatically created django database tables tend to dislike being tampered with.

Speaking of restoring postgres data...

When restoring data, remember to specify database name. If, for example, you do this: 
# su postgres -c 'psql -f demongin.sql'
You'll end up copying all your tables to the postgres database; ye olde psql monitor, for better or for worse, always assumes that you want to use the database of the same name of the user that you're attempting to operate with.

A proper restore of a postgres dump looks like this:
# su postgres -c 'psql -f demongin.sql -d demongin'