Question

I’m not 100% sure I’m doing this right, but I think I’ve found an issue where auth.Permission objects aren’t being created soon enough for migrations to use them when you initialize a DB from scratch.

The important details:

• I’m trying to initialize a Django DB from scratch using ./manage.py syncdb --migrate --noinput

• I have 11 migrations in my chain

• The 1st migration creates a new model called myapp.CompanyAccount

• The 9th migration tries to fetch the permission myapp.change_companyaccount with:

p = orm[ "auth.Permission" ].objects.get( codename = "change_companyaccount" )

At that point, an exception is raised:

django.contrib.auth.models.DoesNotExist: Permission matching query does not exist

I had assumed that the default permissions that are defined for every object (as per http://docs.djangoproject.com/en/dev/topics/auth/#default-permissions) would have been created by the time the 1st migration finished, but it doesn’t appear that they are. If I re-run the migration after the exception, it works the second time because apparently the permission now exists and the 9th migration can execute without error.

Is there anything that can be done to “flush” everything sometime before the 9th migration runs so that the whole thing can run in a single pass without bailing out?

Thanks for any help / advice.

EDIT: In response to John’s comment below, I found out that the following command-line sequence will work:

1. ./manage.py syncdb (this initializes the default Django tables)
2. ./manage.py migrate myapp 0001 (this causes the CompanyAccount table to be created)
3. ./manage.py migrate myapp (this migrates all the way to the end without error)

Unfortunately, skipping step #2 above means that you get the same exception in the 0009 migration, which tells me that my original suspicion was correct that default permissions on new models are not created by South immediately, and are somehow only pushed into the database when the entire migration chain finishes.

This is better than where I was (I’m at least avoiding exceptions now) but I still need to manually segment the migration around the creation of new models that latter migrations might need to touch the permissions of, so this isn’t a complete solution.

Answer 1

As it turns out, the answer is to manually call db.send_pending_create_signals() at some point before you try to access the default permission since South only does this “flushing” step quite late in the process. Thanks to Andrew Godwin from South for replying to this on the South mailing list here:

http://groups.google.com/group/south-users/browse_thread/thread/1de2219fe4f35959