Django についてよくある質問

revision-up-to:	7209 (0.97pre SVN)

Contents

Django についてよくある質問

Django は極めて実践的な要請のもとで成長してきました。 Web 新聞を発行している WorldOnline では、効果的な Web アプリケーションを、ジャーナリズムとして成立する締め切りに間に合うように構築せねばなりません。変転の激しいニュースルームにおいて、 WorldOnline は複雑な Web アプリケーションをコンセプトから立ち上げ公開にもっていくまでの時間を唯一の課題としているのです。

同時に、 WorldOnline の Web 開発者たちは、こと Web 開発の王道に関しては一貫して完璧主義者です。

こうした理由から Django は Web アプリケーションをただ素早く作れるだけではなく、Web 開発の王道に従って作成できるように設計されているのです。 2003 年、WorldOnline の開発者 (Adrian Holovaty と Simon Willison) は PHP に見切りをつけ、 Python による Web 開発に取り組みはじめました。集約的で高い双方向性を備えた Lawrence.com のようなサイト開発の中で、彼らは Web アプリケーションをより迅速に開発できるように、サイトのコードから汎用の Web 開発フレームワークを切り出し、 2 年近くの間ずっと改良を加えながら使い込んできました。

2005 年の夏、 World Online はこれまでの開発の成果を Django としてオープンソース化する決定を下しました。 Django は Apache, Python, そして PostgreSQL をはじめとする様々なオープンソースプロジェクトなしでは実現しませんでした。そして今、私達はオープンソースコミュニティに多少なりともお返しできることにワクワクしているのです。

"Django" とはどういう意味で、どのように発音するのですか？

Django は 1930 年代から 1950 年代初期にかけて活躍したジプシージャズのギタリスト、ジャンゴ・ラインハルト (Django Reinhardt) にちなんで名付けられました。今日では、ジャンゴは歴史上最も優れたギタリストの一人に数えられています。

彼の曲を聞いてみてください。きっと気に入ることでしょう。

Django は JANG-oh ('a' は伸ばす) と発音します。韻は FANG-oh と同じです。 "D" は発音しません。

正しい発音の音声ファイルを作成してあるので参考にしてください。

Django は安定していますか？

はい。 World Online は私達は 3 年以上にわたって Django を使ってきました。 Django で構築したサイトは、これまでに 100 万ヒット／時を超えるトラフィックスパイクに見舞われたことがあり、何度もスラッシュドット効果を喰らっています。そうですね。きわめて安定です。

Django はスケールしますか？

はい。ハードウェアというものは、開発時間に比べて安いものですし、それゆえ Django はユーザが投入可能なハードウェアをできるだけ活用するべく設計されています。

Django は「レイヤ間で何も共有しない (shared-nothing)」アーキテクチャなので、データベースサーバ、キャッシュサーバ、 Web/アプリケーションサーバのどのレベルにハードウェアを追加してもかまいません。

Django はアプリケーションレイヤからのデータベースレイヤを分離し、シンプルながら強力なキャッシュフレームワークを備えています。

Django の舞台裏には誰がいるのですか？

Django は米国カンザス州ローレンス (Lawrence, Kansas, USA) のとある新聞の Web 部門である World Online で開発されました。

Adrian Holovaty

Adrian はジャーナリズムのバックグラウンドを持った Web 開発者です。彼は 2 年半の間 World Online のリードプログラマを勤め、その間に Django を開発して World Online サイトを実装しました。現在彼は washingtonpost.com で働いており、データベースをバックエンドにしたリッチな情報サイトの構築に携わるかたわら、 Django の開発も継続して監督しています。 Adrian は (Django Reinhardt スタイルの) ギター演奏や、 chicagocrime.org のようなサイドプロジェクトのハッキング中が好きです。シカゴ在住です。

IRC では、 adrian_h と名乗っています。

Jacob Kaplan-Moss

Jacob はカリフォルニアから来た男で、コーディングと料理に同じだけ時間を割くという生意気野郎です。彼は World Online の開発を指揮しており、同時に様々な優れたサイドプロジェクトを積極的にハックしています。彼は Python-ObjC バインディングに貢献したことがあり、 Python で Tivo アプリケーションを書く方法を見つけた最初の男でもあります。最近彼は PSP で動く Python にどっぷりはまっています。カンザス州ローレンス在住です。

IRC では jacobkm と名乗っています。

Simon Willison

Simon はイングランドから来た尊敬すべき Web 開発者です。彼は World Online で 1 年間のインターンシップを過ごし、その間に Adrian とともに Djang をスクラッチから開発しました。彼はまれに見る情熱家の英国人で、 Web 開発の王道について確固たる信念を持っており、多くの読者をもつ Web 開発に関する blog, http://simon.incutio.com を何年もの間運営してきました。 Simon は現在 Yahoo UK で働いており、「Hacker Liason」の称号を得ています。イングランド在住です。

IRC では SimonW と名乗っています。

Wilson Miner

Wilson のデザイン術は、私達をロックスターに仕立てあげてしまいます。日中は Apple のインタラクティブデザイナを勤めています。でも Apple で何をやっているか聞いてはいけません。そんなことをしたら、彼にシメられちゃいますよ。サンフランシスコ在住です。

IRC では wilsonian と名乗っています。

どんなサイトが Django を使っているのですか？

Django wiki には Django で作られたサイト一覧という特集ページがあり、日々内容が増えています。自分の Django サイトもどうぞ自由に追加してください。

Django は MVC フレームワークのようですが、コントローラ (Controller) を「ビュー (view)」と呼び、ビュー (View) を「テンプレート (template)」と呼んでいます。どうして標準的な呼び方をしないのですか？

そうですね、呼び名には議論の余地があるでしょう。

我々の MVC の解釈では、「ビュー」とはユーザに提示されるデータのことをいいます。つまり、データが どのように見えるか ということではなく、むしろ どのデータを提示するか です。ビューは どのデータを見せるか であり、 どう見せるか ではありません。この二つは明らかに違います。

というわけで、我々のケースでは、「ビュー」は特定の URL に対する Python コールバック関数になります。なぜなら、コールバック関数はどのデータを提示するかを決めているからです。

さらに、テンプレートによってコンテンツとプレゼンテーションの分離がはっきりしています。Django では、ビューはどのデータを提示するかを決めていますが、ビューは通常、 どのように データを提示するかをテンプレートに委ねます。

では、「コントローラ」はどこに入るのでしょうか。 Django の場合、おそらくフレームワーク、すなわち URL 設定にしたがってリクエストを適切なビューに送信する機構自体がコントローラにあたるといえるでしょう。

略語がお好みなら、 Django を "MTV" フレームワークと呼んでもよいでしょう。つまり、モデル (Model)、テンプレート (Template)、そしてビュー (View) です。こっちの方がよりしっくりきます。

最後に、結局重要なのは問題を解決することです。そして、呼び方は何であれ、 Django はわれわれにとって最も理にかなった方法で問題を解決しているのです。

<フレームワーク X> には <機能 Y> があります -- どうして Django にないのですか？

世の中には他にも素晴らしい Web フレームワークがあるのは良く知っていますし、必要であればそこからアイデアを借りるのにやぶさかではありません。とはいえ、 Django はまさに私達が旧態然の Web フレームワークに不満だったからこそ開発されたのであって、「<Framework X> ができるから」という理由は Django に機能を追加する十分な理由にはならないということに注意して下さい。

なぜ既存の Python ライブラリを使わずスクラッチで Django を作ったのですか？

Django を書き始めた約 2 年前、 Adrian と Simon は少し時間を取って当時利用できた様々な Python ウェブフレームワークを試してみました。

その結果、十分な出来具合のものは一つもないという結論に達したのです。

私達は好みにうるさいのです。(締め切りを守る) 完璧主義者と呼んでもいいでしょう。

これまでずっと、私達は自分たちがすでに実装済みの機能を実現するオープンソースライブラリに出会ってきました。そうしたライブラリに、他の人達が同じ問題を同じ方法で解決しようとしているのを見ては元気づけられる思いでしたが、自分たちのコードの外側に組み込むにはもう遅すぎました。私達はすでにいくつもの運用環境で独自のフレームワークを書き上げ、テストし、実装してきており、できたコードは快適なまでに要求を満たしていたのです。

一方、ほとんどの場合、既存のフレームワークやツールは明らかにある主の根本的、致命的な欠陥があり、私達を神経質にさせました。結局、私達の哲学に 100% 合うものはなかったのです。

繰り返していいますが、私達は好みにうるさいのです。

私達の設計哲学は設計哲学のページに詳しく書いてあります。

かっこいい「スクリーンキャスト」か何かがありますか？

現在進行中だということだけは断言できます。がしかし、私達はまだ Django を改良している真最中なので、現状ではなく、 Django 1.0 になったときの最終的な状態を反映させたいと思っています。言い方を変えれば、 Django API はまだ変化するかもしれないので、それまではスクリーンキャストにまださほどエネルギーを使いたくないということです。

Django はコンテンツ管理システム (CMS) なのでしょうか?

いいえ。 Django は CMS ではありませんし、いわゆる「ターンキーシステム」のようなものでもありません。 Django は Web フレームワークであり、 Web サイトを構築する際に使えるプログラミングツールにすぎません。

例えば、 Django を Drupal のようなシステムと比較するのは無意味です。というのも、 Django はまさに Drupal のようなシステムを作るためのものだからです。

もちろん、 Django の自動 admin サイトはすばらしく、開発時間の節約になります。しかし、 admin サイトは Django というフレームワークのいちモジュールに過ぎません。もっと言うなら、 Django が「 CMS 的な」アプリケーションを作成する上でとりわけ便利な点を持ってはいますが、そのことが「 CMS 的でない」アプリケーションの開発に向いていない、なんてことにつながったりはしないのです。

いつになったら Django 1.0 をリリースするのですか？

短い答え: Django の API 構成に問題がなくなり、 "1.0" に必要と考えている全ての機能を追加し、以前のバージョンとの互換性を維持できるようになった時点、です。

Django の magic-removal ブランチのマージにより、Django 1.0 への道のりは大分進みました。

1.0 になっていないからといってがっかりしないで下さいね。

どうやれば Django のドキュメントをダウンロードしてオフラインで読めますか？

Django のドキュメントは Django tarball リリースの docs ディレクトリにあります。これらのドキュメントは ReST (ReStructuredText) 形式で書かれており、各テキストファイルが Django 公式サイトのページに対応しています。

ドキュメントはバージョン管理システム下にあるので、コードの変更状況を閲覧するのと同じようにしてドキュメントの変更状況を閲覧できます。

技術的には、 Django サイトのドキュメントは最新の開発版の ReST ドキュメントから生成されます、従って、 Django サイトにあるドキュメントの方が、最新の Django リリースのドキュメントよりも多くの情報を提供していることがあります。

Django 開発者はどこで雇えますか？

求職中の開発者リストには、喜んであなたの力になってくれる Django 開発者のリストがあります。

また、求人を http://www.gypsyjobs.com/ に出してみてもよいかもしれません。

インストールに関する質問

どこから始めたらいいですか？

コードをダウンロードしてください。

Django をインストールしてください (インストールガイドを読んで下さい)。

チュートリアルをやってみてください。

他のドキュメントにも目を通して下さい。何かトラブルに出会ったら、質問してみましょう。

"install a later version of setuptools" の解決方法は？

Django 配布物に入っている ez_setup.py を実行してください。

Django を動かすには何が必要？

Django を動かすには Python 2.3 以降が必要です。Django の初歩的な利用では、それ以外の Python ライブラリは不要です。

開発環境を使う場合、つまり Django を試したいだけの場合は、 Web サーバを別にインストールしておく必要はありません。 Django には軽量な開発用サーバがついてきます。運用環境には Apache 2 と mod_python を勧めますが、 Django は WSGI 仕様に従っているので、様々なサーバフラットフォームで動作します。

Django をデータベースと合わせて使うならデータベースエンジンも必要です。我々は PostgreSQL ファンなので PostgreSQL をお勧めしますが、 MySQL や SQLite 3, Oracle もサポートしています。

Python 2.3 を使うのは、 2.5 のような新しいバージョンを使うよりも不利ですか？

いいえ。 Django 自体は 2.3 以降全てのバージョンの Python で動作保証されています。

もちろん、 2.3 よりも新しい Python を使っていれば、自分のコードに新しい Python の機能を取り込めますし、Python 自体の改良によってもたらされた高速化や最適化の恩恵を受けられます。ただし、 Django フレームワーク自体は、 2.3 でも 2.4 や 2.5 でも同じように動作します。

mod_python を使わねばならないのでしょうか？

実際に運用する上では mod_python を使うよう勧めていますが、 Django は WSGI と呼ばれる構成を使っているため、必ずしも mod_python を使わねばならないわけではありません。 Django は WSGI を有効化したサーバと通信できます。他にも、 mod_python を使わない構成として、 FastCGI, SCGI, AJP があります。詳しい情報は FastCGI, SCGI, AJP で Django を使うを参照してください。

また、その他の運用方法についてはサーバ構成に関する wikiページを参照してください。

Django を試してみたり、ローカルのコンピュータ上で開発するだけなら、 Django に付いてくる開発用 Web サーバを使ってください。

Windows への mod_python のインストール方法は？

Python 2.4 を使っているなら Python 2.4 向け mod_python の win32 ビルドを入手してください。

Python 2.4 の場合、 Windows での Django HOWTO も参照してください。

Python 2.3 なら、 http://www.modpython.org/ から mod_python を取って来て、 Running mod_python on Apache on Windows2000 を読んで下さい。

また、 (Windows に限らず) guide to getting mod_python working を読んで下さい。

Django は共有ホスティングサービス (TextDrive や Dreamhost) で動きますか？

Django を使える Web ホストのページをごらん下さい。

公式リリースと開発版のどちらを使うべきなのでしょうか？

Django の開発者達は毎日 Django 改良を重ねており、壊れたコードをチェックインしないよう上手く計らっています。私達は自分のサーバに (Subversion レポジトリ上の) 開発中のコードを直接使っており、安定に運用できています。このことを考えると、一般論として。「公式の」リリースよりはより多くの機能と少ないバグを持つ最新の開発版を使うように勧めます。

Django を使う上での質問

DJANGO_SETTINGS_MODULE の import がらみのエラーがでるのはなぜ？

以下の点を確認してください:

環境変数 DJANGO_SETTINGS_MODULE が完全指定の Python モジュール名になっていますか (たとえば "mysite.settings")。

設定モジュールは sys.path の上にありますか (import mysite.settings はうまくいきますか)。

(言うまでもなく) モジュールに構文エラーはありませんか。
mod_python を使っていて、Django リクエストハンドラは 使っていない のなら、 SetEnv に関わる mod_python のバグを回避する必要があります。 Django から何らかのモジュールを import する前に、以下のコードを実行してください:
os.environ.update(req.subprocess_env)
(req は mod_python のリクエストオブジェクトです)。

テンプレート言語を好きになれません。どうしても使わないとだめですか？

私達はこのテンプレートエンジンを chunky bacon 以来の傑作だと思っているんですが、テンプレート言語の選択というものは宗教に近いものがあるということは認識しています。 Django では、テンプレート言語に対する制限はなんらありません。ですから、 ZPT や Cheetah などを使いたいのなら、それは自由です。

付属のモデル／データベースレイヤを使わねばならないのですか？

いいえ、テンプレートシステムと同様、モデル／データベースレイヤはフレームワークの他の部分と脱カップリングしています。

唯一の例外: 別のデータベースライブラリを使った場合には、 Django の自動生成 admin サイトを利用できなくなります。 admin だけは Django のデータベースレイヤとカップリングしています。

画像やファイルのフィールドの使い方は？

モデルで FileField や ImageField を使うには、いくつかのステップを踏む必要があります:

設定ファイル内で MEDIA_ROOT を指定します。この値は、Django がアップロードされたファイルを置く場所にします (パフォーマンス上の理由から、ファイルをデータベースに置くことはありません)。 MEDIA_URL をそのディレクトリの公開 URL にします。ディレクトリは Web サーバのユーザアカウントに対して書き込み可能にしておかねばなりません。

モデルに FileField や ImageField を追加し、 upload_to オプションを定義して、 MEDIA_ROOT のどのサブディレクトリにファイルをアップロードさせるのかを Django に教えます。

データベースにい保存されるのは、ファイルの (MEDIA_ROOT からの相対で表した) パスだけです。 Django の提供している便宜関数 get_<filename>_url を使うことになるでしょう。例えば、 mug_shot という名前の ImageField があるとすると、テンプレートで画像の URL を指定するには {{ object.get_mug_shot_url }} のようにします。

データベースとモデルに関する質問

Django が実行している生の SQL クエリを見られますか？

まず、 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 文が入ります。クエリはアプリケーションがデータベースを操作する度に記録されてゆきます。

既存のデータベースで Django を使えますか？

使えます。古いデータベースの組み込みを参照してください。

モデルを変更した場合のデータベースの更新方法は？

データが消えてもかまわないのなら、 manage.py ユーティリティを使って、特定のアプリケーションをリセットする SQL を発行できます:

manage.py reset appname

この操作で、 appname に関係したテーブルが削除され、再度作成されます。

データを削除したくないのなら、手作業で ALTER TABLE 文を実行せねばなりません。私達はいつもこの方法でやっています。というのも、データの扱いはとても慎重にせねばならないので、私達は自動化を避けたいのです。とはいえ、データベースの更新を部分的に自動化する機能を追加すべく現在作業中です。

Django のモデルは複数カラムにわたる主キーをサポートしていますか？

いいえ。サポートしているのは単カラムの主キーだけです。

しかし、実践的には問題にはなりません。というのは、(unique_together モデルオプションを指定したり、直接データベースに制約を作ったりして) 他の制約を課し、モデルレベルで一意性を強制できるからです。単カラムの主キーは admin インタフェースをうまく稼働させるため、例えば編集や削除対象のオブジェクトを指定する簡潔な手段として必要なのです。

テーブル形式を MyISAM に指定するなど、データベース固有のオプションを CREATE TABLE 文に追加したいのですが、どうすればよいですか？

私達は、テーブルの形式のようなデータベース固有のオプションに対応するために Django のコードに特殊なケースを追加したくないと考えています。こうしたオプションを使いたければ、 SQL の初期データファイルを作成して、その中で ALTER TABLE 文を使って自分の目的を実現してください。初期データファイルはデータベースの中で CREATE TABLE 文の後に実行されます。

例えば、 MySQL を使っていて、 MyISAM テーブルタイプを使いたい場合には、初期データファイルを作成して、以下のような行を挿入します:

ALTER TABLE myapp_mytable ENGINE=MyISAM;

SQL の初期データファイルでも説明していますが、 SQL ファイルには任意の SQL コードを入れられるので、SQL で行なえる変更なら何でも実現できます。

Django がメモリリークを起こしているのですが、なぜですか？

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()

admin サイトに関する質問

ログインできません。正しいユーザ名とパスワードを入力したのに、エラーメッセージも出ず再度ログインページが表示されるのです。

Django の発行するクッキーのドメインと、ブラウザに格納されたドメインが一致していないため、ログインクッキーが正しく設定されないからです。以下の二つの対策を試してみて下さい:

admin 設定ファイルの SESSION_COOKIE_DOMAIN とお使いのドメインが一致するように設定してください。例えば、ブラウザで "http://www.mysite.com/admin/" にアクセスするようになっているのなら、 "myproject.settings" には SESSION_COOKIE_DOMAIN = 'www.mysite.com' と設定せねばなりません。

ブラウザによっては (Firefox?) ドットの入っていないドメインからのクッキーを受け取ろうとしないようです。admin を "localhost" などのようなドットを含まないドメインで実行しているのなら、"localhost.localdomain" や "127.0.0.1" のように指定してアクセスしてください。また、 SESSION_COOKIE_DOMAIN もそれに合わせて変更してください。

ログインできません。正しいユーザ名とパスワードを入力したところ、「正しいユーザ名とパスワードを入力してください」というエラーメッセージの表示されたログインページが表示されます。

ユーザネームとパスワードが本当に正しいのなら、ユーザアカウントが is_active で、かつ is_staff が True になっているか確かめて下さい。 admin サイトにアクセスできるのは、これら二つのフィールドが共に True であるユーザだけです。

キャッシュミドルウェアに admin サイトをキャッシュさせなくするにはどうすればよいですか？

CACHE_MIDDLEWARE_ANONYMOUS_ONLY 設定を True にしてください。詳しくはキャッシュのドキュメントを参照してください。

admin で、フィールドの値を、オブジェクトを最後に編集したユーザの指定した値と同じにする方法は？

現時点では、 Django はこの操作を行う正規の方法を提供していません。しかしこの要望はよく出ているので、どうやって実装するかを議論しているところです。問題は、(現在のユーザを判定するのに) モデルレイヤと admin レイヤとリクエストレイヤをカップリングしたくないという点にあります。これは難しい問題です。

solution that doesn't require patching Django というハックを提供している人もいますが、これは正規の方法ではなく、将来うまく働かなくなる可能性があります。

admin で、オブジェクトを作成したユーザだけがオブジェクトを編集できるようにアクセスを制限する方法は？

一つ前の質問の答えを見て下さい。

開発サーバでは admin サイトの CSS や画像がうまく表示されるのに、 mod_python を使うと表示されません。

「mod_python で Django を使う」というドキュメントの admin ファイルの提供

"list_filter" に ManyToManyField を入れたのに、フィルタが表示されません。

Django が ManyToManyField に対してフィルタを表示するのはオブジェクトが二つ以上のときだけです。

例えば、 list_filter に sites が入っており、データベースにたった一つしかサイトが登録されていなければ、 "Site" フィルタは表示されません。この状況では、サイトによるフィルタは無意味だからです。

admin インタフェースの機能をカスタマイズする方法は？

方法はいくつかあります。Django が自動生成する add/change フォームを利用して楽をしたければ、モデルの class Admin の js パラメタを使ってページに任意の JavaScript モジュールを貼り付けてください。パラメタは文字列で表した URL からなるリストで、 admin フォームに <script> タグを使って取り込む JavaScript モジュールを指しています。

単に自動生成されるフォームをいじる以上の柔軟さが必要な場合には、 admin 用のカスタムビューを書いて下さい。 admin はそれ自体 Django で作られており、カスタムのビューを書いて認証システムやパーミッションのチェックにフックを掛け、必要な処理を行えます。

admin のルック & フィールをカスタマイズしたいのなら、次の質問に進んで下さい。

動的に生成される admin サイトがみっともありません！変更方法は？

私達は好きなんですが、そうは思わないのなら、 CSS スタイルシートや画像ファイルを編集して、 admin サイトのプレゼンテーションを変更できます。サイトはセマンティックな HTML を使って書かれているので、やりたい変更は全て CSS スタイルシートの編集で実現できます。てほどきに admin で使われているCSS のガイドを用意してあります。

パスワードハッシュを編集せずにユーザを作成する方法は？

admin サイトでユーザを作成したいのなら、 Django の開発版を使ってください。この問題は 2006 年 8 月 4 日に修正されたので、それ以降のバージョンが必要です。

ユーザの作成には Python API も利用できます。詳しくはユーザの作成を参照してください。

コードへの貢献

Django プロジェクトにコードを寄贈したいんですが、どうすればよいですか？

よくぞ聞いてくれました！まさにこの質問に答えるためのドキュメントを用意してあります。 Django プロジェクトへの貢献という文書です。

何週間も前にチケットシステムにバグフィクスを提出したんですが。何で私のパッチを無視するんですか？

心配しないでください。無視しているわけではないんですよ！

まずは「チケットを無視する」ことと「まだチケットを検討していない」ことの違いを御理解ください。 Django のチケットシステムにはオープン状態のチケットが何百もあり、エンドユーザの使い勝手に与えるインパクトも様々です。そのため、 Django の開発者達はチケットをレビューして、優先順位を決めねばならないのです。

また、あなたのリクエストを Django に取り込まないとはっきりした場合、チケットを無視したりはせず、必ずクローズします。従って、チケットがまだオープンの状態なら、リクエストは無視されているのではなく、いま一時的にリクエストに目を通す時間を取れないということにすぎないのです。