5

私は、PostgreSQL 8.4.7-0squeeze2 を使用した Debian スクイーズで Django 1.2.3-3+squeeze1 を使用しています (ただし、PostgreSQL はここでは関係ないと思います)。

   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が目的です。私が抱えている問題は、さまざまな単体テスト間で保存された状態がまだあるように見えることです。具体的には、ID が増加していることがわかります。で1 つのZipFileUploadオブジェクトを作成し、次に で 1 つのオブジェクトをtest1作成すると、両方のIDがであると予想されますが、私が見ているのはZipFileUploadtest211test12test2. これは、ID がこれらのテーブルの外にあるインデックスから取得された場合に意味があります。それが実際に当てはまるかどうかを知るために、Diangoがこれをどのように行っているかについて、私は十分に知りません. 彼らがこのようにしているとしたら、私にはその理由がわかりません。この点に関する説明をいただければ幸いです。

とにかく、誰かが提案できるなら、データベースを削除するクリーンな方法で解決します。このメソッドはおそらく に入るはずteadDownです。Django アプリケーションのテストでは、次の機能について言及されていますが、からのインポートに失敗しましたdjango.test.utils。紛らわしいことに、この関数はdjango/db/backends/creation.py.

destroy_test_db(old_database_name, verbosity=1)

名前が DATABASES の NAME に格納されているデータベースを破棄し、提供された名前を使用するように NAME を設定します。

この文の最初の部分は「名前が DATABASES の NAME に格納されているデータベースを破棄する」ですが、「提供された名前を使用するように NAME を設定する」とはどういう意味ですか? 提供された名前はold_database_name、

NAME文脈に何があるかは明らかではありません。NAMEもしそうなら、なぜDATABASESすでに設定されているものを設定する必要があるのですか? 提供された名前はold_database_nameだと思いますが、もしそうなら、なぜそれを という引数に設定したいのでしょうold_database_nameか? この文は、開発ドキュメントでは変更されていません。

編集：

Steve Mayne からの返信 (以下を参照) の後、この背景について少し詳しく説明したいと思います。

このアプリケーションは、単体テストを含め、2007/2008/2009 年に作成されました。その間、私は Django の 1.0 より前のリリースを使用していました。Ken Cochran の Django Release Historyによると、1.0 は 2008 年 9 月 3 日にリリースされました。説明されているセットアップは、その間は正常に機能していました。上記の TeaDown 関数は、もともと 2007 年 12 月に書かれたものであることがわかりました。では、Django の動作が変わったのでしょうか?

tearDown後から考えると、上記のようにテーブルを空にしても、id カウントが にリセットされることは保証されないことに気付きました1。これは、シーケンスがテーブルとは別のオブジェクトになる可能性があるためです。

スティーブの解決策に感謝します。存在する場合は、シーケンスのリセットに対する移植可能な解決策について聞きたいです。destroy_test_db上記の機能を機能させる方法の説明にも興味があります。

4

1 に答える 1

5

次の SQL を使用して、各テーブルの ID シーケンスをリセットできます。

SELECT pg_catalog.setval(pg_get_serial_sequence('table_name', 'id'), 1);

これは、テーブルが空の場合にのみ行う必要があります。

于 2011-06-06T09:42:39.577 に答える