1.2で後方互換性がとれていないもの

• CSRF対策

  CSRF対策に大きな変更をしました。詳細は CSRFドキュメント を参照してください。主に気をつける点は

  • CsrfResponseMiddleware と CsrfMiddleware がdeprecatedとなりDjango1.4で削除されます。テンプレートタグをフォームに追加することにしました。
  • すべてのcontribアプリケーションはcsrf_protectデコレータを使用しています。テンプレートにcsrf_tokenテンプレートタグを使わなければなりません。もしcontribアプリケーションでカスタムテンプレートを使用している場合には、テンプレートの修正のために UPGRADE INSTRUCTIONS を 必ず読んで ください。
  • CsrfViewMiddlewareはMIDDLEWARE_CLASSESに標準で含まれています。CSRF対策が標準でオンになっているので、ビューはCsrfViewMiddlewareが機能するように書かねばなりません。どうすればよいのかはCSRFのドキュメントにあります。
  • CSRFに関するものはすべてcontribからcoreに移動しました。後方互換性のため古い場所からもimportできますが、deprecatedです。

• ifタグを変更しました

  ifテンプレートタグの新しい機能により、今まで使えていた and or not という変数名が使えなくなりました。今まではキーワードとして扱われていましたが場合によっては機能していました。今後は {% if not %} や {% if and %} といったテンプレートのコードは TemplateSyntaxError を送出します。同様に in も新たにキーワードとなり このコンテキストでは有効な変数名ではなくなりました。

• LazyObject

  LazyObjectは不明な型のオブジェクトを遅延ラップするためにあんドキュメントなユーティリティクラスです。 Django1.1以前ではイントロスペクションを通常と違う方法で行っていました。get_all_members()というパブリックメソッドを使っていましたが、名前の衝突をしやすく、通常のメソッド __members__ や __dir__() を使うようにしました。もしLazyObjectを使っており、ラッパにget_all_members()を実装している場合には、次のように変更してください。

  • 特殊なイントロスペクションの必要がないのであれば（通常の方法で発見できない属性を受け入れるメソッドや、__getattr__()を実装したりしていない場合）は単にget_all_members()メソッドを取り除いてください。

  • もし複雑なイントロスペクションが必要な場合にはまずget_all_members()を__dire__()に名前を変更してください。これはPython2.6以降では標準的な方法です。もし、Python2.6未満をサポートしたい場合には次のコードをクラスに追加してください。:

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

• データベースの指定

  Django1.1以前はひとつのデータベースへの接続にいくつかの設定をしていました。Django1.2では複数データベースに対応したので、データベースの設定が変わりました。

  Django1.4までは今までの設定のママ動きます。1.4までは新しい設定に自動的で変換されます。

  古いフォーマットでは DATABASE_ という設定が幾つかありました。こんなものです。

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

  今後はDATABASESという名前の辞書になります。辞書の各エントリがひとつのデータベース接続に対応します。 default という名前のものは デフォルトのデータベース接続の設定です。各設定の名前は短くされています。前述のサンプルは次のようにします。

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

  Old setting	New Setting
  DATABASE_ENGINE	ENGINE
  DATABASE_HOST	HOST
  DATABASE_NAME	NAME
  DATABASE_OPTIONS	OPTIONS
  DATABASE_PASSWORD	PASSWORD
  DATABASE_PORT	PORT
  DATABASE_USER	USER
  TEST_DATABASE_CHARSET	TEST_CHARSET
  TEST_DATABASE_COLLATION	TEST_COLLATION
  TEST_DATABASE_NAME	TEST_NAME

  DatabaseWrapper()を使って手動でデータベース接続を作った場合にもこの変更が必要です。

  この変更に加え、Django1.2はbuild-inのデータベースバックエンドに関する特殊なハンドリングも廃止します。全てのデータベースバックエンドは完全なモジュール名で設定しなければなりません（postgresql_psycopg2のかわりにdjango.db.backends.postgresql_psycopg2のように設定します）。

• modelインスタンスの__dict__

  これまでmodelインスタンスの__dict__はmodelのフィールドに関する属性のみを含んでいました。

  マルチデータベースのサポートにより、Django1.2はのmodelインスタンスは_state属性を持つようになりました。_stateはmodelインスタンスの__dict__に現れますので、__dict__でフィールドのリストを得ている場合には、_state属性をフィルターしなければなりません。

• フィールドのget_db_pre_*()メソッド

  1.2以前ではカスタムフィールドはPython型の値をデータベース型へ変換するための関数を定義できました。カスタムフィールドはこんな感じでした。:

  class CustomModelField(models.Field):
      # ...
      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つのメソッドはシグネチャに変更があり、二つのメソッドが追加されました。

  class CustomModelField(models.Field):
      # ...
      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):
          # ...
  

  These changes are required to support multiple databases -- get_db_prep_* can no longer make any assumptions regarding the database for which it is preparing. The connection argument now provides the preparation methods with the specific connection for which the value is being prepared.

  新しい二つのメソッドはデータベース固有のデータ準備が必要なものと区別するために存在します。prepared引数は汎用的な準備を使うべきかどうかを指し示します。prepared=Falseをget_db_prep_*()に渡した場合にはget_prep_*()を呼び出して汎用的なデータの準備をすべきです。

  古い雛形から新しい雛形へコンバートする関数を提供しますが、Django1.4では削除します。あなたのget_db_pre_*()メソッドでデータベースコネクションが不要であればget_db_prep_value()をget_pre_value()へ、get_db_prep_lookup()をget_prep_lookup()へ名前を変更してください。データベース固有の変換が必要なのであればconnection引数を使ってデータベース固有の値を解決する実装をしてください。

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

  レンダリングの状態をノード自身に持たせたテンプレートタグはあたらしい cached template loader を使った場合に問題が発生するかもしれません。

  Djangoに付属しているテンプレートタグはcached loaderとあわせて使っても問題はありませんが、サードパーティ製のテンプレートタグやあなた自身のコードを使っている場合にはタグがスレッドセーフであることを確認してください。 スレッドセーフについての情報は template tag thread safety considerations を参照してください。

  Djangoのテンプレートタグがスレッドセーフでなかった事に依存して実装した場合にはテンプレートを修正してください。 cycle タグを使っている場合に、特にincludeタグと組み合わせている場合によく影響を受けるでしょう。例えば:

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

  subtemplate.htmlが:

  {% cycle 'even' 'odd' %}
  

  となっていた場合、スレッドセーフでないDjango1.2より前のレンダラの出力は:

  even odd even odd ...
  

  スレッドセーフなDjango1.2以降のレンダラの出力は:

  even even even even ...
  

  各includeタグのレンダリングは独立したレンダリングになったためです。cycleタグがスレッドセーフでなかった時にはcycleタグの状態が複数の同じincludeで漏れ出していたのです。cycleタグはスレッドセーフになったので、この現象はもう起きないのです。

• Testランナーの終了コード

  Testランナー(tests/runtests.pyとpython manage.py test)の終了コードでは失敗したテストの数を出力しなくなりました。256以上失敗した場合には終了コードとして正しくないためです。Testランナーは成功した場合には0を、失敗した場合には1を返しようになりました。失敗した数はTestランナーの出力の最後にあります。

• Cookieエンコーディング

  Internet ExplorerとSafari（場合によっては他のブラウザも）のCookieのバグに対処するため、カンマとセミコロンを安全でない文字として扱うようにしました。それぞれ、 054 と 073 にエンコーディングされます。もしカンマやセミコロンをCookieに格納していて、かつクライアントサイドのJavaScriptでCookieのパース、生成をしている場合には後方互換性を失っています。

• user_passes_test, login_required, permission_required

  django.contrib.auth.decoratorsはlogin_required, permission_required and user_passes_testデコレータを提供していました。これらのデコレータは第一引数にrequestをとる関数でも、第一引数にselfを第二引数に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
  

  1.1以降で追加されたデコレータ csrf_protect, cache_control や decorator_from_middleware を使って作られたデコレータに適用してください。

• ModelForm.is_valid() と ModelForm.errors

  ModelFormの多くのvalidationに関する動作をモデルレベルへ移動しました。結果、最初にModelForm.is_valid()を呼び出した際やModelForm.errorsにアクセスした際、formのvalidationををトリガーしたかに関わらず、同時にモデルがcleanされます。かつてはこの変換はモデルの保存時に行われていました。モデルの変更されていないインスタンスが必要な場合にはコピーをModelFormのコンストラクタに渡してください。

• MySQLのBooleanField

  以前のDjangoではMySQLのBooleanFieldはTrueかFalseの代わりに1か0を返していました。boolはintのサブクラスなので大抵の場合には問題にならないでしょうが、Django1.2ではきちんとboolで返すようになりました。reprの結果としてBooleanFieldが1か0を出力することを想定している場合にのみ問題となるでしょう。

1.2でdeprecatedとしてマークされたもの

• postgresql database backend

  psycopg1ライブラリは2005年10月から更新されていません。postgresqlデータベースバックエンドはこのライブラリに依存しているのでdeprecatedとしました。

  postgresqlバックエンドを使っている場合には postgresql_psycopg2バックエンドへ移行してください。アップグレードは psycopg2ライブらいをインストールして、DATABASE_ENGINEの設定をpostgresql_psycopg2を読むようにするだけです。

• CSRF response-rewriting　ミドルウェア

  Postのformを出力する際にCSRFトークンを埋め込むミドルウェアCsrfResponseMiddlewareはテンプレートタグにすることにしたのでdeprecatedとしました。Django1.4で完全に削除されます。CsrfMiddlewareとCsrfResponseMiddleware、CsrfViewMiddlewareも同様にdeprecatedとなりました。

また、CSRFモジュールはcontribからcoreに移動しました。contribからのimportはdeprecatedと成っています。 upgrading notes を参照してください。

• SMTPConnection

  SMTPConnectionはe-mailバックエンドAPIを利用することにしたのでdeprecatedとしてマークされました。

  古いコードは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)
  

  EMAIL_BACKENDの設定に依存するので、SMTP connectionを返さないかもしれません。 メール送信に利用するSMTP connectionを明示的にしたい場合にはSMTP connectionを明示的に要求できます。

  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)
  

• User Messages API

  ユーザメッセージモデルにメッセージを保存するAPIはdeprecatedとしてマークされました。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):
      ...
  

  より詳しくは messages documentation を参照してください。 すぐにでも新しいAPIを使うようにコードのアップグレードを開始してください。

• 日付フォーマットヘルパー

  django.utils.translation.get_date_formats() と django.utils.translation.get_partial_date_formats() はdeprecatedとしてマークされ、 django.utils.formats.get_format() を明示的に呼ぶようになりました。 USE_L10N が 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() を使ってください。

• email_re

  ドキュメントには書かれていませんでしたが、メールアドレスの検証用正規表現 email_re はdjango.form.fieldsからdjango.core.validatorsへ写されました。もし使っている場合にはimport文を修正してください。

• Feed(django.contrib.syndication.feeds)

  django.contrib.syndication.feeds.Feedクラスはdjango.contrib.syndication.views.Feedクラスに置き換えました。feeds.Feedクラスはdeprecatedとしてマークされ、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クラスのサブクラスにする以外は）。 例外としては、feedの説明とタイトルに使うテンプレートをDjangoが自動で導き出している場合です（title_templateとdescription_templateを指定していない場合です）。 title_templateとdescription_template属性を指定するか、item_title()とitem_description()メソッドを定義するかしなければいけません。

  LatestEntriesByCategoryは特定のカテゴリを表示するためにbitsという引数をとるget_object()メソッドを使います。新しいFeedクラスはget_object()メソッドにrequestとURLからキャプチャした引数をとります。

  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引数を取っていたのが、別の二つの引数をとるようにかわりました。Feedクラスのget_object()メソッドの戻り値と、requestです。

  Feedクラスは毎回初期化されることはないので、デフォルトでは__init__()メソッドは引数をとらないようになりました。以前はURLからキャプチャしたslugとrequestを取っていました。

  RSS best practices にあわせて、RSSフィードは atom:link エレメントを挿入しないようにしました。テストを修正しなければいけないかもしれません。

  より詳細には syndication framework documentation を参照してください。

• TechnicalメッセージID

  Django1.1までは日付と時刻の表示フォーマットをローカライズするために technical message IDs を利用していました。 すべての大文字の国際化文字対象文字列で翻訳ができるようになっていました(DATETIME_FORMATやDATE_FORMAT、TIME_FORMATのようのもの)。 この仕組みはdeprecatedとしてマークされ、新しい 形式のローカライズ に変更しました。対応する 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モジュールは後方互換性のためSpatialBackendへのアクセスが可能ですが、これはデフォルトの空間データベースコネクションのopsモジュールへのエイリアスです。

    django.contrib.gis.db.backendのアンドキュメントなモジュールやオブジェクトに依存している場合にはコードを修正する必要があるでしょう。例えば、1.1では動作した次のようなimportは

    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にSpatialRefSysとGeometryColumnsのモデルが有り、各々OGC空間メタデータテーブルのspatial_ref_sysとgeometry_columnsにクエリを発行していました。

    このエイリアスはまだ提供されますが、デフォルトのデータベース小ネックションで、デフォルトのコネクションが空間データベースバックエンドをサポートしている場合のみです。

    Note

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

    Note

    spatial_ref_sys()とgeometry_columns()メソッドを用いて得たモデルを使うとしても、デフォルトコネクション以外を使う場合には正しいデータベースエイリアスを使う必要があります。上記の例のように得たモデルで正しくデータベースを使うには、

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

• no言語コード

  Norwegian Bokmålの言語コードはnoを使っていましたが、nbに置き換えます

1.2の新機能

• CSRFサポート

  CSRF攻撃 に対する対策を向上しました。この種の攻撃はあなたのウェブサイトにログインしたユーザが悪意のあるサイトを訪れた際に、リンクやフォームのボタン・JavaScriptを用いてあなたのサイトに対する操作を行わせようとするものです。この種の攻撃にあなたのブラウザが他の認証資格でログインさせようとする「ログインCSRF」というものがあり、これもカバーします。

• E-mailバックエンド

  Djangoがメールを送る方法を設定 できるようになりました。メール送信にSMTPを用いる代わりに設定可能なE-mailバックエンドを選択できるようになりました。もしホスティングプロバイダがサンドボックスやSMTP意外の技術でメールを送るようになっている場合、E-mailバックエンドを作成し、Djangoの標準 メール送信メソッド から利用できます。

  メールのデバッグも簡単になります。メールの送信先を ファイルやコンソール、メモリにするバックエンドを同梱します。全部捨ててしまう ようにさえできます。

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

  Djangoはクッキーやセッションベースの、非ログインユーザと認証ユーザをサポートするビルトインのものを含む、 メッセージフレームワーク を提供します。 メッセージフレームワークはdeprecatedなユーザメッセージAPIを置き換えます。リクエスト時に一時的にメッセージを保存し、次のリクエストで取り出して表示できます。

• マルチデータベースサポート

  Django1.2ではプロジェクトで 複数のデータベース を使えるようになります。クエリーはQuerySetオブジェクトのusing()メソッドで指定したデータベースに対して発行できます。個々のオブジェクトはsave()を呼び出す際のusing引数でデータベースを指定して保存できます。

• スマートなifタグ

  ifタグをパワフルに改善しました。第一に比較演算子のサポートをしました。もう次のように記述必要はありません。

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

  こう書けます。

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

  ノスタルジーに浸るタイプでない限り{% ifequal %}や{% ifnotequal %}を使う理由はありません。

  演算子はすでにサポートされている and, or と not に加え、 ==, !=, <, >, <=, >=, in と not inをサポートし、Pythonの演算子のように動作します。

  また、filterがif表現で利用できます。

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

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

  今までのDjangoではテンプレートをレンダリングする度にディスクからロードしていました。Django1.2では キャッシュテンプレートローダ を用いて一度ロードした結果を続のレンダリングのためにキャッシュできるようになりました。{% extends %}や{% include %}タグを使ってテンプレートを細かく分割している場合には著しいパフォーマンスの向上を図れます。

  副作用として、Djangoテンプレート言語以外のサポートがより簡単になりました。詳しくは Djangoテンプレート以外のサポートについて を参照してください。

• fixturesでの自然なキー

  Fixturesで、より 自然なキー を使って別のオブジェクトを参照できるようになりました。この取り出し方は通常のプライマリキーを使ったオブジェクト参照の置換えで、可読性の向上とプライマリキーの値が予測不能な場合や分からない場合の問題を解決します。

• BigIntegerField

  64bitのBigIntegerFieldを使えるようになりました。

• テストの素早い失敗

  test suiteを実行するdjango-admin.pyのtestコマンドとruntests.pyスクリプトが --failfast オプションをサポートしました。このオプションが指定された場合には、テストを続けず、テストに失敗した時点でテストランナーを終了します。加えてCtrl-Cの扱いも向上し、gracefulに終了するようになりました。中断される前までのテストの結果を出力するようになりました。

• ローカライズの向上

  Djangoの 国際化フレームワーク はロケールに従ったフォーマットやフォームの処理ができるように拡張されました。つまり有効にした場合にはテンプレート上の日付や数値が現在のロケールに応じたフォーマットで出力されます。また、フォームのデータもローカライズされたフォーマットでパースします。詳しくは フォーマットのローカライズ を参照してください。

• ModelAdminのreadonly_fields

  django.contrib.admin.ModelAdmin.readonly_fieldsが編集不可なフィールドとして追加／変更ページのモデルとinlinesで使えるようになり、編集可能なフィールドの横に計算結果を表示できるようになりました。

• シンタックスハイライトのカスタマイズ

  DJANGO_COLORS環境変数でdjango-admin.pyの提供する シンタックスハイライト の変更や無効化ができるようになりました。

• モデルの検証

  モデルのインスタンスは 自身のデータを検証 できるようになり、モデルとフォームのフィールドはバリデータのリストを受け付けるようになりました。モデルのバリデーションは明示的に実行しなければならず、モデルインスタンスのsave()メソッドを呼び出しただけではインスタンスのデータの検証は実施されないことに注意してください。

• オブジェクト単位の権限

  オブジェクトごとに権限を指定する下地が追加されました。コアには実装がなく、 django.contrib.auth.models.User で使われるようにカスタム認証バックエンドを実装できます。詳しくは 認証のドキュメント を参照してください。

• 匿名ユーザへの権限

  カスタム認証バックエンドで supports_anonymous_user を True にすると、 AnonymousUser は User がしているのと同様にバックエンドで権限をチェックします。これはアプリケーションが操作の可否の確認をを常に認可／認証バックエンドに委譲し、権限の集中管理をする場合に便利です。詳しくは 認証のドキュメント を参照してください。

• Syndication feedsビュー

  Syndication feeds をURLconfで直にビューとして利用できます。これでフィードをURLの構造を完全に管理できます。他のビューと同様にrequestオブジェクトが渡されるので、通常のビューでしていることができるようになります。ユーザゴトのアクセスコントロールや、フィードを名前付きURLにしたりできます。

• ユーザ名制限の緩和

  ビルトインUserモデルのusernameフィールドが緩和され、@や+や_や-といった広範囲な文字が使えるようになりました。

• 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は PostGIS 1.5 で追加された機能をサポートしています。 geography type のサポートと 地理座標系の distance queries 可能にしました。

  3D geometryフィールドがサポートされ、GeometryFieldのdimキーワードを3に設定すると有効となります。この機能お一部としてExtent3D集合関数とextent3d()メソッドが追加されました。

  以下のGeoQuerySetメソッドが1.2で追加されました。

  • force_rhr()
  • reverse_geom()
  • geohash()

  GEOSインターフェース はプラットフォームで利用可能な場合にはスレッドセーフなCライブラリを使うようになりました。

  GDALインターフェース now allows the user to set a spatial_filter on the features returned when iterating over a Layer.

  GeoDjangoのドキュメント はDjangoのドキュメントに含まれるようになりました。

• adminのinline関連オブジェクトのJavaScriptによるアシスト

  JavaScriptの有効なブラウザを使っている場合にadminのinlineオブジェクトを動的に追加、削除できるようになりました。JavaScriptの使えないブラウザの場合は今までと変わりません。