Приращение идентификаторов объектов django между модульными тестами

Я использую Django 1.2.3-3 + squeeze1 на Debian squeeze с PostgreSQL 8.4.7-0squeeze2 (хотя я не думаю, что PostgreSQL здесь уместен) и запуск модульных тестов Django на основе unittest со следующими setUp и tearDown

   def setUp(self):
        print "running setup"
        self.c = Client()
        self.user = User.objects.create_user('faheem', 'faheem@email.unc.edu', 'foo')
        self.logged_in = self.c.login(username='faheem', password='foo')
        settings.MEDIA_ROOT='/tmp/'
        #settings.ZIP_UPLOAD='/var/tmp/zip/'

    def tearDown(self):
        print "running teardown"
        FolderUpload.objects.all().delete()
        FileUpload.objects.all().delete()
        ZipFileUpload.objects.all().delete()
        OldFileUpload.objects.all().delete()
        # FIXME: Quick & dirty fix for the time being. Should make this a delete method.
        os.system("rm -rf "+ settings.ZIP_UPLOAD + "/*")

Идея состоит в том, чтобы все было удалено из базы данных между запуском модульных тестов. Согласно документации unittest, для этого и нужен tearDown . Проблема, с которой я столкнулся, заключается в том, что между различными модульными тестами все еще сохраняется какое-то состояние. В частности, я вижу, что идентификаторы увеличиваются. Допустим, я создаю один объект ZipFileUpload в test1 , а затем создаю один объект ZipFileUpload в test2 ,тогда я ожидал бы, что оба идентификатора будут 1 , но я вижу, что это id 1 для test1 и id 2 для test2 . Это имело бы смысл, если бы идентификаторы были получены из некоторого индекса, который находится за пределами этих таблиц. Я не знаю достаточно, как Дианго это делает, чтобы понять, так ли это на самом деле. Если они так поступают, я не знаю почему. Приветствуются любые разъяснения по этому поводу.

Тем не менее, я бы согласился на чистый способ отбросить базу данных, если кто-нибудь может предложить такой. Этот метод, вероятно, следует использовать в teadDown . При тестировании приложений Django упоминается следующая функция, но мне не удалось импортировать ее из django.test.utils . Как ни странно, эта функция находится в django / db / backends / creation.py .

destroy_test_db (old_database_name, verbosity = 1)

Уничтожает базу данных, имя которой хранится в NAME в БАЗАХ ДАННЫХ, и устанавливает NAME для использования предоставленного имени.

Первая часть этого предложения - Ok - " Уничтожить базу данных, имя которой хранится в NAME в DATABASES ", но что подразумевается под "устанавливает ИМЯ для использования предоставленного имени"? Я предполагаю, что предоставленное имя old_database_name ,

Непонятно, что NAME находится в контексте. Это ИМЯ в БАЗАХ ДАННЫХ , и если да, зачем мне устанавливать то, что уже установлено? Я предполагаю, что предоставленное имя old_database_name , но если да, то зачем мне устанавливать его для аргумента с именем old_database_name ? Это предложение не изменилось в документации по разработке.

РЕДАКТИРОВАТЬ:

После ответа Стива Мейна (см. Ниже) я подумал, что немного подробнее расскажу об этом.

Это приложение изначально было написано поверх 2007/2008/2009, включая юнит-тесты. Большую часть этого времени я использовал версии Django до 1.0. Согласно Кен Кокран из истории выпусков Django , 1.0 была выпущена 3 сентября 2008 года. Описанная установка работала нормально в течение этого времени. Я вижу, что описанная выше функция tearDown была первоначально написана в декабре 2007 года. Так, возможно, поведение Django изменилось?

Оглядываясь назад, я понимаю, что очистка таблиц, как tearDown выше, не гарантирует, что счетчик идентификаторов будет сброшен на 1 , поскольку последовательность может быть отдельным объектом из таблицы.

Спасибо Стиву за его решение. Если он существует, я бы хотел услышать о переносном решении для сброса последовательности. Мне также было бы интересно узнать, как заставить работать приведенную выше функцию destroy_test_db .