Django v1.0 documentation

Django 1.0 リリースノート

revision-up-to:8961 (1.0)

Django 1.0 にようこそ!

3 年もの間、私達が待ち望んで来た瞬間が、ついにやってきました。 Django 1.0 はこれまでの Django の歴史において最も大きなマイルストーンであり、完全主義 者たちが自信を持ってお送りするウェブフレームワークの決定版です。

Django 1.0 は、オープンソースプロジェクトとして、コミュニティによって 3 年 にわたり重ねられてきた開発活動の結晶です。数百もの開発者が Django のコード に貢献し、カタログは 50 もの言語に翻訳されました。そして、今や世界中のあら ゆる分野の開発者が Django を様々な仕事に使っています。

ところで、今日深い話があります。 Django を 2005 年に最初にリリースしたとき、 そのソースを取り出した内部リポジトリのバージョンは 8825 でした。一方、 公開のリポジトリ内で Django 1.0 のリビジョンは 8961 です。Django 1.0 は、 コミュニティの貢献の積み重ねが、プライベートな開発の工数を上回ったまさにそ のときにリリースされたのです。

安定性と互換性の保証

Django 1.0 のリリース から、 API の安定性と将来の互 換性を保証します。簡単にいえば、 Django 1.0 向けに開発したコードは、何も変 更せずに 1.1 で動作し、その後の 1.X リリースでもちょっとした変更しか必要な いのです。

詳細は API の安定性に関するガイド を参照してく ださい。

以前のバージョンと互換性のない変更

Django 1.0 には、 Django 0.96 と互換性のない変更が数多くあります。 0.96 向 けに書かれたアプリケーションを移植したいなら、以下の詳しい移植ガイドを参照 してください:

以前のバージョンと互換性のない変更の詳しいリストは http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges にあります。

Django 1.0 の新しい機能

たくさん!

Django 0.96 以降、 4000 ものコミットを行ない、 2000 個のバグを修正しました。 また、編集/追加/削除したコードは 35 万行にも及びます。また、4 万行もの新 たなドキュメントを追加し、既存の機能も格段に改善しました。

実際、新しくなったドキュメントは、 Django の機能の中でもお気に入りの部分の 一つなので、ここから紹介していきましょう。まず、新しいドキュメントのサイト には、下記の URL からアクセスできます:

http://docs.djangoproject.com/

ドキュメントは大幅な改善と整理の結果、すばらしく生まれ変わりました。専用の 検索機能やインデクスなどもあります。

このドキュメントはまだ 1.0 で登場した全ての機能を網羅しきれていませんが、 ガイドブックの決定版として使えることでしょう。ドキュメントのそこかしこに:

Django 1.0 で新たに登場しました: この機能は Django 1.0 で新たに登場しました。

と書かれていて、どの機能を新たに追加したり変更したりしたのか分かるはずです。

それでは、 1.0 で登場したその他の主要な機能を紹介してゆきましょう:

admin アプリケーションのリファクタ

Django の管理インタフェース (django.contrib.admin) を完全にリファクタし ました。admin の定義を完全にモデル定義から脱カップリングし (モデルから class Admin をなくしました!)、Django の新たなフォーム処理ライブラリ (0.96 から登場した django.newforms で、今後は単に django.forms) を 使うよう、 admin のフレームワークを 書き直しました。また、思い通りに拡張し たりカスタマイズしたりできるようになりました。admin アプリケーションのドキュ メントは、 admin インタフェース にあります。

Unicode 処理の改善

Django の内部処理を、一貫して Unicode を使うようリファクタしました。これに より、非西欧圏のコンテンツやデータの扱い劇的に単純化しました。また、サード パーティライブラリや、Unicode を行儀よく扱えないことのあるシステムとの相互 運用を楽にするためのユーティリティも提供しました。

Unicode リファレンス を参照してください。

Django ORM の改善

Django のオブジェクト-リレーショナルマッパ、つまり Django のモデルクラスと データベースを対応づけ、クエリの発行を仲立ちするためのコンポーネントを、徹 底的なリファクタによって劇的に改善しました。ほとんどの Django ユーザにとっ て、この変更による互換性の問題はありません。データベースを操作している公開 の API に細かい変更がありましたが、ほとんどの変更は ORM の内部コードに対し て施されています。このリファクタのもたらす、以前のバージョンと互換性のない 変更や新たな機能は、 Django の wiki ページ に掲載しています。

テンプレート変数の自動エスケープ

クロスサイトスクリプティング (XSS) 脆弱性に対する安全性をより高めるために、 Django のテンプレートシステムが全ての変数出力を自動的に HTML エスケープする よう変更しました。この挙動はもちろん変更でき、変数やテンプレートの一部を 「安全:safe」(エスケープ不要) や「安全でない:unsafe」(エスケープが必要) に マークできます。この機能の詳しい説明は、 autoescape タグのドキュメ ントにあります。

django.contrib.gis (GeoDjango)

1 年にわたる開発を経て、ワールドクラスの GIS (地理情報システム: Geographic Information Systems) のサポートを contrib アプリケーショ ンの形で Django に追加しました。 GIS のドキュメントはまだプロジェクトの外で メンテナンス中で、まもなく Django のメインドキュメントにマージする予定です。 この機能を作り上げ、完成までこぎつけた Justin Bronn, Jeremy Dunck, Brett Hoerner そして Travis Pinney に深く感謝します。

詳しくは http://geodjango.org/ を参照してください。

プラガブルなファイルストレージ機構

Django 組み込みの FileFieldImageField が、プラガブルなファイル ストレージバックエンドを使えるようになりました。ストレージバックエンドによっ て、アップロードファイルを Django に保存する方法を徹底的にカスタマイズでき ます。詳しくは、 ファイルのドキュメント を参照してく ださい。この困難な仕事を達成した Marty Alchin に深く感謝します。

Jython との互換性

Google Summer of Code プロジェクトを通じて多大な貢献をもたらした Leo Soto に感謝します。彼は Django のコードベースをリファクタし、これまで Jython との互換性を妨げていた部分を除去しました。 Jython はJava で書かれた Python 実装で、 Java 仮想マシンで Python コードを実行できます。 Django はまもなく 登場する Jython 2.5 リリースで動作します。

詳しくは Jython 上で Django を動かす を参照してください。

forms と admin への一般化リレーションの組み込み

一般化リレーションのクラスを django.contrib.contenttypes に移し、 admin インタフェースやエンドユーザのフォームでもサポートしました。詳しくは 一般化リレーションのドキュメント を参照してくだ さい。

INSERT/UPDATE の使い分け

Django で save() メソッドを呼び出したとき、SQL レベルで INSERTUPDATE のどちらを使うかの区別は、ほとんどの場合デフォルトの挙動で問題あ りませんが、たまにどちらかを強制的に用いたほうがよい場合があります。そこで、 モデルの save() にパラメタを追加して、実行する SQL を強制できるようにし ました。詳細と、パラメタを使うときの重要な注意点を、データベース API のドキュ メントに記載してあります。

詳しくは Forcing an INSERT or UPDATE を参照してください。

CacheMiddleware の分割

Django の CacheMiddleware を 3 つのクラスに分割しました。 CacheMiddleware 自体はまだあり、以前の機能をそのまま残していますが、実 際には二つの別々のミドルウェア (キャッシュにデータを入れるミドルウェアと、 キャッシュからデータを取り出すミドルウェア) からなっていて、一つのミドルウェ アにまとまっていると起きる問題を回避できます。

正しい使い方など、詳細は キャッシュのドキュメント に 記載しています。

django.contrib.comments のリファクタ

Google Summer of Code プロジェクトの一環として、 Thejaswi Puthraya が Django にバンドルされているコメントシステムを大幅にリライト/リファクタし、 フレキシビリティとカスタマイズ性をすばらしく向上させました。 詳細なド キュメント と、以前のコメントアプリケーション を使っていた人のための アップグレードガイド も読めるようになりました。

撤廃した機能の除去

以前のバージョンで撤廃した機能としてマークしていた機能や、 1.0 のリリースに 先だって除去を予定していた機能を Django から取り去りました。除去した機能に は、import パス django.newforms (django.forms で import できます) や form_for_model, form_for_instance といったヘルパ関数 (ModelForm に置き換わりました)、そしてディスパッチャやファイルアップロー ド、ファイルストレージリファクタリングなどで置き換えられた機能な どがあります。

既知の問題

私達は、 Django 1.0 を可能な限り安定させるべくベストを尽くしましたが、残念 ながら、このリリースには既知の問題が二つあります。

to_field 指定を含むマルチテーブルモデル継承での問題

マルチテーブルモデル継承 を使う場合、子の モデルで permanent_linkto_field をカスタマイズすると、データベー スの一貫性に関するエラーを引き起こすという問題があるので注意してください。 以下のようなモデルを定義すると、 うまく動きません

class Parent(models.Model):
    name = models.CharField(max_length=10)
    other_value = models.IntegerField(unique=True)

class Child(Parent):
    father = models.OneToOneField(Parent, primary_key=True, to_field="other_value", parent_link=True)
    value = models.IntegerField()

このバグは、次の Django のリリースで修正する予定です。

特定のデータベースに関する注意点

Django は全てのデータベースバックエンドの可能な限り多くの機能をサポートしよ うと試みています。しかしながら、全てのデータベースシステムがまったく同じ機 能を持っているわけではなく、とりわけ Django のサポートしているデータベース の多くはバージョン毎に大きく変化しています。ですから、 サポートしてい るデータベースに関する注意 を参照しておくとよいでしょう: