Django は次のデータベースを公式にサポートしています。
\nサードパーティから提供されているデータベースバックエンド も多数あります。
\nDjango はすべてのデータベースで可能な限り多くの機能をサポートするように努めています。しかし、すべてのデータベースバックエンドが似ているわけではないため、どの機能をサポートし、どのような前提なら安全に想定できるのかについて、設計上の決断を下す必要がありました。
\nこのファイルは Django の利用に関係する可能性のある一部の機能を説明しています。サーバー固有のドキュメントやリファレンスマニュアルを置換することを意図したものではありません。
\n持続的な接続は HTTP リクエストごとにデータベースへの接続を再確立するオーバーヘッドを回避します。持続的な接続は接続の最大寿命を定義する CONN_MAX_AGE パラメータによって制御されます。このパラメータはデータベースごとに個別に設定できます。
デフォルト値は 0 で、各リクエストの終了時にデータベース接続をクローズするという従来の動作を維持します。持続的な接続を有効にするには、 CONN_MAX_AGE に秒単位の正の整数を設定します。持続的な接続を無制限にするには、None に設定します。
ASGI を使用する場合、永続的なデータベース接続は無効にすべきです。代わりに、利用可能であればデータベースバックエンドが提供する接続プーリング機能を使用するか、必要に応じてサードパーティ製の接続プーリングの利用を検討してください。
\nDjango は、最初にデータベースへの問い合わせを行うときに、データベースへの接続をオープンします。Django はこの接続をオープンしたままにしておき、その後のリクエストで再利用します。Django は接続が CONN_MAX_AGE で定義された最大寿命を超えたり、それ以上使えなくなると接続をクローズします。
正確には、Djangoは必要なときに、または接続がない場合（これが最初の接続であるか、前の接続がクローズされていた場合）に自動的にデータベースへの接続をオープンします。
\n各リクエストの最初に、Django は接続が最大寿命に達した場合、接続をクローズします。もしデータベースがアイドル状態の接続をしばらくしてから終了するのであれば、 CONN_MAX_AGE を低い値に設定して、Django がデータベースサーバにすでに終了した接続を使おうとしないようにすべきです。(この問題は、非常にトラフィックの少ないサイトにしか影響しないかもしれません)。
各リクエストの終了時に、 Django は接続が最大寿命に達していたり、回復不可能なエラー状態になっていたりすると、接続をクローズします。リクエストの処理中にデータベースエラーが発生した場合、 Django は接続がまだ動作しているかどうかをチェックし、動作していなければ接続をクローズします。接続が使えなくなると、次のリクエストは新しい接続を取得します。
\nCONN_HEALTH_CHECKS を True に設定することで、接続の再利用の堅牢性を向上させ、データベースサーバーによって接続がクローズされた後に新しい接続を受け入れて提供する準備ができている場合（例えば、データベースサーバーの再起動後など）にエラーを防ぐことができます。ヘルスチェックはリクエストごとに一度だけ実行され、リクエストの処理中にデータベースがアクセスされている場合のみ実行されます。
各スレッドは独自の接続を維持するため、データベースは少なくともワーカースレッドと同数の同時接続をサポートする必要があります。
\nデータベースが外部システムのデータベースであったり、キャッシュのおかげでビューの大部分からアクセスされないことがあります。このような場合、 CONN_MAX_AGE を低い値、あるいは 0 に設定する必要があります。これにより、このデータベースへの同時接続数を少なく保つことができます。
開発用サーバはリクエストを処理するたびに新しいスレッドを生成し、 持続的な接続の効果を無効にします。開発中は有効にしないでください。
\nDjango がデータベースへの接続を確立するとき、使われているバックエンドに応じて適切なパラメータを設定します。持続的な接続を有効にすると、この設定はリクエストの度に繰り返されなくなります。接続の分離レベルやタイムゾーンなどのパラメータを変更した場合は、リクエストの最後に Django のデフォルトに戻すか、リクエストの最初に適切な値を設定するか、持続的な接続を無効にしてください。
\n長時間実行されるプロセスで接続が作成された場合、Django のリクエスト－レスポンスサイクル外では、接続は明示的に閉じるか、タイムアウトが発生するまで開いたままになります。django.db.close_old_connections() を使用して、すべての古いまたは使用できない接続を閉じることができます。
Django はすべてのデータベースが UTF-8 エンコーディングを使用することを想定しています。他のエンコーディングを使用すると、Django にとっては有効なデータに対して、データベースから「value too long (値が大きすぎる)」エラーなどの予期しない動作が起こる可能性があります。データベースを正しく設定する方法については、以下のデータベース固有のノートを確認してください。
\nDjango は PostgreSQL 14 以上をサポートします。 psycopg 3.1.8+ または psycopg2 2.8.4+ が必要ですが、最新の psycopg 3.1.8+ が推奨されます。
\n\n詳細は HOST を参照してください。
connection service file のサービス名と password file のパスワードを使用して接続するためには、それらを DATABASES 内のデータベース設定の OPTIONS 部分で指定しなければなりません。
settings.pyDATABASES = {\n "default": {\n "ENGINE": "django.db.backends.postgresql",\n "OPTIONS": {\n "service": "my_service",\n "passfile": ".my_pgpass",\n },\n }\n}\n.pg_service.conf[my_service]\nhost=localhost\nuser=USER\ndbname=NAME\nport=5432\n.my_pgpasslocalhost:5432:NAME:USER:PASSWORD\nPostgreSQLバックエンドは OPTIONS の内容をキーワード引数として接続コンストラクタに渡します。これにより、ドライバの動作をより高度に制御できます。利用可能なすべての parameters についてはPostgreSQLのドキュメントで詳しく説明されています。
Django はデータベース接続のために次のパラメータが必要です。
\nclient_encoding: 'UTF8',
default_transaction_isolation: デフォルトの 'read committed' または接続オプションで設定した値 (以下を参照)。
これらのパラメータがすでに正しい値を持っている場合、 Django は新しい接続のたびにパラメータを設定しないので、パフォーマンスが少し改善されます。これらのパラメータは postgresql.conf で直接設定することもできますし、 ALTER ROLE でデータベースユーザごとに設定することもできます。
Django はこの最適化なしでも問題なく動作しますが、新しい接続のたびに、これらのパラメータを設定するために追加のクエリを実行します。
\nPostgreSQL 自体と同様に、Django のデフォルトは READ COMMITTED の isolation level に設定されています。REPEATABLE READ や SERIALIZABLE などのより高いレベルの分離レベルが必要な場合は、DATABASES 内のデータベース設定の OPTIONS 部分に指定してください。
from django.db.backends.postgresql.psycopg_any import IsolationLevel\n\nDATABASES = {\n # ...\n "OPTIONS": {\n "isolation_level": IsolationLevel.SERIALIZABLE,\n },\n}\nデータベース接続のためにコネクションの確立に使用するロールとは別のロールを使用する必要がある場合は、次のように DATABASES 内のデータベース設定の OPTIONS 部分で指定してください。
DATABASES = {\n "default": {\n "ENGINE": "django.db.backends.postgresql",\n # ...\n "OPTIONS": {\n "assume_role": "my_application_role",\n },\n },\n}\npsycopg で接続プールを使用するには、DATABASES のデータベース設定内の OPTIONS 部分で "pool" を設定し、これを ConnectionPool に渡す辞書にするか、True に設定して ConnectionPool のデフォルトを使用できます。
DATABASES = {\n "default": {\n "ENGINE": "django.db.backends.postgresql",\n # ...\n "OPTIONS": {\n "pool": True,\n },\n },\n}\nこのオプションは psycopg[pool] または psycopg-pool がインストールされている必要があり、psycopg2 では無視されます。
psycopg 3.1.8+ では、Django のデフォルトは クライアントサイド・バインディングカーソル です。もし サーバーサイド・バインディング を使いたい場合は、 DATABASES のデータベース設定の OPTIONS の部分で設定してください：
DATABASES = {\n "default": {\n "ENGINE": "django.db.backends.postgresql",\n # ...\n "OPTIONS": {\n "server_side_binding": True,\n },\n },\n}\nこのオプションは psycopg2 では無視されます。
varchar カラムと text カラムのインデックスLink to this heading#モデルフィールドに db_index=True を指定すると、Django は通常 1 つの CREATE INDEX ステートメントを出力します。しかし、フィールドのデータベースタイプが varchar か text (例えば、 CharField、 FileField、 TextField で使われます) の場合、Django はカラムに適切な PostgreSQL operator class を使う追加のインデックスを作成します。この追加インデックスは、 contains や startswith のような LIKE 演算子を SQL で使ったルックアップを正しく実行するために必要です。
マイグレーションを使用して PostgreSQL 拡張機能 (hstore や postgis など) を追加する必要がある場合は、 CreateExtension オペレーションを使用してください。
QuerySet.iterator() を使うと、 Django は サーバーサイドカーソル をオープンします。デフォルトでは、PostgreSQL はカーソルクエリの結果の最初の10%だけがフェッチされると仮定しています。クエリプランナはクエリの計画に費やす時間を減らし、より速く結果を返すようになりますが、結果の10%以上が取得された場合、性能が低下する可能性があります。PostgreSQLがカーソルクエリで取得する行数に関する仮定を制御するには、 cursor_tuple_fraction オプションを使用してください。
トランザクションプーリングモード（たとえば、PgBouncer ）で接続プーラを使用するには、その接続のサーバーサイドカーソルを無効にする必要があります。
\nサーバーサイドカーソルは接続に対してローカルに存在し、 AUTOCOMMIT が True の場合、トランザクションの終了時にも接続をオープンしたままにします。後続のトランザクションはサーバーサイドカーソルからより多くの結果を取得しようとするかもしれません。トランザクションプーリングモードでは、後続のトランザクションが同じ接続を使用するという保証はありません。異なる接続が使用される場合、トランザクションがサーバーサイドカーソルを参照する時にエラーが発生します。サーバーサイドカーソルは、それが作成された接続でのみアクセス可能だからです。
一つの解決策は、 DATABASES で DISABLE_SERVER_SIDE_CURSORS を True に設定して、接続のサーバーサイドカーソルを無効にすることです。
トランザクションプーリングモードでサーバーサイドカーソルの恩恵を受けるには、サーバーサイドカーソルを使用するクエリを実行するために、データベースへのもう1つの接続 を設定します。この接続はデータベースに直接接続するか、セッションプーリングモードの接続プーラに接続する必要があります。
\nもう一つの方法は、サーバーサイドのカーソルを使用している QuerySet を atomic() ブロックでラップすることです。これはトランザクションの間、 autocommit を無効にするからです。これにより、サーバーサイドカーソルはトランザクションの間だけ生きることになります。
Django は自動インクリメントの主キーを格納するために PostgreSQL の identity カラムを使います。identity カラムには、次に利用可能な値を追跡する sequence の値が代入されます。自動インクリメントのフィールドに手動で値を代入しても、フィールドのシーケンスは更新されません。たとえば下記のようになります：
\n>>> from django.contrib.auth.models import User\n>>> User.objects.create(username="alice", pk=1)\n<User: alice>\n>>> # The sequence hasn't been updated; its next value is 1.\n>>> User.objects.create(username="bob")\nIntegrityError: duplicate key value violates unique constraint\n"auth_user_pkey" DETAIL: Key (id)=(1) already exists.\nそのような値を指定する必要がある場合は、既にテーブルにある値を再利用しないように、後でシーケンスをリセットしてください。 sqlsequencereset 管理コマンドはそのための SQL 文を生成します。
TEST['TEMPLATE'] 設定を使用すると、テストデータベースを作成するための template (たとえば 'template0') を指定できます。
PostgreSQL を non-durable に設定する ことで、テストの実行時間を短縮できます。
\n\nDjango は MariaDB 10.5 以上をサポートします。
\nMariaDBを使用するには、MySQLバックエンドを使用してください、これは2つの間で共有されています。詳細は MySQL に関するノート を参照してください。
\nDjango は MySQL 8.0.11 以降をサポートしています。
\nDjango の inspectdb 機能は information_schema データベースを使います。このデータベースには全てのデータベーススキーマの詳細なデータが含まれています。
Django は、データベースが Unicode (UTF-8 エンコーディング) をサポートすることを期待し、 トランザクションと参照整合性を強制するタスクを MySQL に委譲します。MyISAM ストレージエンジンを使う場合、MySQL が後者 2 つを実際には強制していないという事実に注意することが重要です。次の節を参照してください。
\nMySQL にはいくつかの storage engines があります。サーバ設定でデフォルトのストレージエンジンを変更できます。
\nMySQL のデフォルトのストレージエンジンは InnoDB です。このエンジンは完全にトランザクショナルで、外部キー参照をサポートしています。推奨される選択です。しかし、InnoDB は AUTO_INCREMENT の値を記憶せず、"max(id)+1" として再作成するため、MySQL の再起動時に自動インクリメントカウンタが失われます。このため、 AutoField の値が不用意に再利用される可能性があります。
MyISAM の主な欠点は、トランザクションをサポートしていないことと、外部キー制約を強制していないことです。
\nMySQL には PEP 249 で説明されている Python Database API を実装したドライバがいくつかあります：
\nmysqlclient はネイティブドライバです。 推奨される選択肢です 。
MySQL Connector/Python は Oracle による純粋な Python ドライバで、MySQL クライアントライブラリや標準ライブラリ以外の Python モジュールを必要としません。
DB API ドライバに加え、Django は ORM からデータベースドライバにアクセスするためのアダプタが必要です。Django は mysqlclient 用のアダプタを提供しますが、MySQL Connector/Python には内蔵のアダプタ (its own) があります。
\nDjango には mysqlclient 1.4.3 以降が必要です。
\nMySQL Connector/Python は download page から入手できます。Django アダプタはバージョン 1.1.X 以降で利用可能です。Django の最新リリースには対応していないかもしれません。
\nDjango の タイムゾーンサポート を使うつもりなら、 mysql_tzinfo_to_sql を使って MySQL データベースにタイムゾーンテーブルを読み込んでください。これはデータベースごとではなく、MySQLサーバーに対して一度だけ行う必要があります。
\nコマンドラインツールで以下のSQLを実行することで、データベースを作成 (create your database) できます:
\nCREATE DATABASE <dbname> CHARACTER SET utf8mb4;\nこれにより、すべてのテーブルとカラムがデフォルトでUTF-8を使用するようになります。
\nカラムの照合順序 (collation) の設定は、どの文字列を等しいものとして比較するかだけでなく、データをソートする順序も制御します。 CharField と TextField には db_collation パラメータを指定して、カラムの照合順序を設定できます。
照合順序はデータベース全体およびテーブルごとに設定することもできます。これについては、MySQL ドキュメント documented thoroughly で詳しく説明されています。このような場合、照合順序はデータベースの設定やテーブルを直接操作して設定する必要があります。Django はそれらを変更する API を提供しません。
\nデフォルトでは、UTF-8 データベースでは、MySQL は utf8mb4_0900_ai_ci 照合順序を使用します。この結果、すべての文字列の等値比較は 大文字小文字を区別しない 方法で行われます。つまり、"Fred" と "freD" はデータベースレベルでは等しいとみなされます。フィールドにユニーク制約がある場合、"aa" と "AA" の両方を同じカラムに挿入しようとするのは不正です。デフォルトの照合順序では等しい (つまり一意ではない) と比較されるからです。特定のカラムやテーブルで大文字小文字を区別して比較したい場合は、そのカラムやテーブルを utf8mb4_0900_as_cs 照合順序を使用するように変更してください。
MySQL Unicode Character Sets によると、照合順序 utf8mb4_general_ci の比較は、utf8mb4_general_ci の比較よりも高速ですが、正しさは若干劣ることに注意してください。もしこれがあなたのアプリケーションで許容できるのであれば、 utf8mb4_general_ci を使うべきです。これが許容できない場合(例えば、ドイツ語の辞書の並び順が必要な場合)、より正確な utf8mb4_general_ci を使用してください。
設定のドキュメント を参照してください。
\n接続設定はこの順番で使用されます：
\n\n言い換えると、OPTIONS でデータベースの名前を設定した場合、これは NAME よりも優先されます。これは MySQL option file の内容を上書きすることになります。
以下は MySQL オプションファイルを使用するサンプル設定です：
\n# settings.py\nDATABASES = {\n "default": {\n "ENGINE": "django.db.backends.mysql",\n "OPTIONS": {\n "read_default_file": "/path/to/my.cnf",\n },\n }\n}\n# my.cnf\n[client]\ndatabase = NAME\nuser = USER\npassword = PASSWORD\ndefault-character-set = utf8mb4\n他にも ssl、init_command、sql_mode などの MySQLdb connection options が役に立ちます。
sql_mode の設定Link to this heading#sql_mode オプションのデフォルト値には STRICT_TRANS_TABLES が含まれています。このオプションは、挿入時にデータが切り捨てられた場合に警告をエラーにエスカレートさせるため、Djangoはデータ損失を防ぐためにMySQLで strict mode を有効にすることを強く推奨します (STRICT_TRANS_TABLES または STRICT_ALL_TABLES のいずれか)。
SQLモードをカスタマイズする必要がある場合は、他のMySQLオプションと同様に sql_mode 変数を設定できます。設定ファイル内、または DATABASES のデータベース設定の OPTIONS 部分に 'init_command': "SET sql_mode='STRICT_TRANS_TABLES'" エントリを追加することで設定できます。
並行読み込みを実行する場合、異なるセッション（例えば、異なるリクエストを処理する別々のスレッド）からのデータベース・トランザクションは互いに影響し合う可能性があります。これらの相互作用は各セッションの transaction isolation level の影響を受けます。接続の分離レベルは DATABASES の OPTIONS 部分にある 'isolation_level' エントリで設定できます。このエントリの有効な値は4つの標準的な分離レベルです：
'read uncommitted'
'read committed'
'repeatable read'
'serializable'
または None でサーバで設定された分離レベルを使用します。しかし、Djangoでは MySQL のデフォルトである repeatable read ではなく、read commited を推奨し、デフォルトとしています。repeatable read ではデータ損失が発生する可能性があります。特に、 get_or_create() は IntegrityError を発生させますが、その後の get() 呼び出しではオブジェクトが表示されないような場合があります。
Django はスキーマを生成するとき、ストレージエンジンを指定しないので、テーブルはデータベースサーバが設定したデフォルトのストレージエンジンで作成されます。最も簡単な解決策は、データベースサーバのデフォルトのストレージエンジンを、希望のエンジンに設定することです。
\nホスティングサービスを利用していて、サーバーのデフォルトストレージエンジンを変更できない場合、いくつかの選択肢があります。
\nテーブルが作成された後、 ALTER TABLE ステートメントを実行して、テーブルを新しいストレージエンジン（InnoDBなど）に変換します：
ALTER TABLE <tablename> ENGINE=INNODB;\nこれはテーブルの数が多い場合、面倒です。
\nテーブルを作成する前に MySQLdb の init_command オプションを使用する方法もあります：
"OPTIONS": {\n "init_command": "SET default_storage_engine=INNODB",\n}\nこれは、データベース接続時のデフォルトのストレージエンジンを設定します。テーブルが作成された後は、このオプションを削除してください。テーブルの作成時にのみ必要なクエリを各データベース接続に追加することになります。
\nMySQL の最新バージョンでも、特定の条件下で特定の SQL 文を実行すると、テーブル名の大文字と小文字が変わってしまうという既知の問題 known issues があります。この動作から発生する可能性のある問題を避けるために、可能であれば小文字のテーブル名を使うことをお勧めします。Django はモデルからテーブル名を自動生成するときに小文字のテーブル名を使うので、これは主に db_table パラメータでテーブル名を上書きする場合に考慮すべき点です。
Django ORM と MySQL (InnoDB ストレージエンジン を使う場合) はどちらも、データベース セーブポイント をサポートしています。
\nMyISAM ストレージエンジンを使用している場合、 トランザクション API のセーブポイント関連メソッド を使おとすると、データベース由来のエラーが発生することに注意してください。これは、MySQL データベース/テーブルのストレージエンジンを検出するのは高コストな操作であるため、このような検出結果に基づいてこれらのメソッドを何もしない関数に動的に変換する価値はないと判断されるためです。
\nフィールドに unique=True を使用している場合、カラムタイプが VARCHAR で格納されているフィールドの max_length が 255 文字に制限される可能性があります。これは CharField, SlugField に影響します。詳細は the MySQL documentation を参照してください。
TextField の制限Link to this heading#MySQL は BLOB または TEXT カラムの最初の N 文字だけをインデックス化できます。 TextField は定義された長さを持たないので、 unique=True としてマークすることはできません。MySQL は次のように報告します： "BLOB/TEXT column '<db_column>' used in key specification without a key length" 。
MySQL では、カラム定義に端数表示 (例: DATETIME(6)) が含まれていれば、秒未満の端数を格納できます。
Django は、データベースサーバがサポートしている場合、既存のカラムを秒未満の端数を含むようにアップグレードしません。既存のデータベースで秒未満のカラムを有効にしたい場合は、以下のようなコマンドを実行して、手動で対象のデータベースのカラムを更新する必要があります：
\nALTER TABLE `your_table` MODIFY `your_datetime_column` DATETIME(6)\nまたは データマイグレーション の RunSQL オペレーションを使用します。
TIMESTAMP カラムLink to this heading#もし TIMESTAMP カラムを含むレガシーデータベースを使用している場合、データの破損を避けるために、USE_TZ = False を設定する必要があります。inspectdb はこれらのカラムを DateTimeField にマッピングし、タイムゾーンサポートを有効にすると、MySQLとDjangoの両方が値をUTCからローカル時間に変換しようと試みます。
QuerySet.select_for_update() による行のロックLink to this heading#MySQL と MariaDB は SELECT ... FOR UPDATE 文のいくつかのオプションをサポートしていません。もし select_for_update() がサポートされていないオプションで使用された場合、 NotSupportedError が発生します。
オプション | \nMariaDB | \nMySQL | \n
|---|---|---|
| \nX (≥10.6) | \nX | \n
| \nX | \nX | \n
| \n\n | X | \n
| \n\n | \n |
MySQL で select_for_update() を使用する場合は、少なくともユニーク制約に含まれるフィールドのセットに対してクエリセットをフィルタリングするか、インデックスがカバーするフィールドに対してだけフィルタリングするようにしてください。そうしないと、トランザクションの間、テーブル全体に対して排他的書き込みロックがかかります。
文字列型で整数値のクエリを実行する場合、MySQL はテーブル内のすべての値の型を整数に強制的に変換してから比較を実行します。テーブルに 'abc', 'def' という値があり、WHERE mycolumn=0 というクエリを実行した場合、両方の行がマッチします。同様に、WHERE mycolumn=1 は値 'abc1' にマッチします。したがって、 Django の文字列型フィールドは、クエリで使う前に必ず値を文字列にキャストします。
Field を直接継承したカスタムモデルフィールドを実装したり、 get_prep_value() をオーバーライドしたり、 RawSQL、 extra()、 raw() をオーバーライドする場合は、適切な型キャストを行う必要があります。
Django は SQLite 3.31.0 以上をサポートします。
\nSQLite は、主に読み取り専用であったり、より小さなインストール容量を必要とするアプリケーションのための優れた開発代替手段を提供します。しかし、すべてのデータベースサーバと同様に、SQLite 固有の注意すべき違いがいくつかあります。
\nすべての SQLite バージョンにおいて、特定の種類の文字列を照合しようとした際に、やや直感に反する動作をします。これは、クエリセットで iexact や contains フィルターを使用した場合に発生します。この動作は、次の二つのケースに分かれます。
1. For substring matching, all matches are done case-insensitively. That is a\nfilter such as filter(name__contains="aa") will match a name of "Aabb".
2. For strings containing characters outside the ASCII range, all exact string\nmatches are performed case-sensitively, even when the case-insensitive options\nare passed into the query. So the iexact filter will behave exactly\nthe same as the exact filter in these cases.
この回避策はドキュメント化されています documented at sqlite.org が、Django のデフォルトの SQLite バックエンドでは利用されていません。それらを堅牢に組み込むのはかなり難しいからです。そのため、Django はデフォルトの SQLite の動作を踏襲しており、大文字小文字を区別しないフィルタリングや部分文字列フィルタリングを行う際には、このことを意識する必要があります。
\nSQLiteには本物の10進数の内部型はありません。 SQLite datatypes documentation で説明されているように、10進数の値は内部的に REAL データ型 (8バイトの IEEE 浮動小数点数) に変換されます。
SQLite は軽量なデータベースであるため、高い並行性をサポートすることはできません。 OperationalError: database is locked のエラーは、アプリケーションがデフォルト設定の sqlite で扱える以上の同時実行を試行していることを示しています。このエラーは、あるスレッドまたはプロセスがデータベース接続を排他的にロックし、別のスレッドがロックが解除されるのを待ってタイムアウトしたことを意味します。
Python の SQLite ラッパーにはデフォルトのタイムアウト値があり、2番目のスレッドがタイムアウトして OperationalError: database is locked というエラーを発生させるまでに、どれだけの時間ロックを待つことができるかを決めます。
このエラーが発生した場合は、次の方法で解決できます：
\n他のデータベース・バックエンドに乗り換えることです。ある段階でSQLiteは実世界のアプリケーションには "軽すぎる "ようになり、この種の同時実行エラーはその段階に達していることを示しています。
並行処理を減らし、データベーストランザクションが短時間で終了するようにコードを書き換えます。
データベースオプションの timeout を設定することで、デフォルトのタイムアウト値を増やすことができます：
"OPTIONS": {\n # ...\n "timeout": 20,\n # ...\n}\nこれはSQLiteが "データベースがロックされています" エラーを発生させるまで少し待機させます。解決するために何かするわけではありません。
\nSQLite は DEFERRED、IMMEDIATE、および EXCLUSIVE の3 種類のトランザクションモードをサポートしています。
デフォルトは DEFERRED です。異なるモードを使用する必要がある場合は、DATABASES のデータベース設定内の OPTIONS 部分で設定します。例えば、次のように設定できます：
"OPTIONS": {\n # ...\n "transaction_mode": "IMMEDIATE",\n # ...\n}\nトランザクションが timeout の時間が経過するまで待機し、 "Database is Locked" エラーを発生させないようにするには、トランザクションモードを IMMEDIATE に変更してください。
IMMEDIATE および EXCLUSIVE モードで最良のパフォーマンスを得るためには、トランザクションはできるだけ短くする必要があります。すべてのビューでこれを保証するのは難しい場合があるため、この場合、ATOMIC_REQUESTS の使用は推奨されません。
詳細については、Transactions in SQLite を参照してください。
\nQuerySet.select_for_update() はサポートされていません。Link to this heading#SQLite は SELECT ... FOR UPDATE 構文をサポートしていません。これを呼び出しても何も起こりません。
QuerySet.iterator() を使用する際の分離の問題Link to this heading#QuerySet.iterator() を使用してテーブルをイテレートしながらテーブルを変更する場合、 Isolation In SQLite で説明されている特別な注意点があります。ループ内で行が追加、変更、削除された場合、その行はイテレータからフェッチされた後続の結果に現れるかもしれませんし、現れないかもしれません。コード内でこれを処理する必要があります。
SQLite で JSONField を使うには、Python の sqlite3 ライブラリで JSON1 extension を有効にする必要があります。拡張機能が有効になっていない場合、システムエラー (fields.E180) が発生します。
JSON1 拡張機能を有効にするには、 the wiki page の手順に従ってください。
\n\nPragma options は、接続時に DATABASES のデータベース設定内の OPTIONS 部分で init_command を使用して設定できます。以下の例では、同期書き込みの耐久性を強化し、cache_size を変更する方法を示しています：
DATABASES = {\n "default": {\n "ENGINE": "django.db.backends.sqlite3",\n # ...\n "OPTIONS": {\n "init_command": "PRAGMA synchronous=3; PRAGMA cache_size=2000;",\n },\n }\n}\nDjango は Oracle Database Server バージョン 19c 以降をサポートしています。バージョン 2.3.0 以上の oracledb Python ドライバが必要です。
\n\npython manage.py migrate コマンドを動作させるには、Oracleデータベースユーザーが以下のコマンドを実行する権限を持っている必要があります：
CREATE TABLE
CREATE SEQUENCE
CREATE PROCEDURE
CREATE TRIGGER
プロジェクトのテスト・スイートを実行するには、通常、ユーザーはこれらの 追加 権限を必要とします：
\nCREATE USER
ALTER USER
DROP USER
CREATE TABLESPACE
DROP TABLESPACE
CREATE SESSION WITH ADMIN OPTION
CREATE TABLE WITH ADMIN OPTION
CREATE SEQUENCE WITH ADMIN OPTION
CREATE PROCEDURE WITH ADMIN OPTION
CREATE TRIGGER WITH ADMIN OPTION
RESOURCE ロールは CREATE TABLE, CREATE SEQUENCE, CREATE PROCEDURE, CREATE TRIGGER の権限を持っており、RESOURCE WITH ADMIN OPTION を与えられたユーザは RESOURCE を与えることができますが、個々の権限 (例えば CREATE TABLE) を与えることはできません。そのため、RESOURCE WITH ADMIN OPTION は通常テストの実行には十分ではありません。
これらを実行するには、ユーザは CREATE VIEW WITH ADMIN OPTION と CREATE MATERIALIZED VIEW WITH ADMIN OPTION 権限も必要です。特に、これは Django 自身のテストスイートに必要です。
これらの権限はすべて DBA ロールに含まれており、プライベートな開発者のデータベースで使用するのに適しています。
\nOracle データベースのバックエンドは SYS.DBMS_LOB パッケージと SYS.DBMS_RANDOM パッケージを使用しているので、ユーザーには実行パーミッションが必要です。通常はデフォルトですべてのユーザーがアクセス可能ですが、そうでない場合は以下のようにパーミッションを付与する必要があります：
GRANT EXECUTE ON SYS.DBMS_LOB TO user;\nGRANT EXECUTE ON SYS.DBMS_RANDOM TO user;\nOracle データベースのサービス名を使用して接続するには、settings.py ファイルを次のように設定します：
DATABASES = {\n "default": {\n "ENGINE": "django.db.backends.oracle",\n "NAME": "xe",\n "USER": "a_user",\n "PASSWORD": "a_password",\n "HOST": "",\n "PORT": "",\n }\n}\nこの場合、HOST と PORT の両方を空のままにします。しかし、tnsnames.ora ファイルや同様の命名メソッドを使用せず、SID（この例では "xe"）を使用して接続したい場合は、次のように HOST と PORT の両方を入力します：
DATABASES = {\n "default": {\n "ENGINE": "django.db.backends.oracle",\n "NAME": "xe",\n "USER": "a_user",\n "PASSWORD": "a_password",\n "HOST": "dbprod01ned.mycompany.com",\n "PORT": "1540",\n }\n}\nHOST と PORT の両方を指定するか、両方を空文字列のままにしてください。Django はその選択によって異なる接続記述子を使います。
HOST と PORT の両方が空の場合、NAME に Full DSN または Easy Connect 文字列を使用できます。このフォーマットは、例えば tnsnames.ora のない RAC やプラガブル (pluggable) なデータベースを使用する場合に必要です。
Easy Connect 文字列の例：
\n"NAME": "localhost:1521/orclpdb1"\nFull DSN 文字列の例：
\n"NAME": (\n "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))"\n "(CONNECT_DATA=(SERVICE_NAME=orclpdb1)))"\n)\nTo use a connection pool with oracledb, set "pool" to True in the\nOPTIONS part of your database configuration. This uses the driver's\ncreate_pool() default values:
DATABASES = {\n "default": {\n "ENGINE": "django.db.backends.oracle",\n # ...\n "OPTIONS": {\n "pool": True,\n },\n },\n}\nドライバの create_pool() 関数にカスタムパラメータを渡したい場合は、代わりに "pool" を辞書として設定することができます。
DATABASES = {\n "default": {\n "ENGINE": "django.db.backends.oracle",\n # ...\n "OPTIONS": {\n "pool": {\n "min": 1,\n "max": 10,\n # ...\n }\n },\n },\n}\nDjango をマルチスレッド環境 (例えば、最近のオペレーティングシステムでデフォルトの MPM モジュールを使った Apache など) で動作させたい場合は、 Oracle データベースの設定の threaded オプションを True に設定する必要があります：
"OPTIONS": {\n "threaded": True,\n}\nこれを行わないと、クラッシュその他の異常な動作が発生する可能性があります。
\nデフォルトでは、Oracle バックエンドは新しい行を挿入するときに AutoField の値を効率的に取得するために RETURNING INTO 句を使用します。 この動作は、リモートテーブルへの挿入や INSTEAD OF トリガを使用したビューへの挿入など、特殊なセットアップの場合に DatabaseError を引き起こす可能性があります。 RETURNING INTO 句は、データベース設定の use_returning_into オプションを False に設定することで無効にできます：
"OPTIONS": {\n "use_returning_into": False,\n}\nこの場合、Oracle バックエンドは個別の SELECT クエリを使って AutoField の値を取得します。
Oracle では、名前の長さに 30 文字という制限があります。これに対応するため、バックエンドはデータベース識別子を適当な長さに切り詰め、切り詰めた名前の最後の4文字を繰り返し使用可能なMD5ハッシュ値に置き換えます。さらに、バックエンドはデータベース識別子をすべて大文字にします。
\nこのような変換を防ぐには（通常、レガシーデータベースを扱う場合や、他のユーザーのテーブルにアクセスする場合にのみ必要です）、db_table の値として引用符で囲まれた名前を使用します：
class LegacyModel(models.Model):\n class Meta:\n db_table = '"name_left_in_lowercase"'\n\n\nclass ForeignModel(models.Model):\n class Meta:\n db_table = '"OTHER_USER"."NAME_ONLY_SEEMS_OVER_30"'\n引用符で囲まれた名前は、Django がサポートしている Oracle 以外の他のデータベースバックエンドでも使用できます。ただし、引用符には効果がありません。
\nmigrate を実行すると、特定の Oracle キーワードがモデルフィールド名や db_column オプションの値として使われた場合に、 ORA-06552 エラーが発生することがあります。 Django はクエリで使われる全ての識別子を引用符で囲むことで、このような問題のほとんどを 防ぎますが、Oracle のデータ型がカラム名として使われると、このエラーが発生する可能性が あります。 特に、フィールド名として date, timestamp, number, float を使わないように注意してください。
Django は通常、 NULL よりも空文字列 ('') を好んで使いますが、 Oracle はどちらも同じように扱います。これを回避するために、 Oracle バックエンドは、空の文字列を値とするフィールドの明示的な null オプションを無視し、 null=True であるかのように DDL を生成します。データベースから取得する際、これらのフィールドの NULL 値は本当に空の文字列を意味すると仮定され、この仮定を反映するようにデータは静かに変換されます。
TextField の制限Link to this heading#Oracle バックエンドでは、それぞれの TextField を NCLOB カラムとして保存します。一般に、Oracle はこのような LOB カラムの使用にいくつかの制限を課しています。
LOBカラムは主キーとして使用できません。
LOB 列はインデックスでは使用できません。
LOB 列は SELECT DISTINCT リストでは使用できません。つまり、Oracle に対して TextField 列を含むモデルで QuerySet.distinct メソッドを使用すると、ORA-00932 エラーが発生します。回避策として、 QuerySet.defer メソッドと distinct() を併用して、 TextField 列が SELECT DISTINCT リストに含まれないようにしてください。
Django には組み込みのデータベースバックエンドが付属しています。既存のデータベースバックエンドをサブクラス化して、その動作や機能、設定を変更できます。
\nたとえば、データベースの機能を一つだけ変更する必要があるとします。まず、base モジュールを含む新しいディレクトリを作成します。たとえば：
mysite/\n ...\n mydbengine/\n __init__.py\n base.py\nbase.py モジュールには、 django.db.backends モジュールの既存のエンジンをサブクラス化した DatabaseWrapper というクラスを含める必要があります。以下は、PostgreSQL エンジンをサブクラス化して allows_group_by_selected_pks_on_model という機能を変更する例です：
mysite/mydbengine/base.pyfrom django.db.backends.postgresql import base, features\n\n\nclass DatabaseFeatures(features.DatabaseFeatures):\n def allows_group_by_selected_pks_on_model(self, model):\n return True\n\n\nclass DatabaseWrapper(base.DatabaseWrapper):\n features_class = DatabaseFeatures\n最後に、settings.py ファイルで DATABASE-ENGINE を指定する必要があります：
DATABASES = {\n "default": {\n "ENGINE": "mydbengine",\n # ...\n },\n}\n現在のデータベースエンジンのリストは django/db/backends で見ることができます。
\n公式にサポートされているデータベースに加え、サードパーティが提供するバックエンドがあり、Django で他のデータベースを使うことができます：
\nこれらの非公式のバックエンドがサポートする Django のバージョンと ORM の機能は、バックエンドによって大きく異なります。これらの非公式なバックエンドの特定の機能に関する質問や、サポートに関する質問は、各サードパーティプロジェクトが提供するサポートチャンネルに直接問い合わせてください。
\n