Tag Archives: django

Django and Dreampie

Posted on by
Reply

As would be obvious by now I am a dedicated djangonaut (cheesy name I know) and I’ve been using django long enough now that using the ORM (Object Relational Mapping) is becoming second nature. Using SQL for anything but database gymnastics is somewhat annoying as the data isn’t as accessible to python as it is with an ORM. So when I need to get a quick insight into some data or prototype some code I want to be able to use the ORM instead of SQL.

I’ve also fallen in love with dreampie, which is an interactive python shell on steroids. It allows you to type and edit multi-line pieces of python code which you can then run in the inbuilt python shell. It has a fast clean interface and autocompletes attributes from the interpreter so you can get some hacking done quick.

Of course I want to be able to do quick django hacking in dreampie and I worked out a simple way of doing this.

import sys
sys.path.append('/path/to/your/project/')
import settings
from django.core.management import setup_environ
setup_environ(settings)
from a_django_app.models import AModel

Pasting this into dreampie (or loading it from the nice history functionality dreampie provides) sets up the shell with everything it needs to access the ORM (or anything else you use in django for that matter. The first two lines add the project’s path to the list of paths python uses to search for modules and packages. The next imports the project’s settings and activates those settings using the django function setup_environ. After that you can import app models and query away.

You can also use the same snippet of code at the top of standalone scripts to allow them to access the project’s django environment which is useful though it is normally advisable to add a management command instead.

Django Site Admin Emails

Posted on by
Reply

There is a neat feature in default behavior of Django. If while rendering a view it throws an uncaught exception it emails all the sysadmins in it’s settings file. This simple little feature is great on several levels.

  1. Repeatedly getting emails about an issue with often enough information to diagnose and fix the problem means you’re less likely to put up with broken windows.
  2. When something goes wrong you’re much more likely to find out about it, as monitoring is often one of the last things to be done on a project.

So it is a warm and fuzzy safety net that reassures you with an empty inbox, I really like it when I come in on Monday morning and I don’t get a single email telling me something barfed over the weekend.

And as an added bonus Django has this wonderful philosophy about exposing the pixie dust it uses to do it’s magic. All it takes is a call to mail_admins():

mail_admins("Made a sale","We just sold a pony for $%d" % pony_price)

And you’re alerting everyone when something good happens. This is great with new low volume projects where every sale is a momentous event. Of course you can use this for alerting the team about errors as well. There is also mail_managers() so you can setup the non technicals to receive relevant alerts with the same amount of effort.

Adding Composite Primary Keys to Django

Posted on by
Reply

Composite primary keys are great and relating two records together is best done using them. Adding another field just to identify the relationship makes the table un-normalized (that isn’t a word is it?) and we all want our tables normalized don’t we? So it is common practice for (good) database designs to use them anywhere two records are being related.

Unfortunately Django doesn’t support them right now, at least not without some nasty hacks. This means every time you get your hands on a legacy database there is a high likelihood that there will be composite primary keys are in use and you will be in for a world of pain if you wish to integrate it with Django. I’ve been there and the hacks are nasty, and also mean you can’t use a lot of components such as the admin which makes me sad as the admin is a beautiful thing.

The ticket (http://code.djangoproject.com/ticket/373) has been around for 5 years with only one person taking a decent crack at it and he seems to have stopped working on it around the same time the core team was working on 1.0. So I have started on the path of getting Django to support them. And this doesn’t just mean working on the ORM part of Django, it means getting every part of Django to understand that a primary key doesn’t just mean one column/field. Not a small project by any means but it will show some pay-offs in the short term as it replaces the hacks I currently have in place.

Once I have some code to show it will be up on my github http://github.com/hartror