Django: “Cannot add foreign key constraint”

Upgraded to Django 1.8 and now you get this error when you run your tests?

Have you created migrations for all your apps? If not, you may well be hitting the problem that the database tables are being created in the wrong order, which will give you this error.

If you have an existing Django 1.7 or earlier project, then you need to create the initial migration files, and then fake the initial migration, as described here

Create the migration with

$ python make migrations your_app_label

And then fake the application

$ python migrate –fake-initial your_app_label

Migrating from django-registration to django-allauth

I’ve been wanting to migrate away from django-registration for a while.

Yes, I know it’s been the default registration package since forever and I’ve used it happily for many years. But :

  • it’s no longer actively maintained
  • I want to do away with the email confirmation
  • I want to allow login using either email or username

So after a bit of googling, I decided to try out django-allauth, and I’ve just finished the migration.

Here’s some notes for anyone else thinking about doing the same.

I’ve got an existing system:

  • Django==1.5.1
  • django-registration==1.0

Note: I’m only setting up the ‘accounts’ side of the allauth package, I’ll leave the social-accounts for later.

So here’s what I did:

  1. Set up django-allauth as per their documentation at
  2. Removed the django-registration module from the settings
  3. I wanted to use my own templates rather than theirs, so I added an account subdirectory into my accounts/templates and copied theirs over from the package. I needed to ensure that their package was called later in INSTALLED_APPS to make sure my templates were found first.
  4. Mostly the templates just worked by changing my copy of their templates to use my base template, and other cosmetic changes
  5. One minor gotcha was that the django-registration login template uses id_username as the field, whereas django-allauth uses id_login (since it can be either username or email)
  6. By default, allauth will produce a message for every action. Their base template displays these. I decided I didn’t want them; so following their instructions at replaced the provided templates with blanks.
  7. I added a redirect url from the old django-registration /accounts/register to the new django-allauth /accounts/signup

That was it. Much easier than I expected.


Replace user-input field with enforced value in Django form

I’m subclassing someone else’s form; I need to remove their input field and replace it with a fixed value.

class MyForm(TheirForm):

    def __init__(self, *args, **kwargs):

        super(MyForm, self).__init__(*args, **kwargs)

        # remove unwanted field

    def clean(self, *args, **kwargs):

        cleaned_data = super(MyForm, self).clean(*args, **kwargs)

        # Restore field with fixed value
        cleaned_data['fixedfield'] = FIXEDVALUE

        return cleaned_data



I like BDD. I like cucumber.

I like python. I like django.

I don’t like lettuce, a commonly-used python port of cucumber, when used with django. They’ve chosen the completely daft option to use your main database when testing. I’d forgotten this, so when I discovered I’d torched my production database just because I wanted to write a test, I decided to not touch lettuce again…

And then I discovered behave, which works fine as a python BDD tool; except it doesn’t have an easy tie-up with django.

So I wrote one.

It’s a Work-in-Progress, but I’m using it for my developments, so its definitely usable. Comments, etc, very welcome – please use github for this.


Django GeoIP templatetag

I’ve published 2 template tags for use with GeoIP at

Hope they may be of use…


# Templatetag get_country_name returns the client’s country code
# Example:
# {% ifequal get_country “GB” %}
# do something
# {% endifequal %}

# Templatetag get_country sets the given variable name
# to the client’s country code
# Example:
# {% get_country as my_country %}
# {% ifequal my_country “GB” %}
# do something
# {% endifequal %}

Django App Quick Start

I wanted to start writing a Django app which was to allow a user to enter data in various tables, and then run a workflow process.

I liked the admin front-end but thought I needed to do something clever with generic views to replicate this in my own application.

So I asked this question on the django-users list

On 04/09/05, Rachel Willmer  wrote:
> I want to use the generic view mechanism to add/change/delete but I
> don't want to have to write my own form template for each page.
> I'd like it to work just like the admin interface does. Is it
> possible/sensible to hook into the admin code which seems to use
> add_stage/change_stage to automatically generate the templates? Or is
> there a better way of doing this?
> Any pointers welcome...
> Rachel

Now I’ve read a bit more about it, the answer is of course to just use the admin interface. :-) includes a useful command “adminindex”, which will auto-generate a copy of the admin interface index page.

So generate that, and copy it into your template directory to over-ride the inbuilt one, as described in Tutorial2

Then you can modify that as you wish…

Hey presto, instant application front end that you can use as the basis for the new application…

In retrospect, this is obvious and documented in the Django tutorial. But at the time, I was thinking in terms of “admin” interface and “main” interface, and it slipped past me that I could in fact use the admin interface *as* the main interface…

That might not work too well for most web applications, but for my purposes, (a local single-user application), it will work just fine…