2011-08-02 17 views
0

私は考えを持っていましたが、実装する前にいくつかのフィードバックを得るためにそこに投げ捨てたいと思います。Djangoテストを使用してデータベースのデータを分析および修復する

ここには次のようなものがあります。私は非常に急速に成長しているデータベースを使ってウェブサイトを運営しています。いくつかの問題については、かなりの量のゴミで満たされています。私は、データベースを横断して実行し、混乱を取り除くためにいくつかのスクリプトを準備することを考えていました。ですから、私の考えはDjangoテストを使用することでした。ちょうどそれを行う小さな単純なテストの大きな合計を書く方法ですが、フラグを立てる代わりに実際に問題を修正します。

あなたはどう思いますか?私は何らかの理由でこれがうまくいかないとは思えません。しかし、私はDjangoで味付けされていません。それは難しいだろうか?予測可能な問題はありますか?

ありがとうございます!

答えて

3

いいえ、これはデザインの観点から実装の問題に至るまで、さまざまな理由から悪い考えです。ちょっと言えば、

  1. 実際のデータベースではテストが実行されません。別のデータベースが最初から作成されます。あなたはこれをハックする必要があります。
  2. 通常、データベースに接触する各テストケースはトランザクション内で実行され、次にロールバックされます。したがって、最終的にDBは全く変更されていません。あなたもこれを避けることができますが、それはポイントではありません。
  3. テストは、何かを変更すると常に実行されるはずです。しかし、について話している問題の種類は、は(たいていの場合)1回限りでなければなりません。

しかし、あなたは何をしたいのための非常にシンプルかつ適切な解決策がある:

  1. 間違った/不要なデータが発生しSouth
  2. 修正のバグをインストールします。
  3. 既に存在する「壊れた」データを修正/クリーンアップするdata migrationを書き込みます。
  4. 更新して移行します。
  5. 繰り返し2-5

は今、これは一回限りの修正のためであるが、ほとんどの場合、これはそれを行うための正しい方法です。データの修正に加えて、データの問題を引き起こすバグを修正します。

実際に同じデータ変更機能を2回以上(定期的に)実行する必要がある場合は、custom management command(または単純な実行可能なpythonスクリプト)を作成し、cronから実行するようにスケジュールすることができます。

関連する問題