title: django object ids increment between unit tests
body: <p>I'm using Django 1.2.3-3+squeeze1 on Debian squeeze with PostgreSQL 8.4.7-0squeeze2 (though I don't think PostgreSQL is relevant here), and running Django unit tests based on unittest with the following setUp and tearDown</p>
  
  <pre><code>   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 &amp; dirty fix for the time being. Should make this a delete method.
          os.system("rm -rf "+ settings.ZIP_UPLOAD + "/*")
  </code></pre>
  
  <p>The idea is for everything to be removed from the database between running unit tests. According to the unittest documentation,
  that is what <code>tearDown</code> is for. The problem I am having is that there still seems to be some state saved between the different unit tests.
  Specifically, I'm seeing that the ids get incremented. So lets say if I create one <code>ZipFileUpload</code> object in <code>test1</code>, and then create one <code>ZipFileUpload</code> object in <code>test2</code>, then I would expect both ids to be <code>1</code>, but what I see is that is id <code>1</code> for <code>test1</code> and id <code>2</code> for<code>test2</code>. This would make sense if the ids come from some index which lives outside these tables. I don't know enough about how Diango does this to know if that is in fact the case. If they are doing it this way, I have no idea why. Any clarification on this point would be appreciated.</p>
  
  <p>Regardless, I would settle for a clean way to drop the database, if anyone can suggest one. This method should probably go into <code>teadDown</code>. <a href="https://docs.djangoproject.com/en/1.2/topics/testing/" rel="nofollow">Testing Django applications</a> mentions the following function, but I failed to import it from <code>django.test.utils</code>. Confusingly, this function seems to be in <code>django/db/backends/creation.py</code>. </p>
  
  <blockquote>
    <p>destroy_test_db(old_database_name, verbosity=1)</p>
    
    <p>Destroys the database whose name is in stored in NAME in the DATABASES, and sets NAME to use the provided name.</p>
  </blockquote>
  
  <p>The first part of this sentence is Ok  - "Destroy the database whose name is stored in NAME in the DATABASES",
  but what is meant by "sets NAME to use the provided name" mean? I assume the provided name is <code>old_database_name</code>,</p>
  
  <p>It is not clear what <code>NAME</code> is in the context. Is it the <code>NAME</code> in <code>DATABASES</code>, and if so,
  why do I need to set something that is already set? 
  I assume the provided name is <code>old_database_name</code>,
   but if so, why would I want to set it to an argument called <code>old_database_name</code>?
  This sentence is unchanged in development docs.</p>
  
  <p>EDIT: </p>
  
  <p>After a reply from Steve Mayne (see below), I thought I would elaborate on the background of this a little bit.</p>
  
  <p>This application was originally written over 2007/2008/2009, including the unit tests. During most of that time, I was using pre 1.0 releases of Django. According to <a href="http://kencochrane.net/blog/2010/05/Django-Project-Release-History/" rel="nofollow">Ken Cochran's Django Release History</a>, 1.0 was released on September 3rd, 2008. The setup described worked fine during that time. I see that the tearDown function above was originally written in December 2007. So, perhaps Django's behavior changed?</p>
  
  <p>In hindsight, I realise that emptying the tables, as <code>tearDown</code> does above, does not guarantee that the id count will be reset to <code>1</code>, since the sequence can be a separate object from the table.</p>
  
  <p>Thanks to Steve for his solution. If it exists, I'd like to hear about a portable solution to the sequence reset. I'd also be interested in an explanation of how to make the <code>destroy_test_db</code> function above work.</p>