revision-up-to: | 8961 (1.0) |
---|
まず、 DEBUG 設定を True にして Django を動かしているか確認してく ださい。次に、以下のコードを実行します:
>>> from django.db import connection
>>> connection.queries
[{'sql': 'SELECT polls_polls.id,polls_polls.question,polls_polls.pub_date FROM polls_polls',
'time': '0.002'}]
connection.queries を使えるのは DEBUG が True の時だけです。こ の値は、クエリの実行順に辞書を並べたものです。各辞書には以下の値が入ってい ます:
``sql`` -- 生の SQL 文 ``time`` -- SQL 文の実行にかかった時間を秒で表したもの
connection.queries には、 INSERT, UPDATE, SELECT といった全ての SQL 文 が入ります。クエリはアプリケーションがデータベースを操作する度に記録され てゆきます。
使えます。 古いデータベースの組み込み を参 照してください。
データが消えてもかまわないのなら、 manage.py ユーティリティを使って、特 定のアプリケーションをリセットする SQL を発行できます:
manage.py reset appname
この操作で、 appname に関係したテーブルが削除され、再度作成されます。
データを削除したくないのなら、手作業で ALTER TABLE 文を実行せねばなりま せん。私達はいつもこの方法でやっています。というのも、データの扱いはとても 慎重にせねばならないので、私達は自動化を避けたいのです。とはいえ、データベー スの更新を部分的に自動化する機能を追加すべく現在作業中です。
いいえ。サポートしているのは単カラムの主キーだけです。
しかし、実践的には問題にはなりません。というのは、(unique_together モデ ルオプションを指定したり、直接データベースに制約を作ったりして) 他の制約を 課し、モデルレベルで一意性を強制できるからです。単カラムの主キーは admin イ ンタフェースをうまく稼働させるため、例えば編集や削除対象のオブジェクトを指 定する簡潔な手段として必要なのです。
私達は、テーブルの形式のようなデータベース固有のオプションに対応するために Django のコードに特殊なケースを追加したくないと考えています。こうしたオプショ ンを使いたければ、 SQL の初期データファイル を作成して、 その中で ALTER TABLE 文を使って自分の目的を実現してください。初期データ ファイルはデータベースの中で CREATE TABLE 文の後に実行されます。
例えば、 MySQL を使っていて、 MyISAM テーブルタイプを使いたい場合には、初期 データファイルを作成して、以下のような行を挿入します:
ALTER TABLE myapp_mytable ENGINE=MyISAM;
SQL の初期データファイル <initial-sql> でも説明していますが、 SQL ファイ ルには任意の SQL コードを入れられるので、SQL で行なえる変更なら何でも実現で きます。
Django に既知のメモリリークはありません。 Django プロセスがメモリをどんどん 消費して、いっこうに開放する気配がない場合、 DEBUG が True になって いないか調べてみてください。 DEBUG を True にすると、 Django は実行 した SQL 文の全てのコピーを保存するようになるからです。
(クエリは django.db.connection.queries で保存されます。 Django が実行している生の SQL クエリを見られますか? を参照してください。)
問題を解決するには、 DEBUG を False にしてください。
クエリリストを手動で消去するには、以下のように reset_queries() を呼び出 してください:
from django import db
db.reset_queries()
Aug 31, 2012