Django officially supports the following databases:
\nThere are also a number of database backends provided by third parties.
\nDjango berusaha mendukung sebanyak mungkin fitur-fitur pada semua backend basisdata. bagaimanapun, tidak semua backend basisdata sama, dan kami harus membuat perancangan keputusan pada dimana fitur-fitur untuk mendukung dan dimana anggapan kami dapat membuat aman.
\nThis file describes some of the features that might be relevant to Django\nusage. It is not intended as a replacement for server-specific documentation or\nreference manuals.
\nHubungan tetap menghindari kelebihan dari pembangunan-kembali sebuah hubungan pada basisdata dalam setiap permintaan. mereka dikendalikan dengan parameter CONN_MAX_AGE yang menentukan umur waktu maksimal dari setiap hubungan. Itu dapat disetel secara berdiri sendiri untuk setiap basisdata.
The default value is 0, preserving the historical behavior of closing the\ndatabase connection at the end of each request. To enable persistent\nconnections, set CONN_MAX_AGE to a positive integer of seconds. For\nunlimited persistent connections, set it to None.
Django membua sebuah hubungan pada basisdata ketika itu pertama kali membuat sebuah permintaan basisdata. Itu menjaga hubungan ini tetap terbuka dan menggunakan kembali itu dalam permintaan selanjutnya. Django menutup hubungan sekali itu melampau batas umur maksimal ditentukan oleh CONN_MAX_AGE atau ketika itu tidak digunakan lagi.
Secara terperinci, Django otomatis membuha sebuah hubungan pada basisdata kapanpun dia membutuhkan satu dan tidak mempunyai satu -- baik karena ini adalah hubungan pertama, atau karena hubungan sebelumnya telah ditutup.
\nPada permulaan dari setiap permintaan, Django menutup hubungan jika itu telah mencapai umur maksimal. Jika basisdata anda memutuskan hubungan diam setelah beberapa waktu, anda harus menyetel CONN_MAX_AGE pada nilai terendah, sehingga Django tidak berusaha menggunakan hubungan yang telah diputus oleh peladen basisdata. (Masalah ini mungkin hanya berpengaruh situs lalu lintas sangat rendah.)
Pada akhir dari setiap permintaan, Django menutup hubungan jika itu telah mencapai umur maksimalnya atau jika itu dalam keadaan kesalahan yang tidak dapat ditutup. Jika kesalahan basisdata apapun telah muncul selagi mengolah permintaan, Django memeriksa apakah hubungan masih bekerja, dan menutup itu jika itu tidak. Dengan demikian, kesalahan basisdata mempengaruhi kebanyakan satu permintaan; jika hubungan menjadi tidak berguna, permintaan selanjutnya mendapatkan hubungan segar.
\nSejak setiap thread merawat hubungan dia sendiri, basisdata anda harus mendukung setidaknya sebanyak hubungan serentak ketika anda memiliki thread pekerja.
\nTerkadang sebuah basisdata tidak mau diakses oleh kebanyakan dari tampilan anda, sebagai contoh karena itu adalah basisdata dari sebuah sistem luar, atau terima kasih ke penyimpanan sementara. Dalam kasus-kasus itu, anda harus mensetel CONN_MAX_AGE menjadi nilai rendah atau bahkan 0, karena itu tidak masuk akal merawat sebuah hubungan untuk digunakan kembali. Ini akan membantu menjaga sejumlah hubungan serentak pada basisdata kecil ini.
Peladen pengembangan membuat sebuah thread baru untuk setiap permintaan dia tangani, meniadakan pengaruh dari hubungan tetap. Jangan mengadakan mereka selama pengembangan.
\nKetika Django membangun sebuah hubungan ke basisdata, dia menyetel parameter yang sesuai, tergantung pada backend sedang digunakan. Jika anda mengadakan hubungan tetap, pengaturan ini tidak lagi berulang setiap permintaan. jika anda merubah parameter seperti tingkat pemisahan hubungan atau zona waktu, anda harus baik menyimpan kembali awalan Django pada akhir setiap permintaan, memaksa sebuah nilai sesuai pada permulaan dari setiap permintaan, atau meniadakan hubungan tetap.
\nDjango menganggap bahwa semua basisdata menggunakan penyandian UTF-8. Menggunakan penyandian lain mungkn menghasilkan perilaku tidak diharapkan seperti kesalahan "nilai terlalu panjang" dari basisdata anda untuk data yang sah dalam Django. Lihat basisdata catatan khusus dibawah untuk informasi pada bagaimana menyetel basisdata anda dengan benar.
\nDjango supports PostgreSQL 9.5 and higher. psycopg2 2.5.4 or higher is\nrequired, though the latest release is recommended.
\nLihat HOST untuk rincian.
Django butuh parameter berikut untuk hubungan basisdatanya:
\nclient_encoding: 'UTF8',
default_transaction_isolation: 'read committed' secara awalan, atau nilai disetel dalam pilihan hubungan (lihat dibawah),
Jika parameter ini sudah memiliki nilai benar, Django tidak akan mensetel mereka untuk setiap hubugan baru, yang which memperbaiki sedikit penampilan. Anda dapat menkonfigurasi mereka langsung dalam postgresql.conf atau lebih nyaman per pengguna basisdata ALTER ROLE.
Django akan bekerja baik tanpa optimalisasi ini, tetapi setiap hubungan baru akan melakukan beberapa permintaan untuk mensetel parameter ini.
\nSeperti PostgreSQL itu sendiri, awalan Django pada READ COMMITTED isolation level. Jika anda butuh tingkat terpencil tertinggi seperti REPEATABLE READ atau SERIALIZABLE, setel itu dalam bagian OPTIONS dari konfigurasi basisdata anda dalam DATABASES:
import psycopg2.extensions\n\nDATABASES = {\n # ...\n 'OPTIONS': {\n 'isolation_level': psycopg2.extensions.ISOLATION_LEVEL_SERIALIZABLE,\n },\n}\nvarchar dan textLink to this heading#Ketika menentukan db_index=True pada bidang model anda, Django khususnya mengeluarkan pernyataan tunggal CREATE INDEX. Bagaimanapun, jika jenis basisdata untuk bidang adalah baik salah satu varchar atau text (misalnya, digunakan oleh CharField, FileField, dan TextField), kemudian Django akan membuat sebuah indeks tambahan yang menggunakan PostgreSQL operator class untuk kolom. Indeks tambahan diperlukan untuk dengan benar melakukan pencarian yang menggunakan penghubung LIKE dalam SQL mereka, ketika selesai dengan jenis pencarian contains dan startswith.
Jika anda butuh menambahkan sebuah tambahan PostgreSQL (seperti hstore, postgis, dll.) menggunakan perpindahan, gunakan tindakan CreateExtension.
Ketika menggunakan QuerySet.iterator(), Django membuka sebuah server-side cursor. Secara awalan, PostgreSQL menganggap bahwa hanya 10% pertama dari hasil dari kursor permintaan akan diambil. Perencana penerimaan menghabiskan sedikit waktu merencanakan permintaan dan memulai mengembalikan hasil lebih cepat, tetapi ini dapat mengurangi penampilan jika lebih dari 10% dari hasil diambil. Anggapan PostgreSQL pada angka baris diambil untuk kursor permintaan dikendalikan dengan pilihan cursor_tuple_fraction.
Using a connection pooler in transaction pooling mode (e.g. PgBouncer)\nrequires disabling server-side cursors for that connection.
\nKursos sisi-peladen adalah lokal terhadap sebuah hubungan dan tetap terbuka pada akhir dari sebuah transaksi ketika AUTOCOMMIT adalah True. Sebuah transaksi seanjutnya mungkin berusaha mengambil hasil lebih dari kursor sisi-peladen. Dalam suasana pengumpulan transaksi, tidak ada jaminan bahwa transaksi sebelumnya akan menggunakan hubungan sama. Jika sebuah hubungan berbeda digunakan, sebuah kesalahan dimunculkan ketika transaksi mengacu kursor sisi-peladen, karena kursos sisi-peladen hanya tersedia dalam hubungan dimana mereka dibuat.
Satu pemecahan adalah untuk meniadakan kursor sisi peladen untuk sebuah hubungan adalah DATABASES by setting DISABLE_SERVER_SIDE_CURSORS menjadi True.
Keuntungan dari kursor sisi-peladen dalam suasana penggabungan transaksi, anda dapat menyetel another connection to the database untuk melakukan permintaan yang menggunakan kursor sisi-peladen. Hubungan ini butuh salah satu langsung ke basisdata atau ke hubungan pengumpulan dalam suasana sesi pengumpulan.
\nPilihan lain adalah membungkus setiap QuerySet menggunakan kursor sisi-peladen dalam sebuah blok atomic(), karena itu meniadakan autocommit untuk lamanya transaksi. Cara ini, kursor sisi-peladen akan hanya tinggal untuk selama transaksi.
Django menggunakan SERIAL data type PostgreSQL untuk menyimpan peningkatan-otomatis primary key. Sebuah kolom SERIAL dihitung dengan nilai-nilai dari sequence yang menjaga nilai ketersediaan selanjutnya. Secara manual memberikan nilai pada sebuah bidang peningkatan-otomatis tidak memperbaharui urutan bidang, yang mungkin kemudian menyebabkan sebuah pertentangan. Sebagai contoh:
>>> 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')\n...\nIntegrityError: duplicate key value violates unique constraint\n"auth_user_pkey" DETAIL: Key (id)=(1) already exists.\nJika anda butuh menentukan nilai-nilai seperti itu, setel kembali urutan setelah itu menghindari menggunakan sebuah nilai yang sudah dalam tabel. Perintah pengelolaan sqlsequencereset membangkitkan pernyataan SQL untuk melakukan itu.
Anda dapat menggunakan pengaturan TEST['TEMPLATE'] untuk menentukan template (misalnya 'template0') dari mana membuat basis data percobaan.
Anda dapat mempercepat waktu penjalanan percobaan dengan configuring PostgreSQL to be non-durable.
\n\nDjango supports MariaDB 10.2 and higher.
\nTo use MariaDB, use the MySQL backend, which is shared between the two. See the\nMySQL notes for more details.
\nDjango mendukung MySQL 5.6 dan lebih tinggi.
\nFitur inspectdb Django menggunakan basisdata information_schema, yang mengandung rincian data pada semua skema basisdata.
Django mengharapkan basisdata untuk mendukung Unicode (UTF-8 encoding) dan menugaskan ke itu tugas dari memaksa transaksi dan keutuhan referensial. itu adalah penting untuk waspada dari fakta bahwa dua terakhir sebenarnya tidak dipaksa oleh MySQL ketika menggunakan mesin penyimpanan, lihat bagian selanjutnya.
\nMySQL mempunyai beberapa storage engines. Anda dapat merubah mesin penyimpanan awalan dalam konfigurasi peladen.
\nMesin penyimpanan awalan MySQL adalah InnoDB. Mesin ini sepenuhnya transaksional dan mendukung acuan foreign key. Itu adalah pilihan dianjurkan. Bagaimanapun penghitung peningkatan otomatis InnoDB hilang pada pemulaian kembali MySQL karena itu tidak ingat nilai AUTO_INCREMENT, daripada membuat kembali itu sebagai "max(id)+1". Ini mungkin menghasilkan sebuah penggunaan kembali tidak sengaja dari nilai AutoField.
Kekurangan utama dari MyISAM adalah bahwa itu tidak mendukung transaksi atau memaksa batasan foreign-key.
\nMySQL mempunyai sepasang driver yang menerapkan API Basisdata Python digambarkan dalam PEP 249:
\nmysqlclient adalah pengemudi asli. Itu adalah pilihan dianjurkan.
MySQL Connector/Python adalah murni pengemudi Python dari Oracle yang tidak mewajibkan pustaka klien MySQL atau modul Python apapun diluar dari pustaka standar.
Pengemudi ini adalah untaian-aman dan menyediakan hubungan menyatukan.
\nSebagai tambahan pada pengemudi API DB, Django butuh sebuah penyadur mengakses pengemudi basisdata dari ORM nya. Django menyediakan sebuah penyadur untuk mysqlclient selagi Penghubung/Python MySQL termasuk its own.
\nDjango requires mysqlclient 1.4.0 or later.
\nPenghubung/Python MySQL tersedia dari download page. Penyadur Django tersedia dalam versi 1.1.X dan terakhir. itu mungkin tidak mendukung kebanyakan terbitan terakhir dari Django.
\nJika anda berencana menggunakan dukungan timezone Django, gunakan mysql_tzinfo_to_sql untuk memuat tabel zona waktu kedalam basisdata MySQL. Ini harus dilakukan hanya sekali untuk peladen MySQL anda, bukan per basisdata.
\nAnda dapat membuat basisdata anda menggunakan alat baris-perintah dan SQL ini:
\nCREATE DATABASE <dbname> CHARACTER SET utf8;\nIni memastikan semua tabel dan kolom akan menggunakan UTF-8 secara awal.
\nPengaturan pemeriksaan untuk sebuah kolom mengendalikan urutan dimana data diurutkan sama halnya dengan string apa dibandingkan sebagai setara. Itu dapat disetel pada tingkat luas-basisdata dan juga per-tabel dan per-kolom. Itu adalah documented thoroughly dalam dokumentasi MySQL. Dalam semua kasus, anda menyetel pemeriksaan dengan langsung merubah tabel-tabel basisdata; Django tidak menyediakan cara mensetel ini pada sebuah pengertian model.
\nSecara awalan, dengan basisdata UTF-8, MySQL akan menggunakan pemeriksaan utf8_general_ci. Ini menghasilkan dalam semua kesetaraan pembandingan string sedang diselesaikan dalam cara kasus-tidak-peka. Yaitu, "Fred" dan "freD" dianggap tidak sah untuk mencoba memasukkan kedua "aa" and "AA" kedalam kolom sama, sejak mereka membandingkan sebagai kesetaraan (dan, karenanya, bukan-unik) dengan pemeriksaan awalan. Jika anda ingin perbandingan kasus-peka pada kolom atau tabel tertentu, rubah kolom atau tabel untuk menggunakan pemeriksaan utf8_bin.
Harap catat bahwa menurut MySQL Unicode Character Sets, perbandingan untuk pemeriksaan utf8_general_ci adalah lebih cepat, tetapi sedikit kurang benar, daripada perbandingan untuk utf8_unicode_ci. Jika ini diterima untuk aplikasi anda, anda harus menggunakan utf8_general_ci karena itu lebih cepat. Jika ini tidak diterima (sebagai contoh, jika anda membutuhkan urutan kamus Jerman), gunakan utf8_unicode_ci karena itu lebih akurat.
Mengacu ke pengaturan dokumentasi.
\nPengaturan hubungan digunakan dalam urutan ini:
\n\nDengan kata lain, jika anda mensetel nama dari basisdata dalam OPTIONS, ini akan mengambil hak lebih tinggi terhadap NAME, yang akan menimpa apapin dalam MySQL option file.
Ini adalah contoh konfigurasi yang menggunakan berkas pilihan 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\n\n# my.cnf\n[client]\ndatabase = NAME\nuser = USER\npassword = PASSWORD\ndefault-character-set = utf8\nBeberapa MySQLdb connection options lain mungkin berguna, seperti ssl, init_command, dan sql_mode.
sql_modeLink to this heading#Dari MySQL 5.7 selanjutnya dan pada pemasangan segar dari MySQL 5.6, nilai awalan dari pilihan sql_mode mengandung STRICT_TRANS_TABLES. Pilihan itu meningkatkan peringatan menjadi kesalahan ketika data dipotong ketika pemasukan, jadi Django sangat menganjurkan mengaktifkan strict mode untuk MySQL mencegah kehilangan data (antara STRICT_TRANS_TABLES atau STRICT_ALL_TABLES).
Jika anda butuh menyesuaiakan suasana SQL, anda dapat mensetel variabel sql_mode seperti pilihan MySQL lain: antara dalam berkas konfigurasi atau dengan masukan 'init_command': "SET sql_mode='STRICT_TRANS_TABLES'" dalam bagian OPTIONS dari konfigurasi basisdata anda dalam DATABASES.
Ketika menjalankan pemuatan yang bersamaan, transaksi basisdata dari sesi-sesi berbeda (katakan, urutan lain menangani permintaan berbeda) mungkin berinteraksi dengan satu sama lain. Interaksi ini mungkin dipengaruhi oleh setiap transaction isolation level sesi. Anda dapat mensetel tingkat terpencil hubungan dengan sebuah masukan 'isolation_level' dalam OPTIONS bagian dari konfigurasi basisdata anda dalam DATABASES. Nilai sah untuk masukan ini adalah empat sandar tingkat terpencil:
'read uncommitted'
'read committed'
'repeatable read'
'serializable'
or None to use the server's configured isolation level. However, Django\nworks best with and defaults to read committed rather than MySQL's default,\nrepeatable read. Data loss is possible with repeatable read. In particular,\nyou may see cases where get_or_create()\nwill raise an IntegrityError but the object won't appear in\na subsequent get() call.
Ketika Django membangkitkan skema, itu tidak menentukan sebuah mesin penyimpanan, jadi tabel-tabel akan dibuat dengan apapun mesin penyimpanan awalan paladen basisdata anda dikonfigurasikan. Pemecahan paling mudah adalah mensetel mesin penyimpanan awalan peladen basisdata anda pada mesin yang diinginkan.
\nJika anda sedang menggunakan layanan rumahan dan tidak dapat merubah mesin penyimpanan awalan peladen, anda memiliki sepasang pilihan.
\nSetelah tabel dibuat, jalankan sebuah pernyataan ALTER TABLE untuk merubah sebuah tabel ke mesin penyimpanan baru (seperti InnoDB):
ALTER TABLE <tablename> ENGINE=INNODB;\nIni dapat membosankan jika anda memiliki banyak tabel.
\nPilihan lain adalah menggunakan pilihan init_command untuk MySQLdb sebelum membuat tabel anda:
'OPTIONS': {\n 'init_command': 'SET default_storage_engine=INNODB',\n}\nIni menyetel mesin penyimpanan awalan diatas hubungan ke basisdata. Setelah tabel-tabel anda telah dibuat, anda harus memindahkan pilihan ini ketika itu menambahkan sebuah permintaan yaitu hanya dibutuhkan selama pembautan tabel pada setiap hubungan basisdata.
\nAda known issues di bahkan versi terakhir dari MySQL yang dapat menyebabkan kasus dari nama tabel dirubah ketika pernyataan SQL tertentu dijalankan dibawah kondisi tertentu. Itu dianjurkan bahwa anda menggunakan nama tabel huruf kecil, jika memungkinkan, untuk menghindari masalah apapun yang mungkin muncul dari perilaku ini. Django menggunakan nama tabel huruf kecil ketika it membangkitkan-otomatis nama tabel dari mdoel, jadi ini adalah pertimbangan utama jika anda sedang menimpa nama tabel melalui parameter db_table.
Kedua ORM Django dan MySQL (ketika menggunakan InnoDB storage engine) mendukung basisdata savepoints.
\nIf you use the MyISAM storage engine please be aware of the fact that you will\nreceive database-generated errors if you try to use the savepoint-related\nmethods of the transactions API. The reason\nfor this is that detecting the storage engine of a MySQL database/table is an\nexpensive operation so it was decided it isn't worth to dynamically convert\nthese methods in no-op's based in the results of such detection.
\nAny fields that are stored with VARCHAR column types may have their\nmax_length restricted to 255 characters if you are using unique=True\nfor the field. This affects CharField,\nSlugField. See the MySQL documentation for more\ndetails.
TextFieldLink to this heading#MySQL hanya dapat mengindeks karakter N pertama dari kolom BLOB atau TEXT. Sejak TextField tidak memiliki panjang yang ditentukan, anda tidak dapat menanda itu sebagai unique=True. MySQLakan melaporkan: "kolom BLOB/TEXT '<db_column>' digunakan dalam spesifikasi kunci tanpa panjang kunci".
MySQL 5.6.4 dan kemudian dapat menyimpan store bagian detik, disediakan bahwa pengertian kolom termasuk petunjuk bagian (e.g. DATETIME(6)). Versi paling awal tidak mendukung mereka semua.
Django tidak akan meningkatkan kolom yang ada untuk menyertakan bagian detik jika peladen basisdata mendukung itu. Jika anda ingin mengadakan mereka pada basisdata yang ada, itu terserah anda baik secara manual memperbaharui kolom pada basisdata sasaran, dengan menjalankan sebuah perintah seperti:
\nALTER TABLE `your_table` MODIFY `your_datetime_column` DATETIME(6)\natau menggunakan tindakan RunSQL dalam data migration.
TIMESTAMPLink to this heading#Jika anda menggunakan sebuah basisdata warisan yang mengandung kolom TIMESTAMP, anda harus mensetel USE_TZ = False untuk menghindari kerusakan data. inspectdb memetakan kolom-kolom ini pada DateTimeField dan jika anda mengadakan dukungan zona waktu, kedua MySQL dan Django akan berusaha merubah nilai-nilai dari UTC ke waktu lokal.
QuerySet.select_for_update()Link to this heading#MySQL and MariaDB do not support some options to the SELECT ... FOR UPDATE\nstatement. If select_for_update() is used with an unsupported option, then\na NotSupportedError is raised.
Option | \nMariaDB | \nMySQL | \n
|---|---|---|
| \n\n | X (≥8.0.1) | \n
| \nX (≥10.3) | \nX (≥8.0.1) | \n
| \n\n | \n |
When using select_for_update() on MySQL, make sure you filter a queryset\nagainst at least set of fields contained in unique constraints or only against\nfields covered by indexes. Otherwise, an exclusive write lock will be acquired\nover the full table for the duration of the transaction.
Ketika melakukan sebuah permintaan pada jenis string, tetapi dengan sebuah nilai integer, MySQL akan memaksa jenis-jenis dari semua nilai dalam tabel pada sebuah integer sebelum melakukan perbandingan. Jika tabel-tabel anda mengandung nilai 'abc', 'def' dan permintaan anda untuk WHERE mycolumn=0, kedua baris akan cocok. Mirip, WHERE mycolumn=1 akan cocok nilai 'abc1'. Karena itu, bidang-bidang jenis string disertakan dalam Django akan selalu melempar nilai ke sebuah string sebelum menggunakan itu dalam sebuah permintaan.
Jika anda menerapkan bdiang model penyesuaian yang mewarisi dari Field directly, adalah menimpa get_prep_value(), atau menggunakan RawSQL, extra(), atau raw(), anda harus memastikan bahwa anda melakukan typecasting yang sesuai.
Django mendukung SQLite 3.8.3 dan terakhir.
\nSQLite menyediakan cara lain pengembangan yang bagus untuk aplikasi-aplikasi yang terutama hanya-baca atau membutuhkan jejak kaki pemasangan terkecil. Seperti semua peladen basisdata, meskipun, ada beberapa perbendaan yang khusus pada SQLite yang anda harus waspadai.
\nUntuk semua versi SQLite, ada beberapa perilaku sedikit kontra-intuitif ketika berusaha mencocokkan beberapa jenis string. Ini dibangkitkan ketika menggunakan penyaring iexact atau contains dalam Queryset. Perilaku ini memecah menjadi dua kasus:
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.
Some possible workarounds for this are documented at sqlite.org, but they\naren't utilized by the default SQLite backend in Django, as incorporating them\nwould be fairly difficult to do robustly. Thus, Django exposes the default\nSQLite behavior and you should be aware of this when doing case-insensitive or\nsubstring filtering.
\nSQLite has no real decimal internal type. Decimal values are internally\nconverted to the REAL data type (8-byte IEEE floating point number), as\nexplained in the SQLite datatypes documentation, so they don't support\ncorrectly-rounded decimal floating point arithmetic.
SQLite berarti menjadi basisdata ringan, dan demikian tidak dapat mendukung bersamaan tingkat tinggi. Kesalahan OperationalError: bassidata dikunci menunjukkan bahwa aplikasi anda berpengalaman lebih bersamaan daripada sqlite dapat tangani dalam konfigurasi awalan. Kesalahan ini berarti bahwa satu antrian atau proses mempunyai sebuah kunci khusus pada hubungan basisdata dan waktu habis antrian lain menunggu untuk kunci dibebaskan.
Pembungkus SQLite Python mempunyai nilai waktu habis awalan yang menentukan seberapa lama detik urutan diizinkan untuk menunggu penguncian sebelum itu berakhir dan memunculkan kesalahan OperationalError: database is locked.
Jika anda mendapatkan kesalahan ini, anda dapat menyelesaikannya dengan:
\nBerganti ke backend basisdata lain. Pada titik tertentu SQLite menjadi terlalu "ringan" untuk aplikasi dunia-sebenarnya, dan urutan kesalahan bersamaan ini menunjukkan anda telah mencapat titik itu.
Menulis kembali kode anda untuk mengurangi bersamaan dan memastikan transaksi basisdata adalah berumur-pendek.
Meningkatkan nilai waktu habis awalan dengan mengatur pilihan basisdata timeout:
'OPTIONS': {\n # ...\n 'timeout': 20,\n # ...\n}\nThis will make SQLite wait a bit longer before throwing "database is locked"\nerrors; it won't really do anything to solve them.
\nQuerySet.select_for_update() tidak didukungLink to this heading#SQLite tidak mendukung sintaksis SELECT ... FOR UPDATE. Memanggil itu tidak akan memiliki pengaruh.
For most backends, raw queries (Manager.raw() or cursor.execute())\ncan use the "pyformat" parameter style, where placeholders in the query\nare given as '%(name)s' and the parameters are passed as a dictionary\nrather than a list. SQLite does not support this.
QuerySet.iterator()Link to this heading#There are special considerations described in Isolation In SQLite when\nmodifying a table while iterating over it using QuerySet.iterator(). If\na row is added, changed, or deleted within the loop, then that row may or may\nnot appear, or may appear twice, in subsequent results fetched from the\niterator. Your code must handle this.
To use JSONField on SQLite, you need to enable the\nJSON1 extension on Python's sqlite3 library. If the extension is\nnot enabled on your installation, a system error (fields.E180) will be\nraised.
To enable the JSON1 extension you can follow the instruction on\nthe wiki page.
\nDjango supports Oracle Database Server versions 12.2 and higher. Version\n6.0 or higher of the cx_Oracle Python driver is required.
\nUntuk perintah python manage.py migrate bekerja, pengguna basisdata Oracle anda harus mempunyai hak istimewa untuk menjalankan perintah berikut:
CREATE TABLE
CREATE SEQUENCE
CREATE PROCEDURE
CREATE TRIGGER
Untuk menjalankan deretan percobaan proyek, pengguna biasanya butuh hak tambahan ini:
\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
Selagi peran RESOURCE mempunyai hak istimewa yang diwajibkan CREATE TABLE, CREATE SEQUENCE, CREATE PROCEDURE, dan CREATE TRIGGER`, dan seorang pengguna diberikan ``RESOURCE WITH ADMIN OPTION dapat memberikan RESOURCE, pengguna seperti itu tidak dapat memberikan hak istimewa sendiri (yaitu CREATE TABLE), dan demikian RESOURCE WITH ADMIN OPTION tidak biasanya cukup untuk menjalankan percobaan.
Some test suites also create views or materialized views; to run these, the\nuser also needs CREATE VIEW WITH ADMIN OPTION and\nCREATE MATERIALIZED VIEW WITH ADMIN OPTION privileges. In particular, this\nis needed for Django's own test suite.
Semua hak iswimewa ini disertakan dalam peran DBA, yang sesuai untuk digunakan pada basisdata pengembang pribadi.
\nBackend basisdata Oracle menggunakan paket SYS.DBMS_LOB dan SYS.DBMS_RANDOM, jadi pengguna anda akan membutuhkan menjalankan perizinan padanya. Itu secara biasa dapat diakses ke semua pengguna secara awal, tetapi di kasus itu tidak, anda akan butuh memberikan perizinan seperti itu:
GRANT EXECUTE ON SYS.DBMS_LOB TO user;\nGRANT EXECUTE ON SYS.DBMS_RANDOM TO user;\nUntuk menghubungkan menggunakan nama layanan dari basisdata Oracle anda, berkas settings.py anda harus terlihat seperti ini:
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}\nDalam kasus ini, anda harus meninggakan kedua HOST dan PORT kosong. Bagaimanapun, jika anda tidak menggunakan berkas tnsnames.ora atau metode penamaan mirip dan ingin berhubungan menggunakan SID ("xe" dalam contoh ini), kemudian isi kedua HOST dan PORT seperti itu:
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}\nAnda harus salah andara mendukung kedua HOST and PORT, atau meninggalkan kedua sebagai string kosong. Django akan menggunakan deskriptor hubungan berbeda tergantung pada pilihan itu.
Sebuah Full DSN atau string Easy Connect dapat digunakan dalam NAME jika kedua HOST dan PORT adalah kosong. Bentuk ini diwajibkan ketika menggunakan RAC atau basisdata tertanam tanpa tnsnames.ora, sebagai contoh.
Contoh dari Easy Connect string:
\n'NAME': 'localhost:1521/orclpdb1',\nContoh dari string DSN penuh:
\n'NAME': (\n '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))'\n '(CONNECT_DATA=(SERVICE_NAME=orclpdb1)))'\n),\nJika anda berencana menjalankan Django dalam lingkungan banyak antrian (yaitu Apache menggunakan modul MPM awalan pada sistem operasi modern apapun), kemudian anda harus mensetel pilihan threaded dari konfigurasi basisdata Oracle anda menjadi True:
'OPTIONS': {\n 'threaded': True,\n},\nKegagalam melakukan ini akan menyebabkan tabrakan dan perilaku ganjil lain.
\nSecara awalan, backend Oracle menggunakan klausa RETURNING INTO untuk efesian mengambil nilai dari AutoField ketika memasukkan baris baru. Perilaku ini mungkin menghasilkan sebuah DatabaseError dallam pengaturan tidak biasa tertentu, seperti ketika memasukkan kedalam tabel jauh, atau kedalam sebuah tampilan dengan sebuah pemicu INSTEAD OF. Klausa RETURNING INTO dapat ditiadakan dengan mengatur pilihan use_returning_into dari konfigurasi basisdata menjadi False:
'OPTIONS': {\n 'use_returning_into': False,\n},\nDalam kasus ini, backend Oracle akan menggunakan permintaan SELECT terpisah untuk mengambil nilai-nilai AutoField.
Oracle memaksakan batasan panjang nama dari 30 karakter. Untuk mengakomodasi ini, backend memotong penciri basisdata agar cocok, mengganti empat karakter akhir dari nama terpotong dengan sebuah nilai campuran MD5 berulang. Sebagai tambahan, backend merubah penciri basisdata menjadi semua-huruf-besar.
\nUntuk mencegah perubahan ini (ini biasanya hanya membutuhkan ketika berhubungan dengan basisdata warisan atau mengakses tabel-tabel yang milik pengguna lain), gunakan sebuah nama terkutip sebagai nilai untuk db_table:
class LegacyModel(models.Model):\n class Meta:\n db_table = '"name_left_in_lowercase"'\n\nclass ForeignModel(models.Model):\n class Meta:\n db_table = '"OTHER_USER"."NAME_ONLY_SEEMS_OVER_30"'\nNama terkutip dapat juga digunakan dengan backend basisdata didukung lain Django; kecuali untuk Oracle, bagaimanapun, kutipan tidak mempunyai pengaruh.
\nKetika menjalankan migrate, sebuah kesalahan ORA-06552 mungkin ditemui jika kata kunci Oracle tertentu digunakan sebagai nama dari sebuah bidang model atau nilai dari sebuah pilihan db_column. Django mengutip semua penciri digunakan dalam permintaan untuk mencegah kebanyakan masalah seperti itu, tetapi kesalahan ini dapat masih muncul ketika sebuah jenis data oracle digunakan sebagai sebuah nama kolom. Khususnya, hati-hati menghindari penggunaan nama-nama date, timestamp, number atau float sebagai nama bidang.
Django umumnya memilih menggunakan string kosong ('') daripada NULL, tetapi Oracle memperlakukan keduanya mirip. Untuk menyiasati ini, backend Oracle mengabaikan pilihan null tersirat pada bidang yang mempunyai string kosong sebagai nilai kemungkinan dan membangkitkan DDL seolah-olah null=True. Ketika mengambil dari basisdata, itu dianggap bahwa sebuah nilai NULL dalam satu dari bidang-bidang ini sangat berarti string kosong, dan data secara diam dirubah untuk mencerminkan anggapan ini.
TextFieldLink to this heading#Backend Oracle menyimpan TextFields sebagai kolom NCLOB. Oracle memaksakan beberapa pembatasan pada penggunaan seperti kolom LOB secara umum:
Kolom LOB tidak boleh digunakan sebagai primary key.
Kolom LOB tidak boleh digunakan sebagai indeks.
Kolom LOB mugnkin tidak digunakan dalam daftar SELECT DISTINCT. Ini berarti bahwa mencoba menggunakan metode QuerySet.distinct pada sebuah model yang menyertakan kolom TextField akan menghasilkan dalam sebuah kesalahan ORA-00932 ketika berjalan terhadap Oracle. Sebagai pemecahannya, gunakan metode QuerySet.defer dalam berhubungan dengan distinct() untuk mencegah kolom TextField dari menjadi disertakan dalam daftar SELECT DISTINCT.
Django comes with built-in database backends. You may subclass an existing\ndatabase backends to modify its behavior, features, or configuration.
\nConsider, for example, that you need to change a single database feature.\nFirst, you have to create a new directory with a base module in it. For\nexample:
mysite/\n ...\n mydbengine/\n __init__.py\n base.py\nThe base.py module must contain a class named DatabaseWrapper that\nsubclasses an existing engine from the django.db.backends module. Here's an\nexample of subclassing the PostgreSQL engine to change a feature class\nallows_group_by_selected_pks_on_model:
from django.db.backends.postgresql import base, features\n\nclass DatabaseFeatures(features.DatabaseFeatures):\n def allows_group_by_selected_pks_on_model(self, model):\n return True\n\nclass DatabaseWrapper(base.DatabaseWrapper):\n features_class = DatabaseFeatures\nFinally, you must specify a DATABASE-ENGINE in your settings.py\nfile:
DATABASES = {\n 'default': {\n 'ENGINE': 'mydbengine',\n ...\n },\n}\nYou can see the current list of database engines by looking in\ndjango/db/backends.
\nSebagai tambahan pada basisdata didukung resmi, ada backend disediakan oleh pihak ketiga yang mengizinkan anda menggunakan basisdata lain dengan Django:
\n\nVersi Django dan fitur ORM didukung oleh backend tidak resmi sangat beragam. Permintaan mengenai kemampuan khusus dari backend tidak resmi ini, bersama dengan permintaan didukung apapun, harus diarahkan ke saluran pendukung disediakan oleh proyek pihak ke3.
\n