Django1.5リリースノート

2013年2月26日

Django 1.5へようこそ！

これらのリリースノートには、の新機能と、Django1.4以前のバージョンからアップグレードするときに注意が必要な後方互換性のない変更が含まれています。また、非推奨プランで詳しく説明されているいくつかの機能を削除し、いくつかの機能の非推奨プロセスを開始しました。

概要

Django 1.5の最大の新機能は、構成可能なユーザーモデルです。 Django 1.5より前は、Djangoの認証フレームワーク（ django.contrib.auth ）を使用したいアプリケーションは、Djangoの「ユーザー」の定義を使用することを余儀なくされていました。 Django 1.5では、Userモデルを自分で作成したモデルと交換できるようになりました。これは、既存のUserモデルの単純な拡張である可能性があります（たとえば、TwitterまたはFacebook IDフィールドを追加することができます）。または、Userをサイト用に完全にカスタマイズされたものに完全に置き換えることができます。

Django 1.5は、 Python3サポートを備えた最初のリリースでもあります。このサポートはまだ本番環境に対応しているとは見なされていないため、「実験的」とラベル付けしていますが、アプリのPython3への移植を開始するための準備はすべて整っています。次のリリースであるDjango1.6は、予約なしでPython3をサポートします。

Django1.5のその他の注目すべき新機能は次のとおりです。

モデルのフィールドのサブセットの保存のサポート- Model.save（）は、update_fields引数を受け入れるようになりました。これにより、データベースに書き戻すフィールドを指定できます。 save()を呼び出します。これは、同時実行性の高い操作に役立ち、パフォーマンスを向上させることができます。
新しい StreamingHttpResponse 応答クラスを介したストリーミング応答のサポートが向上しました。
GeoDjango はPostGIS2.0をサポートするようになりました。
… もっと; 以下を参照。

可能な限り、 API安定性ポリシーに従って下位互換性のある方法で新機能を導入しようとしています。ただし、以前のリリースと同様に、Django1.5にはいくつかのマイナーな後方互換性のない変更が付属しています。以前のバージョンのDjangoからアップグレードする人は、そのリストを注意深く読む必要があります。

注目に値する非推奨の機能の1つは、「新しいスタイル」の：ttag： `url` タグへの移行です。 Django 1.3より前は、{% url myview %}のような構文が正しく解釈されていませんでした（Djangoは"myview"を、myviewという名前のテンプレート変数ではなく、ビューのリテラル名と見なしていました）。 Django 1.3以降では、{% load url from future %}構文が導入され、myviewが変数と見なされる修正された動作が導入されました。

結果として、テンプレートで{% load url from future %}を使用していない場合は、{% url myview %}などのタグを{% url "myview" %}に変更する必要があります。 が{% load url from future %}を使用してだった場合は、Django1.5でその行を削除するだけです。

Pythonの互換性

Django1.5にはPython2.6.5以降が必要ですが、 Python2.7.3以降を強くお勧めします。 Python2.5以下のサポートは終了しました。

今日のほとんどのオペレーティングシステムベンダーはデフォルトバージョンとしてPython2.6以降を出荷しているため、この変更は少数のDjangoユーザーにのみ影響するはずです。ただし、Python 2.5をまだ使用している場合は、Pythonバージョンをアップグレードできるようになるまで、Django1.4に固執する必要があります。サポートポリシーに従い、Django1.4はDjango1.6がリリースされるまでセキュリティサポートを受け続けます。

Jythonの最新リリースは現在Python2.6をサポートしていないため、Django1.5はJythonの最終リリースでは実行されません。ただし、Jythonは現在2.7をサポートするアルファリリースを提供しており、Django1.5はそのアルファリリースをサポートしています。

Python3のサポート

Django 1.5では、Python 3、特にPython3.2以降のサポートが導入されています。これは、シングルコードベースの形式で提供されます。 Python3に別のバージョンのDjangoをインストールする必要はありません。つまり、Python 2のみ、Python 3のみ、または両方のプラットフォームをサポートする単一のアプリケーションを対象としたアプリケーションを作成できます。

ただし、現時点では、このサポートに「実験的」というラベルを付けています。自動テストスイートを介して広範なテストを受けていますが、実際のテストはほとんど受けていません。バグを排除するために最善を尽くしましたが、Djangoの考えられるすべての使用法を網羅したかどうかはわかりません。

Djangoの一部の機能は、Python 3にまだ移植されていないサードパーティのソフトウェアに依存しているため、利用できません。

MySQLデータベースバックエンド（MySQLdbに依存）
ImageField （PILに依存）
LiveServerTestCase （Selenium WebDriverに依存）

さらに、Djangoは単なるWebフレームワークではありません。これは、プラグ可能なコンポーネントのエコシステムです。現時点では、Python 3に移植されているサードパーティアプリケーションはほとんどないため、実際のアプリケーションがPython3ですべての依存関係を満たしているとは考えられません。

したがって、Python3での本番環境ではDjango1.5を使用しないことをお勧めします。代わりに、この機会を利用して、アプリケーションをPython3に移植し始めてください。プラグ可能なコンポーネントの作成者の場合は、今すぐ移植を開始することをお勧めします。

次のリリースであるDjango1.6では、Python3のファーストクラスの本番環境対応サポートを提供する予定です。

Django1.5の新機能

構成可能なユーザーモデル

Django 1.5では、ユーザー関連データのストアとして独自のモデルを使用できるようになりました。プロジェクトに30文字を超えるユーザー名が必要な場合、ユーザー名を名/姓以外の形式で保存する場合、またはカスタムプロファイル情報をユーザーオブジェクトに配置する場合は、これを実行できます。

ユーザーモデルを参照するサードパーティの再利用可能なアプリケーションがある場合は、ユーザーインスタンスを参照する方法にいくつかの変更を加える必要がある場合があります。また、アプリケーションが依存するユーザーモデルの特定の機能を文書化する必要があります。

詳細については、カスタムユーザーモデルに関するドキュメントを参照してください。

モデルのフィールドのサブセットの保存のサポート

メソッド Model.save（）には、新しいキーワード引数update_fieldsがあります。この引数を使用することにより、モデルのフィールドの選択リストのみを保存することができます。これは、パフォーマンス上の理由から、または同時変更の上書きを回避しようとする場合に役立ちます。

遅延インスタンス（.only()または.defer()によってロードされたインスタンス）は、ロードされたフィールドのみを自動的に保存します。ロード後にフィールドが手動で設定されている場合、そのフィールドも保存時に更新されます。

詳細については、 Model.save（）のドキュメントを参照してください。

ストリーミング応答の明示的なサポート

Django 1.5より前は、イテレータを HttpResponse に渡すことでストリーミング応答を作成することができました。しかし、これは信頼できませんでした。 content 属性にアクセスしたミドルウェアは、イテレーターを早期に消費していました。

新しい StreamingHttpResponse クラスを使用してストリーミング応答を明示的に生成できるようになりました。このクラスは、イテレーターである streaming_content 属性を公開します。

StreamingHttpResponse にはcontent属性がないため、応答コンテンツにアクセスする必要があるミドルウェアは、ストリーミング応答をテストし、それに応じて動作する必要があります。

{% verbatim %}テンプレートタグ

Djangoの構文と衝突するJavaScriptテンプレートの処理を容易にするために、：ttag： `verbatim` ブロックタグを使用して、タグのコンテンツの解析を回避できるようになりました。

プロキシモデルに関連付けられたContentTypeインスタンスの取得

メソッド ContentTypeManager.get_for_model（）および ContentTypeManager.get_for_models（）には、それぞれfor_concrete_modelおよびfor_concrete_modelsという新しいキーワード引数があります。この引数を使用してFalseを渡すことにより、プロキシモデルに関連付けられた ContentType を取得できるようになりました。

クラスベースのビューコンテキストの新しいview変数

すべての汎用クラスベースビュー（またはContextMixinから継承するクラスベースビュー）では、コンテキストディクショナリに [を指すview変数が含まれています。 X171X]インスタンス。

GeoDjango

LineString および MultiLineString GEOSオブジェクトは、 interpolate（）および project（）メソッド（いわゆる線形参照）をサポートするようになりました。
GEOSGeometry オブジェクトのwkbおよびhexプロパティは、Z寸法を保持します。
PostGIS 2.0のサポートが追加され、GDAL <1.5のサポートが削除されました。

新しいチュートリアル

ドキュメントへの追加には、改良された Tutorial 3 と新しいテストに関するチュートリアルが含まれます。新しいセクション「高度なチュートリアル」では、再利用可能なアプリの作成方法と、 Django の最初のパッチの作成の新しい寄稿者向けのステップバイステップガイドを提供しています。

マイナーな機能

Django 1.5には、注目に値するいくつかの小さな改善点も含まれています。

テンプレートエンジンは、True、False、およびNoneを対応するPythonオブジェクトとして解釈するようになりました。
django.utils.timezone は、タイムゾーン間で認識されている日時を変換するためのヘルパーを提供します。 localtime（）を参照してください。
汎用ビューはOPTIONSリクエストをサポートします。
call_command（）からのコードによって呼び出されたときに、管理コマンドがSystemExitを発生させなくなりました。コマンドによって発生した例外（ほとんどの場合 CommandError ）は伝播されます。

さらに、カスタムコマンドでエラーやメッセージを出力する場合は、self.stdout.write('message')およびself.stderr.write('error')を使用する必要があります（管理コマンド出力に関する注記を参照）。
：djadmin： `dumpdata` 管理コマンドは、一度に1行を出力し、大きなデータセットをダンプするときのメモリ不足エラーを防ぎます。
カナダのローカルフレーバーでは、「pq」がケベックの許容コードに追加されました。これは古い略語です。
レシーバーデコレーターは、信号のリストを提供することにより、複数の信号に接続できるようになりました。
管理者では、メンバーであるグループでユーザーをフィルタリングできるようになりました。
QuerySet.bulk_create（）にbatch_size引数が追加されました。デフォルトでは、batch_sizeは無制限です。ただし、クエリごとに999個のパラメーターを超えないように単一のバッチが制限されているSQLiteを除きます。
：setting： `LOGIN_URL` および：setting：` LOGIN_REDIRECT_URL` 設定は、ビュー関数名および名前付きURLパターンも受け入れるようになりました。これにより、構成の重複を減らすことができます。詳細については、 login_required（）のドキュメントを参照してください。
Djangoは、mod_wsgi authハンドラーを提供するようになりました。
QuerySet.delete（）および Model.delete（）は、場合によっては高速パスを使用できるようになりました。高速パスにより、メモリにフェッチされるクエリとオブジェクトが少なくなります。詳細については、 QuerySet.delete（）を参照してください。
ResolverMatchのインスタンスは、リクエストにresolver_matchとして保存されます。
デフォルトでは、：setting： `DEBUG` がTrueのときにdjangoロガーに到達するすべてのログメッセージがコンソールに送信されます（[X171Xでロガーを再定義しない限り） ]：setting： `LOGGING` 設定）。
RequestContext を使用する場合、テンプレートで{% if 'someapp.someperm' in perms %}を使用して権限を検索できるようになりました。
ルートテンプレートディレクトリに404.htmlおよび500.htmlテンプレートを置く必要はもうありません。 Djangoは、これらのテンプレートが見つからない場合、両方の状況でいくつかの基本的なエラーメッセージを出力します。もちろん、かなりのエラーページをユーザーに表示するために、これらのテンプレートを提供することをお勧めします。
django.contrib.auth は、ユーザーが正常にログインできなかった場合に発行される新しいシグナルを提供します。 user_login_failed を参照してください
新しいloaddata --ignorenonexistentオプションは、存在しなくなったフィールドのデータを無視します。
assertXMLEqual（）および assertXMLNotEqual（）の新しいアサーションを使用すると、構文の違い（スペース、属性の順序など）を気にすることなく、セマンティックレベルでXMLコンテンツの同等性をテストできます。
RemoteUserMiddlewareは、同じブラウザセッション中にREMOTE_USERヘッダーが消えたときに、強制的にログアウトするようになりました。
キャッシュベースのセッションバックエンドは、デフォルト以外のキャッシュにセッションデータを保存できます。
モデルに複数列のインデックスを作成できるようになりました。詳細については、 index_together のドキュメントをお読みください。
Djangoのロギング構成中に、詳細な非推奨警告が有効になり、警告がロギングシステムにキャプチャされます。ログに記録された警告は、consoleログハンドラーを介してルーティングされます。デフォルトでは、出力を生成するには：setting： `DEBUG` がTrueである必要があります。その結果、DeprecationWarningsは、Pythonバージョン2.7未満の場合と同じように、開発環境のコンソールに出力されるはずです。
django.contrib.admin.ModelAdmin.message_user（）メソッドのAPIが変更され、 django.contrib.messages.add_message（）と同様の機能を追加する追加の引数を受け入れるようになりました。これは、管理アクションからエラーメッセージを生成するのに役立ちます。
新しい django.contrib.admin.ModelAdmin.get_list_filter（）メソッドのおかげで、管理者のリストフィルターをリクエストごとにカスタマイズできるようになりました。

1.5での後方互換性のない変更

警告

このセクションで概説されている変更に加えて、削除された機能については、非推奨プランを必ず確認してください。特定の機能の非推奨タイムライン内にコードを更新しなかった場合、その削除は後方互換性のない変更として表示される場合があります。

ALLOWED_HOSTSは本番環境で必要です

新しい：setting： `ALLOWED_HOSTS` 設定は、リクエストのHostヘッダーを検証し、ホストポイズニング攻撃から保護します。この設定は、：setting： `DEBUG` がFalseの場合は常に必要になります。そうでない場合、 django.http.HttpRequest.get_host（）は SuspiciousOperation [ X164X]。詳細については、：setting： `完全なドキュメント ` 新しい設定のために。

抽象モデルのマネージャー

抽象モデルはカスタムマネージャーを定義でき、そのマネージャーは、抽象モデルを拡張する任意の具象モデルに継承されます。ただし、抽象モデルを使用してマネージャーのメソッドを呼び出そうとすると、例外が発生するようになりました。以前は、呼び出しは許可されていましたが、データベース操作が試行されるとすぐに失敗しました（通常、データベースからの「テーブルが存在しません」エラーが発生します）。

抽象クラスを使用して呼び出しているマネージャーに機能がある場合は、そのロジックを抽象クラスのPython staticmethodまたはclassmethodに移行する必要があります。

年アーカイブクラスベースビューのコンテキスト

他の日付ベースの汎用ビューとの一貫性を保つために、 YearArchiveView はコンテキスト内でyearを文字列ではなくdatetime.dateとして渡すようになりました。テンプレートでテンプレート:Yearを使用している場合は、テンプレート:Yearに置き換える必要があります。

next_yearとprevious_yearもコンテキストに追加されました。 allow_emptyおよびallow_futureに従って計算されます。

年と月のアーカイブクラスベースビューのコンテキスト

YearArchiveView および MonthArchiveView は、関数ベースの先行関数と同様に、コンテキスト内で昇順でソートされたdate_listを提供するように文書化されていますが、実際には降順でした。 1.5では、文書化された順序が復元されました。テンプレートでdate_listを反復処理する場合は、reversedキーワードを追加（または削除）することをお勧めします。

{% for date in date_list reversed %}

ArchiveIndexView は、引き続きdate_listを降順で提供します。

TemplateViewのコンテキスト

他の汎用ビューの設計との一貫性を保つために、 TemplateView はparamsディクショナリをコンテキストに渡さなくなり、代わりに変数をURLconfからコンテキストに直接渡します。

HTTPリクエストの非フォームデータ

request.POST は、ヘッダーにフォーム固有ではないコンテンツタイプを含むHTTPリクエストを介して投稿されたデータを含まなくなります。以前のバージョンでは、multipart/form-dataまたはapplication/x-www-form-urlencoded以外のコンテンツタイプで投稿されたデータは、 request.POST 属性で表されることになります。これらの場合の生のPOSTデータにアクセスしたい開発者は、代わりに request.body 属性を使用する必要があります。

request_finished シグナル

Djangoは、ビュー関数が応答を返すとすぐに request_finished シグナルを送信していました。これは、コンテンツの生成を遅らせるストリーミング応答との相互作用が悪かった。

このシグナルは、コンテンツがWSGIゲートウェイによって完全に消費された後に送信されるようになりました。応答コンテンツをクライアントに送信する前に発生するシグナルに依存している場合、これは後方互換性がない可能性があります。その場合は、代わりにミドルウェアの使用を検討する必要があります。

ノート

一部のWSGIサーバーおよびミドルウェアは、要求の処理後に応答オブジェクトでcloseを常に呼び出すとは限りません。特に、1.2.6より前のuWSGIおよび2.0.7までのSentryのエラー報告ミドルウェアです。そのような場合、request_finished信号はまったく送信されません。これにより、データベースおよびmemcacheサーバーへの接続がアイドル状態になる可能性があります。

テストクライアントでのOPTIONS、PUT、およびDELETEリクエスト

GETやPOSTとは異なり、これらのHTTPメソッドはWebブラウザによって実装されていません。むしろ、JSONやXMLなどのさまざまな形式でデータを転送するAPIで使用されます。このようなリクエストには任意のデータが含まれている可能性があるため、Djangoはその本文をデコードしようとはしません。

ただし、テストクライアントは、GETなどのOPTIONSおよびDELETEリクエストのクエリ文字列と、POSTなどのPUTリクエストのリクエストボディを作成するために使用されていました。このエンコーディングは任意であり、リクエストを受信したときのDjangoの動作と矛盾していたため、Django1.5で削除されました。

OPTIONSまたはDELETEリクエストでdataパラメータを使用していた場合は、それをクエリ文字列に変換して、pathパラメータに追加する必要があります。

content_typeなしでPUTリクエストでdataパラメータを使用していた場合は、データをテストクライアントに渡す前にエンコードし、content_type引数を設定する必要があります。

simplejsonのシステムバージョンは使用されなくなりました

以下で説明するように、Django1.5はdjango.utils.simplejsonを廃止し、Python2.6の組み込みjsonモジュールを優先します。理論的には、この変更は無害です。残念ながら、simplejsonのバージョン間の非互換性のため、状況によってはエラーが発生する可能性があります。

Django 1.4のJSON関連の機能は、常にdjango.utils.simplejsonを使用していました。このモジュールは実際には次のとおりです。

simplejsonのシステムバージョン（利用可能な場合）。 import simplejsonは機能します）、Djangoの組み込みコピーよりも新しい場合、またはCのスピードアップがあった場合、または
標準ライブラリのjsonモジュール（使用可能な場合）。 Python 2.6以降）、または
simplejsonのバージョン2.0.7の組み込みコピー。

Django 1.5では、これらの機能はPythonのjsonモジュールを使用します。これは、simplejsonのバージョン2.0.9に基づいています。

Djangoのバージョン2.0.7のコピーとPythonのバージョン2.0.9のコピーの間に既知の非互換性はありません。ただし、他のバージョンのsimplejsonの間にはいくつかの非互換性があります。

simplejson APIは常にユニコード文字列を返すものとして文書化されていますが、オプションのC実装はバイト文字列を返すことができます。これはPython2.7で修正されました。
simplejson.JSONEncoderは、バージョン2.2でnamedtuple_as_objectキーワード引数を取得しました。

これらの非互換性の詳細については、次のWebサイトを参照してください。：ticket： `ticket＃18023 <18023＃comment：10>` 。

最終的な結果として、simplejsonをインストールし、コードでDjangoのシリアル化内部を直接使用する場合（たとえば、django.core.serializers.json.DjangoJSONEncoderの場合）、simplejsonからjsonに切り替えます。コードが破損する可能性があります。（通常、内部の変更は文書化されていません。ここでは例外を設けています。）

この時点で、Djangoのメンテナは、標準ライブラリのjsonを使用すると、下位互換性が最も強く保証されると考えています。これから使うことをお勧めします。

ハッシャーメソッドパラメーターの文字列型

カスタムパスワードハッシャーを作成した場合、encode()、verify()、またはsafe_summary()メソッドはUnicodeパラメーター（password、[ X147X] またはencoded）。ハッシュメソッドのいずれかにバイト文字列が必要な場合は、 force_bytes（）ユーティリティを使用して文字列をエンコードできます。

previous_page_numberとnext_page_numberの検証

オブジェクトページ付けを使用する場合、 Page オブジェクトのprevious_page_number()およびnext_page_number()メソッドは、返された番号が既存のページ範囲内にあるかどうかをチェックしませんでした。今すぐチェックし、数が少なすぎるか多すぎると InvalidPage 例外を発生させます。

PostgreSQLでのデータベースの自動コミットオプションの動作が変更されました

PostgreSQLの自動コミットオプションは、以前に宣伝されていたようには機能しませんでした。単一のトランザクションブロックでは機能しましたが、最初のブロックが残された後、自動コミット動作が復元されることはありませんでした。このバグは1.5で修正されました。これは単なるバグ修正ですが、自動コミットオプションと一緒にPostgreSQLを使用している場合は、アプリケーションの動作を確認する価値があります。

500応答でセッションが保存されません

応答のステータスコードが500の場合、Djangoのセッションミドルウェアはセッションデータの保存をスキップします。

失敗した管理者ログインの電子メールチェック

Django 1.5より前は、管理インターフェースにログインしようとして、ユーザー名の代わりに誤ってメールアドレスを使用した場合、管理インターフェースは、メールアドレスがユーザー名ではないことを通知する警告を表示していました。 Django 1.5では、カスタムユーザーモデルの導入により、この警告を削除する必要がありました。これは、管理サイトのログイン動作を変更しません。これは、特定のログイン失敗モードで表示される警告メッセージにのみ影響します。

テスト実行の変更

テストの実行にいくつかの変更が導入されましたが、一部のテストセットアップでは下位互換性がない可能性があります。

django.test.TransactionTestCaseでのデータベースフラッシュ

以前は、 TransactionTestCase で各テストが実行される前に、テストデータベースが切り捨てられていました。

単体テストを任意の順序で実行できるようにし、それらが常に互いに分離されていることを確認するために、 TransactionTestCase は、代わりにの実行後にデータベースをリセットするようになりました。

暗黙のDBシーケンスがリセットされることはもうありません

TransactionTestCase テストは、上記のデータベースフラッシュアクションとともに主キーシーケンスを自動的にリセットするために使用されます。

これは変更されたため、シーケンスが暗黙的にリセットされることはありません。これにより、ハードコードされた主キー値に依存する TransactionTestCase テストが失敗する可能性があります。

新しい reset_sequences 属性を使用して、それを必要とする可能性のある TransactionTestCase の古い動作を強制することができます。

テストの順序

すべてのTestCaseコードがクリーンなデータベースで始まることを確認するために、テストは次の順序で実行されるようになりました。

まず、すべての単体テスト（unittest.TestCase、 SimpleTestCase 、 TestCase 、 TransactionTestCase を含む）は、特定の順序が保証または強制されることなく実行されます。
次に、他のテスト（例：データベースを元の状態に復元せずに変更する可能性のあるdoctests）が実行されます。

TransactionTestCase が以前に実行されたと想定する既存のドキュメントテストがデータベースの状態を残したり、他のテストの実行後に何らかの形式の状態が保持されることに依存する単体テストがない限り、これによって問題が発生することはありません。このようなテストはすでに非常に脆弱であり、独立して実行できるように変更する必要があります。

cleaned_data 辞書は無効なフォーム用に保持されています

cleaned_data ディクショナリは、フォームの検証後に常に存在するようになりました。フォームが検証されない場合、検証に合格したフィールドのみが含まれます。フォームの cleaned_data 属性の有無ではなく、 is_valid（）メソッドを使用して検証の成功をテストする必要があります。

複数のデータベースでのsyncdbの動作

syncdbは、データベースルーターにクエリを実行して、コンテンツタイプ（ contenttypes が有効な場合）とアクセス許可（ auth が有効な場合）をターゲットデータベースに作成する必要があるかどうかを判断するようになりました。以前は、--databaseオプションで別のデータベースが指定されていても、デフォルトのデータベースに作成されていました。

複数のデータベースでsyncdbを使用する場合は、ルーターがコンテンツタイプとアクセス許可をそのうちの1つにのみ同期できるようにする必要があります。詳細については、複数のデータベースを持つcontribアプリの動作に関するドキュメントを参照してください。

XMLデシリアライザーはDTDを使用してドキュメントを解析しません

外部エンティティ参照およびエンティティ拡張に関連するサービス拒否攻撃への露出を防ぐために、XMLモデルデシリアライザーは、DTD（DOCTYPE定義）を含むXMLドキュメントの解析を拒否するようになりました。 XMLシリアライザーはDTDを出力しないため、これは通常の使用法には影響せず、カスタム作成されたXMLドキュメントがDjangoのモデルデシリアライザーに渡される場合にのみ影響します。

フォームセットのデフォルトmax_num

フォームセットファクトリのmax_num引数のNoneの（デフォルト）値は、フォームセット内で任意の数のフォームを許可するようにデフォルト設定されなくなりました。代わりに、メモリ枯渇攻撃を防ぐために、デフォルトで1000フォームの制限になりました。この制限は、max_numに高い値を明示的に設定することで引き上げることができます。

その他

django.forms.ModelMultipleChoiceField は、空のリストではなく、空の値として空のQuerySetを返すようになりました。
int_to_base36（）は、非整数入力に対してValueErrorではなくTypeErrorを適切に発生させます。
slugifyテンプレートフィルターは、 django.utils.text.slugify（）で標準のPython関数として利用できるようになりました。同様に、remove_tagsはdjango.utils.html.remove_tags()で入手できます。
アップロードされたファイルは、デフォルトで実行可能ファイルとして作成されなくなりました。それらを実行可能にする必要がある場合は、：setting： `FILE_UPLOAD_PERMISSIONS` を必要に応じて変更してください。新しいデフォルト値は0o666（8進数）で、現在のumask値が最初にマスクされます。
F式は、&および|によるビット演算子をサポートしていました。これらの演算子は、代わりに.bitand()および.bitor()を使用して使用できるようになりました。 &と|の削除は、 Q（）式とQuerySetの組み合わせと一致するように行われ、演算子はブールANDとORとして使用されます。演算子。
filter()呼び出しで、 F式に複数値の関係にまたがるルックアップが含まれている場合、同じチェーンに沿った他のルックアップと同じ関係を常に再利用するとは限りませんでした。これは変更され、F（）式は、同じfilter()呼び出し内の他のルックアップと常に同じ関係を使用するようになりました。
：ttag： `csrf_token` テンプレートタグはdivで囲まれなくなりました。 HTML5より前のStrictDTDに対するHTML検証が必要な場合は、ページの周囲にdivを追加する必要があります。
非推奨のテンプレートタグ{% admin_media_prefix %}のみを含むテンプレートタグライブラリadminmediaが削除されました。 {% load adminmedia %}でロードしようとすると失敗します。テンプレートにまだその行が含まれている場合は、それを削除する必要があります。
実装の見落としのため、 django.contrib.sites を有効にせずに django.contrib.redirects を使用することが可能でした。これはもう許可されていません。 django.contrib.redirectsを使用している場合は、：setting： `INSTALLED_APPS` にdjango.contrib.sitesが含まれていることを確認してください。
BoundField.label_tag は、contents引数をエスケープするようになりました。 HTMLのエスケープを回避するには、引数を渡す前に django.utils.safestring.mark_safe（）を使用します。
select_related（）を介してフェッチされた逆1対1の関係にアクセスすると、Noneを返す代わりに、 DoesNotExist が発生するようになりました。

1.5で廃止された機能

django.contrib.localflavor

localflavorcontribアプリは個別のパッケージに分割されています。 django.contrib.localflavor自体は、廃止が加速された後、Django1.6で削除されます。

新しいパッケージはGitHubで入手できます。コアチームは、これらのパッケージを長期的に効率的に維持することはできません。現時点では、わずか12か国にまたがっています。翻訳と同様に、メンテナンスはコミュニティの関心のあるメンバーに引き渡されます。

django.contrib.markup

マークアップcontribモジュールは非推奨になり、非推奨の加速スケジュールに従います。 Djangoがフレームワークでこの機能を維持するよりも、Pythonマークアップライブラリまたはサードパーティのタグライブラリを直接使用することをお勧めします。

AUTH_PROFILE_MODULE

カスタムユーザーモデルの導入により、ユーザープロファイルデータを保存するための組み込みメカニズムは不要になりました。

ユーザーモデルと1対1の関係を持つユーザープロファイルモデルを定義することもできます。実際、データをユーザーアカウントに関連付ける必要がある多くのアプリケーションでは、これが適切なデザインパターンになります。ただし、AUTH_PROFILE_MODULE設定、およびユーザープロファイルモデルにアクセスするためのdjango.contrib.auth.models.User.get_profile()メソッドは、使用しないでください。

HttpResponse のストリーミング動作

Django 1.5は、イテレータを HttpResponse に渡すことにより、応答をストリーミングする機能を廃止します。この動作に依存している場合は、 StreamingHttpResponse に切り替えてください。上記のストリーミング応答の明示的なサポートを参照してください。

Django 1.7以降では、イテレータは HttpResponse によってすぐに消費されます。

django.utils.simplejson

Django1.5はPython2.5のサポートを終了したため、Pythonの標準ライブラリで利用可能なjsonモジュールを信頼できるようになり、simplejsonの独自のコピーを削除しました。 django.utils.simplejsonの代わりにjsonをインポートする必要があります。

残念ながら、simplejsonのバージョン間の非互換性のため、この変更には望ましくない副作用が生じる可能性があります。後方互換性のない変更セクションを参照してください。 Pythonのjsonになった後にsimplejsonに追加された機能に依存する場合は、simplejsonを明示的にインポートする必要があります。

django.utils.encoding.StrAndUnicode

django.utils.encoding.StrAndUnicodeミックスインは非推奨になりました。 __str__メソッドを定義し、代わりに python_2_unicode_compatible（）デコレータを適用します。

django.utils.itercompat.product

django.utils.itercompat.product関数は非推奨になりました。代わりに、組み込みのitertools.product()を使用してください。

cleanup管理コマンド

cleanup管理コマンドは非推奨になり、：djadmin： `clearsessions` に置き換えられました。

daily_cleanup.pyスクリプト

文書化されていないdaily_cleanup.pyスクリプトは非推奨になりました。代わりに、：djadmin： `clearsessions` 管理コマンドを使用してください。

Django 1.5リリースノート—Djangoドキュメント