Django SQLite testing oddity: Different path of execution?

This is merely a theory that I would like to figure out based on others feedback and perhaps similar experiences.

Been using mySQL for running tests, but of course an in-memory SQLite database is much faster. However, it seems to have run into some problems.

When DATABASE_ENGINE is set to use django.db.backends.sqlite3 and I run manage.py test, the output is not as hoped:

(Removed most lines, but pointing out interesting points of failure)

开发者_如何学JAVA$ python manage.py test
Traceback (most recent call last):
  File "manage.py", line 12, in 
    execute_manager(settings)
  File "/Users/bartekc/.virtualenvs/xx/lib/python2.6/site-packages/django/core/management/__init__.py", line 438, in execute_manager
    utility.execute()
  File "/Users/bartekc/domains/xx/xx/associates/yy/models.py", line 51, in 
    class AcvTripIncentive(models.Model):

  # First interesting failure
  File "/Users/bartekc/domains/xx/xx/associates/yy/models.py", line 55, in AcvTripIncentive
    trip = models.OneToOneField(Trip, limit_choices_to={'sites' : Site.objects.get(name='ZZ'), 'is_active' : True,})

  # Next interesting failure
   File "/Users/bartekc/domains/xx/xx/associates/yyz/models.py", line 252, in 
    current_site = Site.objects.get_current()

There are multiple failures like this but just pointing out a couple. The problem is obvious. The Site model has no actual data, but the files contain code that try to fetch the current, or specific instances under the Site model.

Now, I can think of an easy solution: That OneToOneField should be switched to use a function with limit_choices_to, and the second one the same. The functions are then called when required, not on initial scanning of the file by Django.

However, my actual question is: Why does this happen with SQLite and not mySQL?. Is there a different way the two database engines process through tests? I wouldn't think so, since Python is doing all the compiling of the models.

What exactly is happening here?

Cheers.

Is there some reason you are not mocking access to the database? Your UT boundary gets enormously wide when you add a database (no matter what database) to the mixture. It starts to look more like an integration test rather than a unit test.

Are you loading your Site objects from a fixture?

If so, perhaps you are stumbling upon a known issue with MySQL and transactions. Do a text search for "MySQL and Fixtures" on this page: http://docs.djangoproject.com/en/dev/ref/django-admin/?from=olddocs