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

提供：Dev Guides
< DjangoDjango/docs/2.2.x/releases/1.2
移動先:案内、検索

Django1.2リリースノート

2010年5月17日。

Django 1.2へようこそ！

作成からほぼ1年が経ち、Django 1.2には、新機能の印象的なリストと多くのバグ修正が含まれています。 これらのリリースノートには、新機能のほか、Django1.1以前のバージョンからアップグレードするときに知っておく必要のある重要な変更点が記載されています。

概要

Django 1.2には、次のようないくつかの大きくて重要な新機能が導入されています。

これらは単なるハイライトです。 完全な詳細と機能の完全なリストは以下にあります。

も参照してください

Django Advent は、Django 1.2のリリースを、いくつかの新機能を詳細にカバーする一連の記事とチュートリアルでカバーしました。


これらの機能は、可能な限り、 API安定性ポリシーポリシーに従って下位互換性のある方法で導入されています。

ただし、一部のユーザーにとっては下位互換性がないように、いくつかの機能が変更されています。 大きな変更点は次のとおりです。

  • Python2.3のサポートは終了しました。 以下の完全な注記を参照してください。

  • 新しいCSRF保護フレームワークは、古いシステムとの下位互換性がありません。 古いシステムのユーザーは、Django1.4で古いシステムが削除されるまで影響を受けません。

    ただし、新しいCSRF保護フレームワークにアップグレードするには、以下の CSRF保護で詳しく説明されている、後方互換性のない重要な変更がいくつか必要です。

  • カスタム Field サブクラスの作成者は、以下のField の get_db_prep _ *（）メソッドで詳しく説明されているように、多くのメソッドでプロトタイプが変更されていることに注意してください。

  • テンプレートタグの内部は多少変更されています。 状態を保存する必要があるカスタムテンプレートタグの作成者（例： カスタム制御フロータグ）は、コードがステートフルテンプレートタグの新しいルールに従っていることを確認する必要があります。

  • user_passes_test（）、 login_required（）、および permit_required（）、 django.contrib.auth のデコレータは関数とメソッドで動作しなくなりました。 簡単な1行の修正があります。

繰り返しますが、これらはほとんどのユーザーに影響を与える大きな機能にすぎません。 以前のバージョンのDjangoからアップグレードするユーザーは、後方互換性のない変更の完全なリストと非推奨の機能のリストを参照することを強くお勧めします。


Pythonの互換性

新しい機能ではありませんが、Django 1.2は、Djangoの最初の公開デビュー以来、Python互換性ポリシーに最初のシフトを導入していることに注意することが重要です。 以前のDjangoリリースは、2.3以降の2.xPythonバージョンでテストおよびサポートされていました。 ただし、Django 1.2は、Python2.3の公式サポートを終了します。 そのため、Djangoに必要なPythonの最小バージョンは2.4になり、DjangoはPython 2.4、2.5、2.6でテストおよびサポートされ、まだリリースされていないPython2.7でサポートされる予定です。

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

Djangoの全体的な2.xPythonサポート、および最終的なPython 3.xへの移行のロードマップは現在開発中であり、Django1.3のリリース前に発表される予定です。


Django1.2の新機能

複数のデータベースのサポート

Django 1.2には、Djangoプロジェクトで複数のデータベースを使用する機能が追加されています。 クエリは、QuerySetオブジェクトのusing()メソッドを使用して特定のデータベースで発行できます。 save()を呼び出すときにusing引数を指定することにより、個々のオブジェクトを特定のデータベースに保存できます。


モデルの検証

モデルインスタンスは、独自のデータの検証をサポートするようになり、モデルフィールドとフォームフィールドの両方が、再利用可能なカプセル化された検証動作を指定するバリデーターの構成可能なリストを受け入れるようになりました。 ただし、検証は引き続き明示的に実行する必要があることに注意してください。 モデルインスタンスのsave()メソッドを呼び出すだけでは、インスタンスのデータの検証は実行されません。


改善されたCSRF保護

Djangoは、クロスサイトリクエストフォージェリ（CSRF）攻撃に対する保護が大幅に改善されました。 このタイプの攻撃は、悪意のあるWebサイトに、ブラウザで悪意のあるサイトにアクセスするログインユーザーの資格情報を使用して、Webサイトで何らかのアクションを実行することを目的としたリンク、フォームボタン、またはJavaScriptが含まれている場合に発生します。 関連するタイプの攻撃である「ログインCSRF」もカバーされています。この攻撃サイトは、ユーザーのブラウザをだまして、他の誰かの資格情報を使用してサイトにログインさせます。


メッセージフレームワーク

Djangoには、匿名クライアントと認証済みクライアントの両方に対して、Cookieベースおよびセッションベースのメッセージングのサポートが組み込まれた、堅牢で構成可能なメッセージフレームワークが含まれるようになりました。 メッセージフレームワークは、非推奨のユーザーメッセージAPIに置き換わるものであり、メッセージを1つのリクエストに一時的に保存し、後続のリクエスト（通常は次のリクエスト）で表示するために取得することができます。


オブジェクトレベルの権限

オブジェクトごとのレベルで権限を指定するための基盤が追加されました。 コアにはこれの実装はありませんが、カスタム認証バックエンドがこの実装を提供でき、 django.contrib.auth.models.User によって使用されます。 詳細については、認証ドキュメントを参照してください。


匿名ユーザーの権限

supports_anonymous_userをTrueに設定してカスタム認証バックエンドを提供すると、AnonymousUserは、ユーザーが既に行ったように、バックエンドのアクセス許可を確認します。 これは、権限の処理を一元化するのに役立ちます。アプリは、何かが許可されているかどうかの質問を承認/認証バックエンドにいつでも委任できます。 詳細については、認証ドキュメントを参照してください。


ユーザー名の緩和された要件

組み込みのユーザーモデルのユーザー名フィールドで、@、+、.、 -文字。


メールバックエンド

これで、Djangoが電子メールを送信する方法を構成できます。 SMTPを使用してすべての電子メールを送信する代わりに、構成可能な電子メールバックエンドを選択してメッセージを送信できるようになりました。 ホスティングプロバイダーがメールの送信にサンドボックスまたはその他の非SMTP技術を使用している場合、Djangoの標準メール送信方法がこれらの機能を使用できるようにするメールバックエンドを構築できるようになりました。

これにより、メール送信のデバッグも簡単になります。 Djangoには、ファイル、コンソール、またはメモリにメールを送信できるバックエンド実装が付属しています。 すべてのメールを破棄するように構成することもできます。


「スマート」：ttag： `if` タグ

：ttag： `if` タグがアップグレードされ、より強力になりました。 まず、比較演算子のサポートを追加しました。 次のように入力する必要はありません。 

{% ifnotequal a b %}
 ...
{% endifnotequal %}

これを行うことができます： 

{% if a != b %}
 ...
{% endif %}

懐かしいタイプでない限り、{% ifequal %}や{% ifnotequal %}を使う理由はもうありません。

サポートされている演算子は、==、!=、<、>、<=、>=、 [ X98X]とnot inは、すでにサポートされているand、or、notに加えて、すべてPython演算子のように機能します。

また、if式でフィルターを使用できるようになりました。 例えば： 

<div
  {% if user.email|lower == message.recipient|lower %}
    class="highlight"
  {% endif %}
>{{ message }}</div>

テンプレートのキャッシュ

以前のバージョンのDjangoでは、テンプレートをレンダリングするたびに、ディスクからリロードされていました。 Django 1.2では、キャッシュされたテンプレートローダーを使用してテンプレートを1回ロードし、その後のレンダリングごとに結果をキャッシュできます。 これにより、テンプレートが多数の小さなサブテンプレートに分割されている場合（{% extends %}または{% include %}タグを使用）、パフォーマンスが大幅に向上する可能性があります。

副作用として、Django以外のテンプレート言語のサポートがはるかに簡単になりました。


クラスベースのテンプレートローダー

テンプレートキャッシングを導入するために行われた変更の一環として、Djangoの一般的な傾向に従って、テンプレートローダーAPIは、関数ではなくPythonクラスにカプセル化されたテンプレートロードメカニズムを使用するように変更されました。これは唯一の方法です。 Django1.1まで利用可能です。

Django に同梱されているすべてのテンプレートローダーは新しいAPIに移植されていますが、それらは引き続き関数ベースのAPIを実装しており、テンプレートコア機構は引き続き関数ベースのローダー（組み込みまたはサードパーティ）を受け入れるため、既存のプロジェクトのTEMPLATE_LOADERS設定をすぐに変更する必要があります。Django1.3リリースまでそのままにしておくと、動作し続けます。

独自のカスタムテンプレートローダーを開発した場合は、クラスベースの実装への移植を検討することをお勧めします。関数ベースのローダーとの下位互換性のためのコードは、Django 1.2で非推奨プロセスを開始し、Django1.4で削除されるためです。 これらのローダークラスがテンプレートAPIリファレンスに実装する必要のあるAPIの説明があり、Djangoに付属のローダーのソースコードを調べることもできます。


フィクスチャの自然キー

フィクスチャは、自然キーを使用してリモートオブジェクトを参照できるようになりました。 このルックアップスキームは、フィクスチャ内の通常の主キーベースのオブジェクト参照に代わるものであり、読みやすさを向上させ、主キー値が予測できないか不明なオブジェクトを参照する問題を解決します。


テストの迅速な失敗

django-admin.pyの：djadmin： `test` サブコマンドとDjango独自のテストスイートの実行に使用されるruntests.pyスクリプトの両方で、--failfastオプションがサポートされるようになりました。 このオプションを指定すると、テスト実行を続行する代わりに、障害が発生した後にテストランナーが終了します。 さらに、テスト実行中のCtrl-Cの処理が改善され、中断前に実行されたテストの詳細を報告するテスト実行の正常な終了がトリガーされるようになりました。


BigIntegerField

モデルは64ビット BigIntegerField タイプを使用できるようになりました。


ローカリゼーションの改善

Djangoの国際化フレームワークは、ロケール対応のフォーマットとフォーム処理で拡張されました。 つまり、有効にすると、テンプレートの日付と数値は、現在のロケールに指定された形式を使用して表示されます。 Djangoは、フォーム内のデータを解析するときにローカライズされた形式も使用します。 詳細については、フォーマットのローカリゼーションを参照してください。


ModelAdminのreadonly_fields

django.contrib.admin.ModelAdmin.readonly_fields が追加され、モデルとインラインの追加/変更ページで編集不可能なフィールドが有効になりました。 フィールドと計算値は、編集可能なフィールドと一緒に表示できます。


カスタマイズ可能な構文の強調表示

DJANGO_COLORS環境変数を使用して、django-admin.pyで使用される色を変更または無効にして、構文の強調表示を提供できるようになりました。


ビューとしてのシンジケーションフィード

シンジケーションフィードを URLconf のビューとして直接使用できるようになりました。 これは、フィードのURL構造を完全に制御できることを意味します。 他のビューと同様に、フィードビューにはrequestオブジェクトが渡されるため、ユーザーベースのアクセス制御やフィードに名前付きURLを作成するなど、ビューで通常行うことは何でもできます。


GeoDjango

1.2の GeoDjango の最も重要な新機能は、複数の空間データベースのサポートです。 その結果、次の空間データベースバックエンドが含まれるようになりました。

  • django.contrib.gis.db.backends.postgis
  • django.contrib.gis.db.backends.mysql
  • django.contrib.gis.db.backends.oracle
  • django.contrib.gis.db.backends.spatialite

GeoDjangoは、PostGIS1.5リリースで追加された豊富な機能をサポートするようになりました。 新機能には、地理タイプのサポート、および地理座標系の非ポイントジオメトリでの距離クエリの有効化が含まれます。

3Dジオメトリフィールドのサポートが追加され、 GeometryField で dim キーワードを3に設定することで有効にできる場合があります。 この機能の一部として、 Extent3D アグリゲートとextent3d() GeoQuerySetメソッドが追加されました。

force_rhr()、reverse_geom()、およびgeohash() GeoQuerySetメソッドは新しいものです。

プラットフォームで利用可能な場合、スレッドセーフなCライブラリ関数を使用するようにGEOSインターフェイスが更新されました。

GDALインターフェースにより、ユーザーは Layer を反復処理したときに返される機能に spatial_filter を設定できるようになりました。

最後に、 GeoDjangoのドキュメントはDjangoに含まれるようになり、 geodjango.org で個別にホストされなくなりました。


新しいnowテンプレートタグ形式指定子文字：cおよびu

：ttag： `now` の引数に、日時値をISO8601形式でフォーマットするように指定するcとuの2つの新しいフォーマット文字が追加されました。これにより、日時または時刻の値のマイクロ秒部分を出力できます。

これらは、：tfilter： `date` および：tfilter：` time` テンプレートフィルター、humanizeテンプレートタグライブラリ、および新しいフォーマットローカリゼーションフレームワーク。


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

可能な限り、上記の新機能は、 API安定性ポリシーポリシーに従って下位互換性のある方法で導入されています。 これは、Django1.1で機能していた実質的にすべての既存のコードが引き続きDjango1.2で機能することを意味します。 ただし、そのようなコードは警告の発行を開始します（詳細については以下を参照してください）。

ただし、一部のユーザーにとっては、すぐに下位互換性がなくなるように、いくつかの機能が変更されています。 これらの変更については、以下で詳しく説明します。

CSRF保護

CSRFドキュメントで詳しく説明されているように、CSRF保護の動作方法に大きな変更を加えました。 知っておくべき主な変更点は次のとおりです。

  • CsrfResponseMiddlewareとCsrfMiddlewareは非推奨になり、フォームに挿入する必要のあるテンプレートタグを優先して、Django1.4で完全に削除されます。

  • すべてのcontribアプリは、csrf_protectデコレータを使用してビューを保護します。 これには、テンプレートでcsrf_tokenテンプレートタグを使用する必要があります。 コントリビュートビューにカスタムテンプレートを使用した場合は、アップグレード手順を読んでそれらのテンプレートを修正する必要があります。

    ドキュメントが削除されました

    アップグレードノートは、現在のDjangoドキュメントから削除されました。 これらの手順については、Django1.3以前のドキュメントを参照してください。

  • CsrfViewMiddlewareはデフォルトでMIDDLEWARE_CLASSESに含まれています。 これにより、デフォルトでCSRF保護がオンになるため、ミドルウェアで機能するようにPOSTリクエストを受け入れるビューを作成する必要があります。 これを行う方法の説明は、CSRFドキュメントにあります。

  • すべてのCSRFがcontribからcoreに移動しました（古い場所での下位互換性のあるインポートは非推奨であり、Django 1.4ではサポートされなくなります）。


Fieldのget_db_prep_*()メソッド

Django 1.2より前は、カスタムFieldには、Python値からデータベース互換値への変換をサポートするいくつかの関数を定義するオプションがありました。 カスタムフィールドは次のようになります。 

class CustomModelField(models.Field):
    # ...
    def db_type(self):
        # ...

    def get_db_prep_save(self, value):
        # ...

    def get_db_prep_value(self, value):
        # ...

    def get_db_prep_lookup(self, lookup_type, value):
        # ...

1.2では、これら3つの方法のプロトタイプが変更され、2つの追加の方法が導入されました。 

class CustomModelField(models.Field):
    # ...

    def db_type(self, connection):
        # ...

    def get_prep_value(self, value):
        # ...

    def get_prep_lookup(self, lookup_type, value):
        # ...

    def get_db_prep_save(self, value, connection):
        # ...

    def get_db_prep_value(self, value, connection, prepared=False):
        # ...

    def get_db_prep_lookup(self, lookup_type, value, connection, prepared=False):
        # ...

これらの変更は、複数のデータベースをサポートするために必要です– db_typeおよびget_db_prep_*は、準備中のデータベースに関して仮定を行うことができなくなりました。 connection引数は、値が準備されている特定の接続を使用して準備メソッドを提供するようになりました。

一般的なデータ準備要件をデータベース固有の要件から区別するために、2つの新しい方法が存在します。 prepared引数は、ジェネリック値の準備が実行されたかどうかをデータベース準備メソッドに示すために使用されます。 準備されていない（つまり、prepared=False）値がget_db_prep_*()呼び出しに提供された場合、対応するget_prep_*()呼び出しを呼び出して、一般的なデータ準備を実行する必要があります。

古いプロトタイプに準拠している関数を新しいプロトタイプと互換性のある関数に透過的に変換する変換関数を提供しました。 ただし、これらの変換関数はDjango 1.4で削除されるため、Field定義をアップグレードして、新しいプロトタイプをできるだけ早く使用する必要があります。

get_db_prep_*()メソッドがデータベース接続を使用しなかった場合は、get_db_prep_value()の名前をget_prep_value()に、get_db_prep_lookup()の名前を [に変更することでアップグレードできます。 X152X]。 データベース固有の変換が必要な場合は、connection引数を使用してデータベース固有の値を解決する実装get_db_prep_*を提供する必要があります。


ステートフルテンプレートタグ

Nodeサブクラスにレンダリング状態を格納するテンプレートタグは、常にスレッドセーフやその他の問題に対して脆弱でした。 ただし、Django 1.2以降、新しいキャッシュテンプレートローダーと一緒に使用すると、問題が発生する可能性もあります。

組み込みのDjangoテンプレートタグはすべてキャッシュローダーで安全に使用できますが、サードパーティのパッケージまたは独自のコードからのカスタムテンプレートタグを使用している場合は、 [X213X ]各タグの実装はスレッドセーフです。 詳細については、テンプレートタグスレッドの安全性に関する考慮事項を参照してください。

Djangoのテンプレートタグがスレッドセーフではないの実装に依存している場合は、テンプレートを更新する必要がある場合もあります。 ：ttag： `cycle` タグは、特に：ttag：` include` タグと組み合わせて使用した場合に、この方法で影響を受ける可能性が最も高くなります。 次のテンプレートフラグメントについて考えてみます。 

{% for object in object_list %}
    {% include "subtemplate.html" %}
{% endfor %}

subtemplate.htmlは次のようになります。 

{% cycle 'even' 'odd' %}

スレッドセーフではない、Django 1.2より前のレンダラーを使用すると、次のように出力されます。 

even odd even odd ...

スレッドセーフなDjango1.2レンダラーを使用すると、代わりに次のようになります。 

even even even even ...

これは、：ttag： `include` タグの各レンダリングが独立したレンダリングであるためです。 ：ttag： `cycle` タグがスレッドセーフでない場合、：ttag：` cycle` タグの状態は、同じ：ttagの複数のレンダリング間でリークしていました。 ： `include` 。 ：ttag： `cycle` タグがスレッドセーフになったので、このリークは発生しなくなりました。


user_passes_test、login_required、permission_required

django.contrib.auth.decoratorsは、デコレータlogin_required、permission_required、およびuser_passes_testを提供します。 以前は、これらのデコレータを関数（最初の引数が「request」）とメソッド（最初の引数が「self」、2番目の引数が「request」）の両方で使用できました。 残念ながら、これをサポートするコードに欠陥が発見されました。これは限られた状況でのみ機能し、機能しない場合はデバッグが非常に難しいエラーを生成します。

このため、「自動適応」動作は削除されました。メソッドでこれらのデコレータを使用している場合は、 django.utils.decorators.method_decorator（）を手動で適用してデコレータをに変換する必要があります。メソッドで動作するもの。 たとえば、次のコードを変更します。 

class MyClass(object):

    @login_required
    def my_view(self, request):
        pass

これに： 

from django.utils.decorators import method_decorator

class MyClass(object):

    @method_decorator(login_required)
    def my_view(self, request):
        pass

また： 

from django.utils.decorators import method_decorator

login_required_m = method_decorator(login_required)

class MyClass(object):

    @login_required_m
    def my_view(self, request):
        pass

開発トランクをフォローしている方のために、この変更は、csrf_protect、cache_control、およびdecorator_from_middlewareを使用して作成されたものなど、1.1以降に導入された他のデコレータにも適用されます。


：ttag： `if` タグの変更

：ttag： `if` テンプレートタグの新機能により、有効な変数名として「および」、「または」および「not」を受け入れなくなりました。 以前は、これらの文字列を変数名として使用できました。 現在、キーワードステータスは常に適用され、{% if not %}や{% if and %}などのテンプレートコードはTemplateSyntaxErrorをスローします。 また、inは新しいキーワードであるため、このタグの有効な変数名ではありません。


LazyObject

LazyObjectは、文書化されていないが頻繁に使用されるユーティリティクラスであり、不明なタイプの他のオブジェクトを遅延ラップするために使用されます。

Django 1.1以前では、get_all_members()という名前のパブリックメソッドを実装するラップされたオブジェクトに応じて、非標準的な方法でイントロスペクションを処理していました。 これは名前の衝突につながる可能性があるため、__members__と__dir__()を含む標準のPythonイントロスペクションメソッドを使用するように変更されました。

独自のコードでLazyObjectを使用し、ラップされたオブジェクトにget_all_members()メソッドを実装した場合は、いくつかの変更を加える必要があります。

まず、クラスにイントロスペクションの特別な要件がない場合（つまり、__getattr__()または通常のメカニズムでは検出できない属性を許可するその他のメソッドを実装していない場合）、get_all_members()を削除するだけです。方法。 LazyObjectのデフォルトの実装は正しいことをします。

イントロスペクションの要件がより複雑な場合は、最初にget_all_members()メソッドの名前を__dir__()に変更します。 これは、Python2.6以降の標準的なイントロスペクション方法です。 2.6より前のバージョンのPythonのサポートが必要な場合は、次のコードをクラスに追加します。 

__members__ = property(lambda self: self.__dir__())

モデルインスタンスの__dict__

これまで、モデルインスタンスの__dict__属性には、モデルのフィールドに対応する属性のみが含まれていました。

複数のデータベース構成をサポートするために、Django1.2はオブジェクトインスタンスに_state属性を追加しました。 この属性は、モデルインスタンスの__dict__に表示されます。 コードが__dict__の反復に依存してフィールドのリストを取得する場合は、_state属性を処理またはフィルターで除外する準備をする必要があります。


テストランナーの終了ステータスコード

テストランナーの終了ステータスコード（tests/runtests.pyおよびpython manage.py test）は、256以上のテストに失敗すると誤った終了ステータスコードが発生したため、失敗したテストの数を表さなくなりました。 テストランナーの終了ステータスコードは、成功（失敗したテストなし）の場合は0、テストの失敗がいくつでもある場合は1になります。 必要に応じて、テストの失敗数は、テストランナーの出力の最後に表示されます。


ModelForm.is_valid()およびModelForm.errors

ModelFormsの検証作業の多くは、モデルレベルに移動されました。 その結果、初めてModelForm.is_valid()を呼び出したり、ModelForm.errorsにアクセスしたり、フォームの検証をトリガーしたりすると、モデルは定置洗浄されます。 この変換は、モデルが保存されたときに発生していました。 モデルの変更されていないインスタンスが必要な場合は、コピーをModelFormコンストラクターに渡す必要があります。


MySQLのBooleanField

以前のバージョンのDjangoでは、MySQLでのモデルのBooleanFieldは、TrueまたはFalseではなく、1または0として値を返していました。 ]; boolはPythonのintのサブクラスであるため、ほとんどの人にとってこれは問題ではありませんでした。 ただし、Django 1.2では、MySQLのBooleanFieldは実際のboolを正しく返します。 これが問題になるのは、BooleanFieldのreprが1または0を印刷することを期待していた場合のみです。


FormSetsのmax_numの解釈の変更

FormSetの処理に加えられた機能拡張の一環として、max_numパラメーターの django.forms.formsets.formset_factory（）および django.formsへのデフォルト値と解釈。 models.modelformset_factory（）関数が少し変更されました。 この変更は、 max_num 引数がインライン管理オブジェクトに使用される方法にも影響します。

以前は、max_numのデフォルト値は0（ゼロ）でした。 次に、FormSetsは、max_numのブール値を使用して、生成されるフォームの数に制限を課すかどうかを決定しました。 0のデフォルト値は、FormSet内のフォームの数にデフォルトの制限がないことを意味しました。

1.2以降、max_numのデフォルト値はNoneに変更され、FormSetsはNoneの値と0の値を区別します。 Noneの値は、フォームの数に制限がないことを示します。 0の値は、最大0のフォームを課す必要があることを示します。 これは、必ずしもフォームが表示されないことを意味するわけではありません。詳細については、 ModelFormSetのドキュメントを参照してください。

max_numに0の値を手動で指定した場合は、FormSetまたは管理者定義を更新する必要があります。

も参照してください

管理者でのインライン関連オブジェクトのJavaScript支援処理


email_re

電子メールアドレスを検証するための文書化されていない正規表現がdjango.form.fieldsからdjango.core.validatorsに移動されました。 インポートを使用している場合は、インポートを更新する必要があります。


1.2で廃止された機能

最後に、Django 1.2は、以前のリリースの一部の機能を廃止しています。 これらの機能は引き続きサポートされていますが、今後数回のリリースサイクルで段階的に廃止されます。

以下の機能のいずれかを利用するコードは、Django1.2でPendingDeprecationWarningを発生させます。 この警告はデフォルトでは無音ですが、Pythonのwarningsモジュールを使用するか、-Wdまたは-Wallフラグを指定してPythonを実行することでオンにできます。

Django 1.3では、これらの警告はDeprecationWarningになり、はサイレントではありません。 Django 1.4では、これらの機能のサポートは完全に削除されます。

も参照してください

詳細については、ドキュメント Djangoのリリースプロセスおよび非推奨のタイムラインを参照してください。`


データベースの指定

Django 1.2より前は、Djangoはいくつかの設定を使用して単一のデータベースへのアクセスを制御していました。 Django 1.2では複数のデータベースのサポートが導入されたため、データベース設定の定義方法が変更されました。

既存のDjango設定ファイルは、Django1.4まで期待どおりに機能し続けます。 それまでは、古いスタイルのデータベース設定が自動的に新しいスタイルの形式に変換されます。

古いスタイル（1.2より前）の形式では、設定ファイルにいくつかのDATABASE_設定がありました。 例えば： 

DATABASE_NAME = 'test_db'
DATABASE_ENGINE = 'postgresql_psycopg2'
DATABASE_USER = 'myusername'
DATABASE_PASSWORD = 's3krit'

これらの設定は現在、：setting： `DATABASES` という名前の辞書にあります。 ディクショナリの各項目は単一のデータベース接続に対応し、名前'default'はデフォルトのデータベース接続を表します。 設定名も短縮されています。 以前のサンプル設定は次のようになります。 

DATABASES = {
    'default': {
        'NAME': 'test_db',
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'USER': 'myusername',
        'PASSWORD': 's3krit',
    }
}

これは、次の設定に影響します。

古い設定 新しい設定
DATABASE_ENGINE ：setting： `ENGINE `
DATABASE_HOST ：setting： `HOST`
データベース名 ：setting： `NAME`
DATABASE_OPTIONS ：setting： `オプション`
DATABASE_PASSWORD ：setting： `PASSWORD`
DATABASE_PORT ：setting： `PORT`
DATABASE_USER ：setting： `USER`
TEST_DATABASE_CHARSET ：setting： `TEST_CHARSET`
TEST_DATABASE_COLLATION ：setting： `TEST_COLLATION`
TEST_DATABASE_NAME ：setting： `TEST_NAME`

これらの変更は、選択したデータベースバックエンドからDatabaseWrapper()を使用してデータベース接続を手動で作成した場合にも必要です。

構造の変更に加えて、Django1.2は組み込みデータベースバックエンドの特別な処理を削除します。 すべてのデータベースバックエンドは、完全修飾モジュール名で指定する必要があります（つまり、postgresql_psycopg2だけでなく、django.db.backends.postgresql_psycopg2）。


postgresqlデータベースバックエンド

psycopg1ライブラリは、2005年10月以降更新されていません。 その結果、このライブラリを使用するpostgresqlデータベースバックエンドは非推奨になりました。

現在postgresqlバックエンドを使用している場合は、postgresql_psycopg2バックエンドの使用に移行する必要があります。 コードを更新するには、psycopg2 ライブラリを変更し、 ：setting： `ENGINE ` 使用する設定django.db.backends.postgresql_psycopg2 。


CSRF応答-ミドルウェアの書き換え

CsrfResponseMiddlewareは、発信ページのPOSTフォームにCSRFトークンを自動的に挿入するミドルウェアであり、テンプレートタグ方式（上記を参照）を優先して非推奨になり、Django1.4で完全に削除されます。 CsrfResponseMiddlewareおよびCsrfViewMiddlewareの機能を含むCsrfMiddlewareも、同様に非推奨になりました。

また、アップグレードノートで説明されているように、CSRFモジュールはcontribからcoreに移動し、古いインポートは非推奨になりました。

ドキュメントが削除されました

アップグレードノートは、現在のDjangoドキュメントから削除されました。 これらの手順については、Django1.3以前のドキュメントを参照してください。


SMTPConnection

SMTPConnectionクラスは非推奨になり、汎用の電子メールバックエンドAPIが採用されました。 SMTPConnectionのインスタンスを明示的にインスタンス化した古いコード： 

from django.core.mail import SMTPConnection
connection = SMTPConnection()
messages = get_notification_email()
connection.send_messages(messages)

… get_connection（）を呼び出して、一般的な電子メール接続をインスタンス化する必要があります。 

from django.core.mail import get_connection
connection = get_connection()
messages = get_notification_email()
connection.send_messages(messages)

：setting： `EMAIL_BACKEND` 設定の値によっては、SMTP接続が返されない場合があります。 電子メールの送信に使用するSMTP接続が明示的に必要な場合は、SMTP接続を明示的に要求できます。 

from django.core.mail import get_connection
connection = get_connection('django.core.mail.backends.smtp.EmailBackend')
messages = get_notification_email()
connection.send_messages(messages)

SMTPConnectionのインスタンスを構築するための呼び出しで追加の引数が必要な場合は、それらの引数を get_connection（）呼び出しに渡すことができます。 

connection = get_connection('django.core.mail.backends.smtp.EmailBackend', hostname='localhost', port=1234)

ユーザーメッセージAPI

ユーザーMessageモデル（user.message_set.create経由）にメッセージを保存するためのAPIは非推奨になり、標準のリリースプロセスに従ってDjango1.4で削除されます。

コードをアップグレードするには、次のインスタンスを置き換える必要があります。 

user.message_set.create('a message')

…次のように： 

from django.contrib import messages
messages.add_message(request, messages.INFO, 'a message')

さらに、この方法を使用する場合は、次のものを置き換える必要があります。 

for message in user.get_and_delete_messages():
    ...

…と： 

from django.contrib import messages
for message in messages.get_messages(request):
    ...

詳細については、メッセージの完全なドキュメントを参照してください。 新しいAPIをすぐに使用するには、コードの更新を開始する必要があります。


日付形式のヘルパー関数

django.utils.translation.get_date_formats()およびdjango.utils.translation.get_partial_date_formats()は非推奨になり、：setting： `USE_L10N` が設定されている場合にロケールを認識するdjango.utils.formats.get_format()への適切な呼び出しが優先されます。 Trueに設定し、Falseに設定するとデフォルト設定にフォールバックします。

これを書く代わりに、異なる日付形式を取得するには： 

from django.utils.translation import get_date_formats
date_format, datetime_format, time_format = get_date_formats()

…使用する： 

from django.utils import formats
date_format = formats.get_format('DATE_FORMAT')
datetime_format = formats.get_format('DATETIME_FORMAT')
time_format = formats.get_format('TIME_FORMAT')

または、日付値を直接フォーマットする場合： 

from django.utils import formats
value_formatted = formats.date_format(value, 'DATETIME_FORMAT')

同じことがdjango.forms.fieldsにあるグローバルにも当てはまります。

  • DEFAULT_DATE_INPUT_FORMATS
  • DEFAULT_TIME_INPUT_FORMATS
  • DEFAULT_DATETIME_INPUT_FORMATS

django.utils.formats.get_format()を使用して、適切な形式を取得します。


機能ベースのテストランナー

Django 1.2は、クラスベースのアプローチを使用するようにテストランナーツールを変更します。 古いスタイルの関数ベースのテストランナーは引き続き機能しますが、新しいクラスベースのランナーを使用するように更新する必要があります。


django.contrib.syndication.feedsのFeed

django.contrib.syndication.feeds.Feedクラスは django.contrib.syndication.views.Feed クラスに置き換えられました。 古いfeeds.Feedクラスは非推奨であり、Django1.4で削除される予定です。

新しいクラスのAPIはほぼ同じですが、インスタンスをビューとして使用できます。 たとえば、次の URLconf で古いフレームワークを使用することを検討してください。 

from django.conf.urls.defaults import *
from myproject.feeds import LatestEntries, LatestEntriesByCategory

feeds = {
    'latest': LatestEntries,
    'categories': LatestEntriesByCategory,
}

urlpatterns = patterns('',
    # ...
    (r'^feeds/(?P<url>.*)/$', 'django.contrib.syndication.views.feed',
        {'feed_dict': feeds}),
    # ...
)

新しいFeedクラスを使用すると、これらのフィードをビューとして直接デプロイできます。 

from django.conf.urls.defaults import *
from myproject.feeds import LatestEntries, LatestEntriesByCategory

urlpatterns = patterns('',
    # ...
    (r'^feeds/latest/$', LatestEntries()),
    (r'^feeds/categories/(?P<category_id>\d+)/$', LatestEntriesByCategory()),
    # ...
)

現在feed()ビューを使用している場合、LatestEntriesクラスは、新しい Feed クラスをサブクラス化する以外に変更する必要がないことがよくあります。 例外は、Djangoがフィードの説明とタイトル要素のレンダリングに使用するテンプレートの名前を自動的に計算していた場合です（title_templateおよびdescription_template属性を指定していなかった場合）。 常にtitle_templateおよびdescription_template属性を指定するか、item_title()およびitem_description()メソッドを指定する必要があります。

ただし、LatestEntriesByCategoryは、get_object()メソッドとbits引数を使用して、表示する特定のカテゴリを指定します。 新しい Feed クラスでは、get_object()メソッドはURLからrequestと引数を受け取るため、次のようになります。 

from django.contrib.syndication.views import Feed
from django.shortcuts import get_object_or_404
from myproject.models import Category

class LatestEntriesByCategory(Feed):
    def get_object(self, request, category_id):
        return get_object_or_404(Category, id=category_id)

    # ...

さらに、Feedクラスのget_feed()メソッドは異なる引数を取るようになりました。これは、Feedクラスを直接使用する場合に影響を与える可能性があります。 オプションのurl引数を取る代わりに、独自のget_object()メソッドによって返されるオブジェクトと現在のrequestオブジェクトの2つの引数を取るようになりました。

Feedクラスがリクエストごとに初期化されないことを考慮に入れるために、__init__()メソッドはデフォルトで引数をとらないようになりました。 以前は、URLとrequestオブジェクトからslugを取得していました。

RSSのベストプラクティスに従って、RSSフィードにatom:link要素が含まれるようになりました。 これを考慮に入れるために、テストを更新する必要があるかもしれません。

詳細については、シンジケーションフレームワークの完全なドキュメントを参照してください。


テクニカルメッセージID

バージョン1.1まで、DjangoはテクニカルメッセージIDを使用して、ローカライザーに日付と時刻の形式を変換する可能性を提供していました。 それらはすべて大文字であるために認識できる翻訳可能な翻訳文字列でした（たとえば、：setting： `DATETIME_FORMAT` 、：setting：` DATE_FORMAT` 、 ：setting： `TIME_FORMAT` ）。 ローカライザーが対応するdjango/conf/locale/<locale name>/ディレクトリのformats.pyファイルでその情報を指定できるようにする、新しいフォーマットローカリゼーションインフラストラクチャを優先して非推奨になりました。


GeoDjango

複数のデータベースをサポートできるようにするために、GeoDjangoデータベースの内部が大幅に変更されました。 後方互換性のない最大の変更は、モジュールdjango.contrib.gis.db.backendの名前が django.contrib.gis.db.backends に変更されたことです。ここで、本格的な空間データベースバックエンドが存在。 次のセクションでは、これらの変更の影響を受けた最も人気のあるAPIに関する情報を提供します。

SpatialBackend

個別の空間バックエンドを作成する前に、django.contrib.gis.db.backend.SpatialBackendオブジェクトは、空間データベースの機能を内省するための抽象化として提供されていました。 SpatialBackendによって提供されるすべての属性とルーチンは、データベースバックエンドのops属性の一部になりました。

古いモジュールdjango.contrib.gis.db.backendは、デフォルトのopsモジュールの単なるエイリアスであるSpatialBackendオブジェクトへの下位互換性アクセスのために引き続き提供されます。空間データベース接続。

SpatialBackendによって提供される抽象化ではなく、django.contrib.gis.db.backend内の文書化されていないモジュールおよびオブジェクトに依存していたユーザーは、コードを変更する必要があります。 たとえば、1.1以下で機能する次のインポート： 

from django.contrib.gis.db.backend.postgis import PostGISAdaptor

変更する必要があります： 

from django.db import connection
PostGISAdaptor = connection.ops.Adapter

SpatialRefSysおよびGeometryColumnsモデル

以前のバージョンのGeoDjangoでは、 django.contrib.gis.db.models には、OGC空間メタデータテーブルspatial_ref_sysとクエリを実行するためのSpatialRefSysモデルとGeometryColumnsモデルがありました。それぞれgeometry_columns。

これらのエイリアスは引き続き提供されますが、 default データベース接続専用であり、デフォルト接続がサポートされている空間データベースバックエンドを使用している場合にのみ存在します。

ノート

OGC空間メタデータテーブルのテーブル構造は空間データベース間で異なるため、SpatialRefSysおよびGeometryColumnsモデルをgisアプリケーション名に関連付けることはできなくなりました。 したがって、次の例でget_modelsメソッドを使用すると、モデルは返されません。 

>>> from django.db.models import get_app, get_models
>>> get_models(get_app('gis'))
[]

空間データベースに適切なSpatialRefSysおよびGeometryColumnsを取得するには、空間バックエンドが提供するメソッドを使用します。 

>>> from django.db import connections
>>> SpatialRefSys = connections['my_spatialite'].ops.spatial_ref_sys()
>>> GeometryColumns = connections['my_postgis'].ops.geometry_columns()

ノート

spatial_ref_sys()およびgeometry_columns()メソッドから返されたモデルを使用する場合でも、デフォルト以外の接続でクエリを実行するときは、正しいデータベースエイリアスを使用する必要があります。 つまり、上記の例のモデルが正しいデータベースを使用していることを確認するには、次のようにします。 

sr_qs = SpatialRefSys.objects.using('my_spatialite').filter(...)
gc_qs = GeometryColumns.objects.using('my_postgis').filter(...)

言語コードno

ノルウェーのブークモールnoで現在使用されている言語コードは、より一般的な言語コードnbに置き換えられています。


関数ベースのテンプレートローダー

Django 1.2は、クラスベースのアプローチを使用するようにテンプレートの読み込みメカニズムを変更します。 古いスタイルの関数ベースのテンプレートローダーは引き続き機能しますが、新しいクラスベースのテンプレートローダーを使用するように更新する必要があります。



「https://www.finddevguides.com/index.php?title=Django/docs/2.2.x/releases/1.2&oldid=94839」から取得
Powered by MediaWiki