Testing w/ contenttypes with syncdb causes an error django_content_types table does not exist

[craig.kimerer@…]

A quick way to see the error (which is obviously wrong)

1. Add contenttypes to your installed apps
2. Create a model on second db (we'll call it 'other_db')
3. In django/test/simple.py run_tests() make the alias iteration order (you can hardcode this) to be for alias in ordered: with `for alias in ['other_db', 'default']

That will show that the db creation order is important.

The other harder way to do this, is to find something that lets you iterate over a dictionaries items where whatever your other alias hashes "before" the 'default' one does.

[robmadole]

I suspect the fix to this is related to #7052. I will give this a go.

[robmadole]

I've confirmed what Craig has reported. It does indeed cause a problem with the test runner but only if you hack it up as he's described. I wouldn't call this a bug unless there was some way to reproduce the error naturally.

But I think here is the crux of the problem:

• The settings file has a DATABASES dictionary
• Dictionaries are unordered
• We can't guarantee the default database (where django_content_type lives) gets sync'd before it's needed

I'm not sure what the best fix is. I can think of a couple ways; one of which is to make sure the default database is ALWAYS returned first in connections iterator. This would only fix stuff that relies on default though but that might be good enough. Not perfect though, a fringe case might actually produce this problem I just can't wrap my head around the actual steps to get there. (And it seems like Craig could not either.)

The second way I thought of is nasty, basically make sure that every table is created for every connection before we emit_post_sync_signal.

[Russell Keith-Magee]

There may have been a problem at the time of the original report due to errors being raised; however, there have since been some major changes to the way the management commands interact with multiple database situations, so this doesn't appear to be a problem any more - I certainly can't reproduce the problem using the technique described.