Django1.1リリースノート
2009年7月29日
Django 1.1へようこそ！
Django 1.1には、多くの気の利いた新機能、多くのバグ修正、およびDjango1.0からの簡単なアップグレードパスが含まれています。
1.1での後方互換性のない変更
Djangoには APIの安定性のポリシーがあります。 つまり、一般に、Django 1.0に対して開発したコードは、1.1に対して変更なしで引き続き機能するはずです。 ただし、バグを解決するために必要な場合は、後方互換性のない変更を行うことがあり、Django1.0とDjango1.1の間にはそのような（マイナーな）変更がいくつかあります。
Django 1.1にアップグレードする前に、次の変更が影響を与えないことを再確認し、影響がある場合はコードをアップグレードする必要があります。
制約名の変更
Django 1.1は、データベース制約名の生成に使用される方法を変更して、マシンのワードサイズに関係なく名前が一貫するようにします。 この変更は、一部のユーザーにとって後方互換性がありません。
32ビットプラットフォームを使用している場合は、オフフックです。 この変更の結果として違いは見られません。
ただし、64ビットプラットフォームのユーザーは、reset管理コマンドを使用するといくつかの問題が発生する可能性があります。 この変更の前は、64ビットプラットフォームは制約名に64ビットの16文字のダイジェストを生成していました。 例えば：
ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_5e8f10c132091d1e FOREIGN KEY ...この変更に続いて、すべてのプラットフォームは、ワードサイズに関係なく、制約名に32ビットの8文字のダイジェストを生成します。 例えば：
ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_32091d1e FOREIGN KEY ...この変更の結果、64ビットマシンで作成されたテーブルではreset管理コマンドを使用できなくなります。 これは、新しく生成された名前が過去に生成された名前と一致しないためです。 その結果、resetコマンドで作成されたSQLは無効になります。
64ビット制約で作成されたアプリケーションをリセットする必要がある場合は、resetを呼び出す前に、古い制約を手動で削除する必要があります。
テストケースがトランザクションで実行されるようになりました
Django 1.1はトランザクション内でテストを実行し、テストパフォーマンスを向上させます（詳細については、テストパフォーマンスの改善を参照してください）。
既存のテストでトランザクションの動作をテストする必要がある場合、テスト環境に関する無効な仮定に依存している場合、または特定のテストケースの順序が必要な場合、この変更はわずかに後方互換性がありません。
このような場合は、代わりに TransactionTestCase を使用できます。 これは、新しいロールバックアプローチによって明らかになったテストケースエラーを回避するための簡単な修正です。 長期テストでは、テストケースを修正するために書き直す必要があります。
SetRemoteAddrFromForwardedForミドルウェアを削除しました
便宜上、Django 1.0にはオプションのミドルウェアクラスdjango.middleware.http.SetRemoteAddrFromForwardedForが含まれていました。これは、一部のプロキシ構成で一般的に設定されるHTTP X-Forwarded-Forヘッダーに基づいてREMOTE_ADDRの値を更新しました。
このメカニズムは、汎用使用に十分な信頼性を持たせることができず、（反対のドキュメントにもかかわらず）Djangoに含まれているため、アプリケーション開発者はREMOTE_ADDRの値が「安全」であると見なす可能性があることが実証されています。 」または何らかの方法で認証のソースとして信頼できます。
直接的なセキュリティの問題ではありませんが、Django1.1リリースでこのミドルウェアを削除することにしました。 DeprecationWarningを上げる以外に何もしないクラスに置き換えられました。
このミドルウェアに依存している場合、最も簡単なアップグレードパスは次のとおりです。
- 削除前に存在していたコードを調べます。
- アップストリームプロキシで正しく機能することを確認し、特定のプロキシをサポートするように変更します（必要な場合）。
SetRemoteAddrFromForwardedForの修正バージョンを、独自のプロジェクトのミドルウェアとして導入します。
アップロードされたファイルの名前は後で利用できます
Django 1.0では、モデルがデータベースに保存される前に、モデルの FileField にアップロードおよび保存されたファイルがディスクに保存されていました。 これは、ファイルに割り当てられた実際のファイル名が保存前に利用可能であることを意味しました。 たとえば、モデルの保存前信号ハンドラーで使用できました。
Django 1.1では、ファイルはデータベースへのモデルの保存の一部として保存されるため、ディスクで使用される実際のファイル名は、モデルが保存される後まで信頼できません。
モデルフォームセットの保存方法の変更
Django 1.1では、 BaseModelFormSet がModelForm.save()を呼び出すようになりました。
モデルフォームセットの__init__でself.initialを変更した場合、またはBaseFormSetの内部_total_form_countまたは_initial_form_count属性に依存した場合、これは下位互換性がありません。 これらの属性はパブリックメソッドになりました。
joinフィルターのエスケープ動作を修正しました
：tfilter： `join` フィルターは、コネクターに渡されるリテラル値をエスケープしなくなりました。
これは、5つの特別なHTML文字の1つを含むリテラル文字列の特別な状況とは後方互換性がありません。 したがって、テンプレート:Fooを記述していた場合は、テンプレート:Fooを記述する必要があります。
以前の動作はバグであり、文書化されて期待されていたものとは反対でした。
永続的なリダイレクトとredirect_to()汎用ビュー
Django 1.1は、permanent引数をdjango.views.generic.simple.redirect_to()ビューに追加します。 redirect_toビューを「permanent」と呼ばれるフォーマット文字列キーで使用していた場合、これは技術的に後方互換性がありません。これはほとんどありません。
1.1で廃止された機能
1つの機能がDjango1.1で非推奨としてマークされています：
その管理者ビューを登録するために
AdminSite.root()を使用する必要はなくなりました。 つまり、URLconfに次の行が含まれている場合：(r'^admin/(.*)', admin.site.root),次のように変更する必要があります。
(r'^admin/', include(admin.site.urls)),
この機能の使用をコードからすぐに削除し始める必要があります。
AdminSite.rootは、Django 1.1で使用されている場合、PendingDeprecationWarningを発生させます。 この警告はデフォルトで非表示になっています。 Django 1.2では、この警告はDeprecationWarningにアップグレードされ、大音量で表示されます。 Django1.3はAdminSite.root()を完全に削除します。
非推奨のポリシーと戦略の詳細については、 Djangoのリリースプロセスを参照してください。
Django1.1の新機能
かなり：Django 1.0以降、1,290のコードコミットを行い、1,206のバグを修正し、約10,000行のドキュメントを追加しました。
Django1.1の主な新機能は次のとおりです。
ORMの改善
Djangoのオブジェクトリレーショナルマッパー（ORM）には、集約サポートとクエリ式という2つの主要な機能拡張が追加されました。
集約サポート
SQL集計クエリを実行できるようになりました（つまり、 DjangoのORM内からCOUNT()、MAX()、MIN()など）。 集計の結果を直接返すか、 QuerySet 内のオブジェクトに集計クエリの結果で注釈を付けるかを選択できます。
この機能は、新しい Aggregate（）および annotate（）メソッドとして利用可能であり、 ORM集約ドキュメントで詳細に説明されています。
モデルの改善
Djangoのモデルレイヤーにいくつかの機能が追加されました。
「管理されていない」モデル
Managed モデルオプションを使用して、Djangoがモデルのデータベーステーブルのライフサイクルを管理するかどうかを制御できるようになりました。 これはデフォルトでTrueに設定されます。つまり、Djangoはsyncdbに適切なデータベーステーブルを作成し、resetコマンドの一部としてそれらを削除します。 つまり、Djangoはデータベーステーブルのライフサイクルを管理します。
ただし、これをFalseに設定すると、このモデルのデータベーステーブルの作成または削除は自動的に実行されません。 これは、モデルが他の方法で作成された既存のテーブルまたはデータベースビューを表す場合に役立ちます。
詳細については、管理対象オプションのドキュメントを参照してください。
プロキシモデル
プロキシモデルを作成できるようになりました。これは、Pythonレベル（データベースレベルではなく）の動作のみを追加し、新しいテーブルで表されない既存のモデルのサブクラスです。 つまり、新しいモデルは、すべての実際のデータを格納する、いくつかの基礎となるモデルのプロキシです。
詳細はすべて、プロキシモデルのドキュメントに記載されています。 この機能は表面的にはアンマネージモデルと似ているため、ドキュメントにはプロキシモデルとアンマネージモデルの違いについての説明があります。
テストの改善
テストフレームワークにいくつかの注目すべき改善が加えられました。
テストパフォーマンスの改善
Djangoのテストフレームワークを使用して作成されたテストは、劇的に高速に実行されるようになりました（多くの場合、10倍も高速になります）。
これは、トランザクションベースのテストの導入によって達成されました。 django.test.TestCase を使用すると、テストは、フラッシュして再入力するのではなく、終了時にロールバックされるトランザクションで実行されるようになります。データベース。 これにより、ほとんどのタイプの単体テストで大幅なスピードアップが実現します。 詳細な説明とデータベースサポートに関するいくつかの重要な注意事項については、 TestCase および TransactionTestCase のドキュメントを参照してください。
クライアントの改善をテストする
テストクライアントには、小さな、しかし非常に便利ないくつかの改善が加えられました。
- テスト Client は、
follow引数を使用して Client.get（）および Client.post（）へのリダイレクトを自動的に追跡できるようになりました。 これにより、リダイレクトを発行するビューのテストが簡単になります。 - テストクライアントから返された応答でテンプレートコンテキストを取得するのが簡単になりました。
request.context[key]としてコンテキストにアクセスするだけです。request.contextをコンテキストのリストとして扱う古い方法（継承チェーン内のレンダリングされたテンプレートごとに1つ）は、必要に応じて引き続き使用できます。
新しい管理機能
Django 1.1は、Djangoの管理インターフェースにいくつかの気の利いた新機能を追加します。
変更リストの編集可能なフィールド
新しい list_editable 管理オプションを使用して、管理リストビューでフィールドを編集可能にすることができるようになりました。 これらのフィールドはリストページにフォームウィジェットとして表示され、まとめて編集および保存できます。
管理者の「アクション」
モデルのグループに対して何らかのアクションを一括で実行できる管理アクションを定義できるようになりました。 ユーザーは、変更リストページでオブジェクトを選択し、選択したすべてのオブジェクトにこれらの一括アクションを適用できます。
Djangoには、オブジェクトのグループを一挙に削除するための事前定義された管理アクションが1つ付属しています。
条件付きビュー処理
Djangoは、標準のETagおよびLast-Modified HTTPヘッダーを使用して、条件付きビュー処理をより適切にサポートするようになりました。 これは、より安価な条件をテストすることで、ビュー処理を簡単に短絡できることを意味します。 多くのビューでは、これにより速度が大幅に向上し、帯域幅が減少する可能性があります。
URL名前空間
Django 1.1は、URL「名前空間」の導入により、名前付きURLパターンを改善します。
つまり、この機能を使用すると、同じアプリケーションの同じURLグループをDjango URLConfに複数回含めることができ、逆解決を実行するときに使用されるさまざまな（場合によってはネストされた）名前付きプレフィックスが使用されます。 つまり、Djangoの管理インターフェースのような再利用可能なアプリケーションは、URLの競合なしに複数回登録される可能性があります。
詳細については、 URL名前空間の定義に関するドキュメントを参照してください。
GeoDjango
Django 1.1では、 GeoDjango （つまり、 django.contrib.gis）には、いくつかの新機能があります。
- 空間バックエンドとしての SpatiaLite – SQLiteの空間データベース–のサポート。
- 地理的集合体（
Collect、Extent、MakeLine、Union）およびF式。 - 新しい
GeoQuerySetメソッド：collect、geojson、およびsnap_to_grid。 GEOSGeometryオブジェクトの新しいリストインターフェイスメソッド。
詳細については、GeoDjangoのドキュメントを参照してください。
その他の改善
Django1.0以降に導入されたその他の新機能と変更点は次のとおりです。
- CSRF保護ミドルウェアは2つのクラスに分割されています–
CsrfViewMiddlewareは着信要求をチェックし、CsrfResponseMiddlewareは発信応答を処理します。 結合されたCsrfMiddlewareクラス（両方を実行）は下位互換性のために残りますが、CSRF処理がいつどこで行われるかをきめ細かく制御できるようにするために、分割クラスの使用が推奨されます。 reverse()とそれを使用するコード（{% url %}テンプレートタグなど）は、管理URLがinclude(admin.site.urls)を介して設定されている場合、Djangoの管理サイトのURLで機能するようになりました（送信admin.site.rootビューへの管理者リクエストは引き続き機能しますが、このように構成されている場合、管理者のURLは「元に戻せません」）。- DjangoURLconfモジュールの
include()関数は、モジュール名に加えて、URLパターンのシーケンス（patterns()によって生成される）を受け入れることができるようになりました。 - Djangoフォームのインスタンス（フォームの概要を参照）には、
hidden_fields()とvisible_fields()の2つの追加メソッドがあり、非表示のリストを返します。つまり、 [X162X ] –およびフォーム上の表示フィールド。 redirect_to汎用ビューは、追加のキーワード引数permanentを受け入れるようになりました。permanentがTrueの場合、ビューはHTTP永続リダイレクト（ステータスコード301）を発行します。Falseの場合、ビューはHTTP一時リダイレクトを発行します（ステータスコード302）。DateFieldおよびDateTimeFieldに、新しいデータベースルックアップタイプ[week_day）が追加されました。 このタイプのルックアップは、1（日曜日）から7（土曜日）までの数値を受け入れ、フィールド値がその曜日と一致するオブジェクトを返します。 詳細については、ルックアップタイプの完全なリストを参照してください。- Djangoのテンプレート言語の
{% for %}タグは、オプションの{% empty %}句を受け入れるようになりました。これは、{% for %}が空のシーケンスをループするように要求されたときに表示されます。 この例については、組み込みテンプレートタグのリストを参照してください。 - ：djadmin： `dumpdata` 管理コマンドは、引数として個々のモデル名を受け入れるようになり、特定のモデルからのみデータをエクスポートできるようになりました。
- 新しい：tfilter： `safeseq` テンプレートフィルターがあります。これはリストの：tfilter：` safe` と同じように機能し、リスト内の各アイテムを安全としてマークします。
- キャッシュバックエンドは、
incr()およびdecr()コマンドをサポートして、キャッシュキーの値をインクリメントおよびデクリメントするようになりました。 アトミックなインクリメント/デクリメントをサポートするキャッシュバックエンド（特にmemcachedバックエンド）では、これらの操作はアトミックであり、非常に高速です。 - Djangoは、この目的で使用される標準の
REMOTE_USER環境変数をサポートする新しい認証バックエンドを介して、 Webサーバーに認証を簡単に委任できるようになりました。 - 新しい django.shortcuts.redirect（）関数があり、オブジェクト、ビュー名、またはURLを指定してリダイレクトを簡単に発行できます。
postgresql_psycopg2バックエンドは、ネイティブPostgreSQL自動コミットをサポートするようになりました。 これは高度なPostgreSQL固有の機能であり、読み取りが多い特定のアプリケーションを大幅に高速化できます。
次は何ですか？
少し休憩してから、Django 1.2の作業を開始します。疲れた人のために休むことはありません！ 支援したい場合は、1.2リリースに向けた進捗状況を含むDjango開発の議論が、 django-developers メーリングリストと[X201Xの#django-dev IRCチャネルで毎日行われます。 ] 。 気軽にディスカッションに参加してください！
Djangoのオンラインドキュメントには、Djangoに貢献する方法に関するヒントも含まれています。
コードの開発、ドキュメントの作成、チケットのトリアージ、提案されたバグ修正のテストの支援など、あらゆるレベルでの貢献はいつでも歓迎され、高く評価されています。
そして、それはそうです。
