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

DjangoにはAPIの安定についてのポリシーがあります。基本的にはDjango1.0向けに開発したコードはDjango1.1になっても変更無しに動きます。 が、バグの改修でどうしても後方互換性が失われる事があります。Django1.0とDjango1.1の間にはほんの少しの違いがあります。

Django1.1にバージョンをあげる前に、下記の変更があなたのコードに影響がないかダブルチェックしてください。もし、影響があるようでしたらコードを修正してください。

• 制約名が変更されました

  Django1.1では、マシンのワードサイズに影響されずに名前を生成するために、データベースの制約名を生成するメソッドを変更しました。この変更は後方互換性を失っている可能性があります。

  32bitのプラットフォームを使っている場合には違いに気づかないでしょう。

  64bitのプラットフォームを使っている場合には management コマンドの　reset で問題があるかもしれません。この変更の前は64bitプラットフォームでは16文字の digest を制約名に使っていました。:

  ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_5e8f10c132091d1e FOREIGN KEY ...
  

  この変更の後では、プラットフォームに関わらず8文字の digest を制約名に使います。:

  ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_32091d1e FOREIGN KEY ...
  

  このため、64bitマシンで生成したテーブルに対して management コマンドの reset を実行できない可能性があります。昔生成した制約名が新しく生成される名前にマッチせず、誤ったSQLが生成されるためです。

  64bitで制約が生成されたアプリケーションを reset したい場合には、事前に古い制約を手動で破棄(drop)してからにしてください。

• テストケースがトランザクション内で実行されるようになりました

  Django1.1では、より良いパフォーマンスがでるよう、トランザクション内でテストが実行されるようになりました。

  既存のテストが、トランザクションの振る舞いをテストする必要がある場合、テスト環境について誤った前提に依存している場合、テストケースに特定の順番が必要な場合には後方互換性を失っています。

  このような場合には、TransactionTestCaseを代わりに使えます。単に新しいロールバックのアプローチでテストケースのエラーを明らかにするだけです。長いテストは正しく書き直さねばなりません。

• SetRemoteAddrFromForwardedFor ミドルウェアを削除しました

  Django1.0には便利のために django.middleware.http.SetRemoteAddrFromForwardedFor を同梱していました。このミドルウェアはProxyの設定により付与される X-Forwarded-For HTTPヘッダを使って、 REMOTE_ADDR ヘッダを上書きするものでした。

  実際の用途としては信頼性に欠ける仕組みで、たとえドキュメントに書かれていたとしても、Djangoに含まれていることでアプリケーション開発者たちに認証ソースとしてREMOTE_ADDRの値が安全だと思い込ませてしまうことになります。

  直接セキュリティの問題ではありませんが、Django1.1のリリースでこのミドルウェアを削除する事に決めました。DeprecationWorningを出力する以外は何もしないクラスに差し替えてあります。

  もし、このミドルウェアに依存してしまっている場合には次のようにアップグレードしてください

  • 処理が削除されるコードを試す
  • 上流のProxyで正しく動作する事を確認し、場合によってはコードを修正します
  • 修正したバージョンのSetRemoteAddrFromForwardedForをプロジェクトに導入します

• アップロードされたファイルの名前はあとからわかります

  Django1.0ではモデルがデータベースに保存される前にディスクに保存されていました。実際のファイル名はデータベースの保存前にわかっ低迷したので、モデルの pre-save シグナルハンドラで参照可能でした。

  Django1.1では、データベースへモデルの保存する際にファイルを保存します。モデルが保存されるまで実際の名前が信頼できません（確定しません）。

• モデルformsetsの保存が変わりました。

  Django1.1ではBaseModelFormSetがModelForm.save()を呼び出すようになりました。

  モデルのformsetsを__init__で変更している場合や、内部的な_total_form_countや_initial_formsetアトリビュートに依存している場合には後方互換性を失っています。これらのアトリビュートはパブリックメソッドに変更されました。

• joinフィルターのエスケープが修正されました

  joinフィルターが接続文字列をエスケープしてしまうことがなくなりました。

  接続文字列をエスケープしてしまう特殊な状況においては後方互換性を失っています。 {{ foo|join:"&" }} と書いていた場合には、 {{ foo|join:"&" }} に書き換えてください。

  以前の振る舞いはバグで、ドキュメントに書かれていたこととは正反対でした。

• redirect_to汎用ビューにpermanent redirects引数を追加しました

  Django1.1では django.views.generic.simple.redirect_to() 汎用ビューに permanent という引数が追加になりました。もし、redirect_toにpermanentという引数を渡してしまっていた場合には、後方互換性が失われています。

1.1で廃止予定となった機能

ひとつの機能が廃止予定としてマークされました。

• adminのビューを登録するのに AdminSite.root() を使わないでください

  以下のようなURLconfは

  (r'^admin/(.*)', admin.site.root),
  

  次のように書き換えてください

  (r'^admin/', include(admin.site.urls)),
  

  コードの書き換えはすぐに開始して、廃止予定のコードは削除してください。

  Django1.1ではAdminSite.rootはPendingDeprecationWarningを送出します。この警告はデフォルトでは表示されません。

  Django1.2では、DeprecationWarningに変わります。この警告は派手に表示されます。

  Django1.3では、AdminSite.root()は削除されます。

1.1の新機能

1290のコミットと、1206のバグフィックス、1万行のドキュメントが追加されています。

1.1の主な新機能は…

• ORMの改善

  Object-relational Mapperに大きく二つ、強化を行いました。集合関数のサポートと、query expressionsの追加です。

  集合関数のサポート

  ORMから集合関数SQLを発行できるようになりました。直に集合関数の結果を返すかQuerySetに集合関数の結果を注釈するか選択できます。

  この機能は新しいメソッド QuerySet.aggregate() と QuerySet.annotate() で利用できます。詳細は the ORM aggregation documentation ドキュメントを参照してください。

  Query Expressions

  Queryが別のフィールドや別の関連するモデルのフィールドを参照できるようになりました。この機能は新しい F オブジェクトで使います。詳細は documentation for F expressions ドキュメントを参照してください。

• Modelの改善

  いくつかの機能がモデルに追加されました。

  UNMANAGEDモデル

  モデルのデータベースライフサイクルをDjangoに管理させるかどうかをコントロールできるようになりました。デフォルトはTrueで、Djangoはsyncdbやresetコマンドでデータベースを作ったり削除したりします。これがデータベースのライフサイクルをDjangoが管理するということです。

  もし、Falseに設定すると、このモデルに関してはテーブルの作成や削除を自動で行うことはなくなります。すでに存在するテーブルやデータベースのビューを使っている場合などに便利です。

  より詳細には、 managedオプションのドキュメント を参照してください。

  Proxyモデル

  Proxyモデルを作れるようになりました。Proxyモデルは、既存のモデルに、新しいテーブルと関連付けることなく、Pythonレベルの振る舞いを追加するサブクラスです。新しいモデルは全データを保持する上位のモデルにプロキシーします。

  詳細は proxy models documentation ドキュメントにあります。この昨日はunmanagedモデルと表面的には似ているので、どう違うのかが how proxy models differ from unmanaged models ドキュメントに記載されています。

  Deferredフィールド

  複雑な状況ではものすごく大きなデータを保持するフィールドが含まれているかもしれませんし、Pythonのオブジェクトに変換するコストが大きいといったことがあるかもしれません。特定にフィールドが必要ないとわかっている時にはデータベースから対象のデータを取り出さないようにできます。

  あたらしいquerysetのメソッド defer() と only() を使います。

• テストの改善

  テスティングフレームワーク にいくつかの機能強化をしました。

  パフォーマンスの向上

  Djangoのテスティングフレームワークを用いて書かれたテストは劇的に早く実行出来るようになりました（多くの場合10倍早くなることもあります）

  django.test.TestCaseを用いたテストでは、テストの最後にデータベースをクリアして再作成していましたが、トランザクションを用いてロールバックすることで、パフォーマンスの向上を達成しました。 詳細とデータベースのサポートに付いての重要な事項は TestCase ドキュメントと TransactionTestCase ドキュメントを参照してください。

  Testクライアントの改善

  テストクライアントに小さいながらも非常に便利な改善を行いました。

  • Client.get() と Client.post() にfollow引数を追加し、自動でリダイレクトに従えるようになりました。リダイレクトの扱いがシンプルになります。
  • テンプレートのコンテキストを簡単に参照できるようになりました。 request.context[key] とするだけで参照できます。いままでは、 request.contextにテンプレートの継承チェーンごとのコンテキストがリストになって入っていました。もし必要であれば、今までのモノも使えます。

• 新しいadminの機能

  adminに格好イイ機能をいくつか追加しました。

  一覧での一括編集

  あたらしい list_editable オプションで一覧でフィールドを編集可能になりました。指定したフィールドは一覧でフォームのウィジェットを用いて表示され、一括で保存できます。

  Adminアクション

  モデルのグループに対して一括で処理を行える adminアクション を定義できるようになりました。 ユーザは一覧で選択したオブジェクトに対して一括で処理を行えるようになります。

  一括で削除を行えるアクションを同梱しています。

• 条件によるビューの処理

  EtagやLast-ModifiedといったHTTPヘッダを使った conditional view processing のサポートを向上しました。条件の確認によって、ビューの処理を簡単に省略できるようになります。多くのビューで速度と帯域を劇的に改善します。

• URLネームスペース

　　URLネームスペースの導入で named URL patterns を改善しました。

簡単に言えば、同じアプリケーションの同じURLを、prefixを変えることでURLConfになんどもインクルードできるようになります。URLの衝突なしに、Djangoのadminのような再利用可能なアプリケーションを登録できるということです。

詳細は the documentation on defining URL namespaces を参照してください。

• GeoDjango

  GeoDjango にいくつかの機能が追加されました。

  • SpatiaLite のサポート - 空間バックエンドとしてSQLiteの空間データベースをサポートしました
  • 地理集合関数(Collect, Extent, MakeLine, Union)と F を追加しました
  • GeoQuerySet に collect, geojson, snap_to_grid メソッドを追加しました
  • GEOSGeometryオブジェクトに新しい一覧メソッドを追加

  詳細は GeoDjango documentation を参照してください。

• その他の改善
  • CSRF対策ミドルウェア を リクエストのチェックを行う CsrfViewMiddleware と、 レスポンスの出力時に処理をする CsrfResponseMiddleware の二つのクラスに分けました。二つの処理を行っていた CsrfMiddleware クラスも後方互換性のために残してありますが、処理に応じて分けられた二つを使ってください。
  • reverse() と reverse() を使っている {% url %} のようなコードで、 DjangoのadminのURLが動作するようになりました。ただしadminのURLを include(admin.site.urls) でセットしている時のみです。
  • URLconfモジュールの include() 関数にURLパターンのシーケンス(patterns()で生成されるもの）を渡せるようになりました。
  • formsのインスタンスに hidden_fields() と visible_fields() という二つのメソッドが追加されました（ the forms overview 参照）。それぞれ hidden のリストを返すものと visible のフィールドを返します。
  • redirect_to 汎用ビューにpermanentキーワード引数を渡せるようになりました。 permanent をTrue で渡すと HTTPステータスコード301の permanent redirect を返します。 False の場合には 302 のtemporary redirect を返します。
  • DateField と DateTimeField に新たに week_day という条件検索が加わりました。 この種別は1（日曜）から7（土曜）の数値を受け取り、曜日の一致するオブジェクトを返します。詳細は the full list of lookup types ドキュメントを参照してください。
  • {% for %} テンプレートタグに {% empty %}が追加されました。 {% for %}タグに空のリストが渡された場合の句です。 the list of build-in template tags ドキュメントを参照してください。
  • 管理コマンドのdumpdateに個々のモデル名を渡せるようになりました。特定のモデルのデータだけをエクスポートできます。
  • safeseq テンプレートフィルターが追加されました。listに大してsafeと同様に動作するものです。listの各アイテムをsafeにします。
  • Cache backends が incr() と decr() コマンドでキャッシュのキーをインクリメント、デクリメントできるようになりました。キャッシュバックエンドがアトミックなインクリメント、デクリメントをサポートしていればこの処理はアトミックに、そして極めて早く動作します。
  • REMOTE_USER環境変数を使った認証バックエンドを利用し、 Webサーバへ認証を委譲 できるようになりました。
  • 新しい django.shortcuts.redirect() 関数でオブジェクトやビュー名、URLを渡して簡単にリダイレクトできるようになりました。
  • postgresql_psycopg2 バックエンドが PostgreSQLのネイティブオートコミット をサポートしました。PostgreSQLに特有の機能ですが、読み込み先行のアプリケーションではかなりの高速化になるでしょう。