Code

Opened 5 years ago

Closed 5 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: UI/UX:

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.

Attachments (0)

Change History (3)

comment:1 Changed 5 years ago by robmadole

  • Needs documentation unset
  • Needs tests unset
  • Owner changed from nobody to robmadole
  • Patch needs improvement unset
  • Status changed from new to assigned

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

comment:2 Changed 5 years ago by robmadole

  • Cc robmadole@… added
  • Keywords multidb syncdb content_type added
  • Triage Stage changed from Unreviewed to Design 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 Changed 5 years ago by russellm

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.