Opened 15 years ago

Closed 14 years ago

#11828 closed (fixed)

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

Reported by: craig.kimerer@… Owned by: robmadole
Component: Testing framework Version: soc2009/multidb
Severity: Keywords: multidb syncdb content_type
Cc: robmadole@… Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (3)

comment:1 by robmadole, 14 years ago

Owner: changed from nobody to robmadole
Status: newassigned

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

comment:2 by robmadole, 14 years ago

Cc: robmadole@… added
Keywords: multidb syncdb content_type added
Triage Stage: UnreviewedDesign decision needed

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.

comment:3 by Russell Keith-Magee, 14 years ago

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top