Базы данных ¶
Django официально поддерживает следующие базы данных:
Есть также ряд движков баз данных, предоставленных сторонними источниками .
Django пытается включить как можно больше функций для всех типов баз данных. Однако не все типы баз данных созданы равными, и нам пришлось принять проектные решения о том, какие функции включить и на какие допущения можно безопасно полагаться.
В этом файле описаны некоторые функции, которые могут иметь отношение к использованию Django. Он не предназначен для замены документации по серверу или справочных руководств.
Общие замечания ¶
Постоянные соединения ¶
Постоянные соединения избавляют от необходимости повторно устанавливать соединение с базой данных для каждого запроса. Они контролируются настройкой, CONN_MAX_AGE
которая определяет максимальное время жизни соединения. Этот параметр можно установить независимо для каждой базы данных.
По умолчанию 0
сохраняется историческое поведение закрытия соединения с базой данных в конце каждого запроса. Чтобы разрешить постоянные соединения, задайте CONN_MAX_AGE
положительное целое число секунд. Чтобы сделать постоянные соединения неограниченными по времени, установите для него значение None
.
Управление подключениями ¶
Django открывает соединение с базой данных по первому запросу базы данных. Это соединение остается открытым и повторно используется для последующих запросов. Django закрывает соединение, как только истечет установленный срок CONN_MAX_AGE
или соединение больше не будет использоваться.
В деталях, Django автоматически открывает соединение с базой данных всякий раз, когда это необходимо, и его еще нет - либо потому, что это первое соединение, либо потому, что предыдущее соединение. был закрыт.
Перед каждым запросом к базе данных Django закрывает соединение, если достигнуто ограничение по времени. Если ваша база данных завершает незанятые соединения через определенное время, вы должны установить для него CONN_MAX_AGE
более низкое значение, чтобы Django не пытался использовать соединение, которое было прервано сервером базы данных (эта проблема не может повлиять на чем сайты с очень низкой посещаемостью).
В конце каждого запроса к базе данных Django закрывает соединение, если соединение достигло ограничения по времени или если оно находится в состоянии фатальной ошибки. Если при обработке запросов возникли какие-либо ошибки базы данных, Django проверяет, работает ли соединение, и закрывает его, если это не так. Таким образом, ошибки базы данных влияют не более чем на один запрос; если соединение становится непригодным для использования, следующий запрос получает новое соединение.
Предостережения ¶
Поскольку каждый поток управляет своим собственным подключением, база данных должна поддерживать как минимум столько одновременных подключений, сколько существует рабочих потоков для Django.
Иногда большинство представлений не имеют доступа к определенной базе данных, например, потому что это база данных внешней системы или через кеширование. В этом случае следует установить CONN_MAX_AGE
низкое значение или даже значение 0
, поскольку нет смысла поддерживать соединение, которое вряд ли будет использоваться повторно. Это поможет сохранить небольшое количество одновременных подключений к этой базе данных.
Сервер разработки создает новый поток для каждого обрабатываемого запроса, сводя на нет эффект постоянных подключений. Не активируйте их во время разработки.
Когда Django подключается к базе данных, он устанавливает соответствующие параметры в зависимости от типа используемой базы данных. Если вы включаете постоянные соединения, эта фаза настройки не повторяется для каждого запроса. Если вы меняете такие параметры, как уровень изоляции соединения или часовой пояс, вы должны либо восстановить Django до настроек по умолчанию в конце каждого запроса, либо принудительно установить соответствующее значение перед каждым запросом, либо отключить соединения. упорный.
Характер кодирования ¶
Django предполагает, что все базы данных используют кодировку UTF-8. Использование других кодировок может привести к неожиданному поведению, например к ошибкам базы данных «слишком длинное значение» для данных, допустимых в Django. См. Примечания к базе данных ниже, чтобы узнать, как правильно настроить базу данных.
Примечания к PostgreSQL ¶
Django поддерживает PostgreSQL 9.5 и новее. Требуется psycopg2 2.5.4 или новее, хотя рекомендуется использовать более новую версию.
Оптимизация конфигурации PostgreSQL ¶
Для подключения к базам данных Django необходимы следующие параметры:
client_encoding
:'UTF8'
,default_transaction_isolation
: по умолчанию или значение, определенное в параметрах подключения (см. ниже),'read committed'
Если эти параметры уже имеют правильные значения, Django не придется предоставлять их для каждого нового соединения, что немного улучшает производительность. Вы можете настроить их напрямую postgresql.conf
или более удобно для каждого пользователя базы данных с помощью ALTER ROLE .
Django отлично работает без этой оптимизации, но каждое новое соединение будет делать еще несколько запросов для установки этих параметров.
Уровень изоляции ¶
Как и в случае с самим PostgreSQL, Django по умолчанию использует "уровень изоляции " . Если вам нужен более высокий уровень изоляции, такой как или , установите его в части конфигурации базы данных :READ COMMITTED
REPEATABLE READ
SERIALIZABLE
OPTIONS
DATABASES
import psycopg2.extensions
DATABASES = {
# ...
'OPTIONS': {
'isolation_level': psycopg2.extensions.ISOLATION_LEVEL_SERIALIZABLE,
},
}
Заметка
При более высоких уровнях изоляции ваше приложение должно быть готово обрабатывать исключения, которые генерируются во время сбоев сериализации. Эта опция предназначена для опытных пользователей.
Указатель столбцов varchar
и text
¶
Когда вы заполняете db_index=True
поля шаблона, Django обычно генерирует только одно . Однако, если тип поля базы данных - или (например, для полей типа , или ), то Django создает дополнительный индекс, который использует соответствующий класс операторов PostgreSQL для столбца. Этот дополнительный индекс необходим для правильного функционирования поиска, использующего оператор SQL , как и поиск с использованием и .CREATE INDEX
varchar
text
CharField
FileField
TextField
LIKE
contains
startswith
Операция миграции для добавления расширений ¶
Если вам нужно добавить расширение PostgreSQL (например hstore
, postgis
и т. Д.) С помощью миграции, используйте операцию CreateExtension
.
Курсоры на стороне сервера ¶
При использовании QuerySet.iterator()
Django открывает курсор на стороне сервера . По умолчанию PostgreSQL предполагает, что будут получены только первые 10% результатов запроса курсора. Планировщик запросов тратит меньше времени на планирование запроса и начинает быстрее возвращать результаты, но он также может снизить производительность, если будет получено более 10% результатов. Предположения PostgreSQL о количестве строк, полученных из запроса курсора, контролируются параметром cursor_tuple_fraction .
Массовые транзакции и серверные курсоры ¶
Использование пула соединений в режиме пула транзакций (например, PgBouncer ) требует отключения серверных курсоров для этого соединения.
Курсоры на стороне сервера зависят от соединения и остаются открытыми в конце транзакции, когда они AUTOCOMMIT
стоят True
. Следующая транзакция может потребовать дополнительных результатов от серверного курсора. В режиме объединения транзакций нет гарантии, что последующие транзакции будут повторно использовать одно и то же соединение. Если используется другое соединение, возникает ошибка, когда транзакция обращается к курсору на стороне сервера, потому что эти типы курсоров доступны только для соединения, в котором они были созданы.
Одно из решений - отключить серверные курсоры для подключения DATABASES
, установив DISABLE_SERVER_SIDE_CURSORS
значение True
.
Чтобы воспользоваться курсорами на стороне сервера в режиме агрегирования транзакций, можно определить другое соединение с базой данных для выполнения запросов с использованием курсоров на стороне сервера. Это соединение должно быть выполнено либо напрямую с базой данных, либо с концентратором соединений в режиме группировки сеансов.
Другой вариант - обернуть каждый QuerySet
из курсоров на стороне сервера в блок atomic()
, так как это отключает режим autocommit
на время транзакции. Таким образом, курсор на стороне сервера будет активен только на время транзакции.
Ручное указание значений первичного ключа с автоинкрементом ¶
Django использует тип данных PostgreSQL SERIAL для хранения первичных ключей автоинкремента. Столбец SERIAL
заполняется значениями в последовательности, которая отслеживает следующее доступное значение. Присвоение значения полю автоинкремента вручную не приводит к обновлению последовательности поля, что в дальнейшем может вызвать конфликт. например
>>> from django.contrib.auth.models import User
>>> User.objects.create(username='alice', pk=1)
<User: alice>
>>> # The sequence hasn't been updated; its next value is 1.
>>> User.objects.create(username='bob')
...
IntegrityError: duplicate key value violates unique constraint
"auth_user_pkey" DETAIL: Key (id)=(1) already exists.
Если вам нужно указать такие значения, сбросьте последовательность, чтобы избежать повторного использования значения, которое уже есть в таблице. Команда администрирования sqlsequencereset
генерирует команды SQL, которые это делают.
Тестовые модели базы данных ¶
Этот параметр может использоваться TEST['TEMPLATE']
для указания шаблона (например 'template0'
), из которого создается тестовая база данных.
Ускорение выполнения теста с помощью временных настроек ¶
Вы можете ускорить выполнение теста, настроив Loss-Accepted PostgreSQL .
Предупреждение
Это опасно: ваша база данных будет более подвержена потере или повреждению данных в случае сбоя сервера или отключения электроэнергии. Используйте это только на машинах для разработки, где вы можете легко восстановить все базы данных в кластере.
Заметки MariaDB ¶
Django поддерживает MariaDB 10.2 и выше.
Чтобы использовать MariaDB, используйте движок MySQL, который является общим для них обоих. См. Примечания к MySQL для получения более подробной информации.
Примечания к MySQL ¶
Поддерживаемые версии ¶
Django поддерживает MySQL версии 5.6 и новее.
Функциональность inspectdb
Django использует базу данных information_schema
, которая содержит подробные данные обо всех схемах в базе данных.
Django ожидает, что база данных примет Unicode (кодировка UTF-8) и делегирует ей ответственность за выполнение транзакций и ссылочную целостность. Важно знать, что эти последние два аспекта фактически не применяются MySQL при использовании механизма хранения MyISAM, см. Следующий раздел.
Механизмы хранения ¶
MySQL имеет несколько механизмов хранения . Вы можете изменить механизм хранения по умолчанию в конфигурации сервера.
Механизм хранения MySQL по умолчанию - InnoDB . Этот механизм полностью транзакционный и поддерживает ссылки на внешние ключи. Это рекомендуемый выбор. Однако счетчик автоматического увеличения InnoDB теряется при перезапуске MySQL, потому что он не сохраняет значение, AUTO_INCREMENT
а пересчитывает его как «max (id) +1». Это может привести к неправильному повторному использованию значений AutoField
.
Основные недостатки MyISAM заключаются в том, что он не поддерживает транзакции и не проверяет ограничения внешнего ключа.
Драйверы MySQL DB API ¶
MySQL предлагает несколько драйверов, которые реализуют API базы данных Python, описанный в PEP 249 :
- mysqlclient - это собственный драйвер. Это рекомендуемый выбор .
- MySQL Connector / Python - это чистый драйвер Python, написанный Oracle, который не требует клиентской библиотеки MySQL или других модулей Python за пределами стандартной библиотеки.
Эти драйверы учитывают конкуренцию между потоками выполнения (потокобезопасность) и управляют группировкой соединений (пул).
Помимо драйвера DB API, Django нужен адаптер для доступа к драйверам базы данных из ORM. Django предоставляет адаптер для mysqlclient, а MySQL Connector / Python включает собственный .
mysqlclient ¶
Django требует mysqlclient 1.4.0 или новее.
Коннектор MySQL / Python ¶
MySQL Connector / Python доступен на этой странице загрузки . Адаптер Django доступен в версиях 1.1.X и новее. Он может не поддерживать последнюю версию Django.
Определения часовых поясов ¶
Если вы планируете использовать поддержку часовых поясов Django, используйте mysql_tzinfo_to_sql для загрузки таблиц часовых поясов в базу данных MySQL. Это нужно сделать только один раз для каждого сервера MySQL, а не для каждой базы данных.
Создание базы данных ¶
Вы можете создать базу данных с помощью инструментов командной строки и этой команды SQL:
CREATE DATABASE <dbname> CHARACTER SET utf8;
Это гарантирует, что все таблицы и столбцы по умолчанию используют кодировку UTF-8.
Параметры сортировки ¶
Метод сортировки («сопоставление») столбца определяет порядок, в котором сортируются данные, а также сравнение строк на равенство. Этот параметр может быть определен на уровне базы данных, а также по таблице и по столбцу. Это полностью задокументировано в документации MySQL. Во всех случаях метод сортировки определяется прямым изменением таблиц базы данных; Django не предоставляет возможности сделать это на уровне определения модели.
По умолчанию в базе данных UTF-8 MySQL использует сопоставление utf8_general_ci
. В результате все сравнения строк на равенство выполняются без учета регистра. То есть «Fred» и «freD» считаются эквивалентными для базы данных. Если вы наложили уникальное ограничение на поле, было бы недопустимо вставлять и «aa», и «AA» в этот же столбец, поскольку их сравнение показывает, что они одинаковы (и, следовательно, не уникальный) с параметрами сортировки по умолчанию. Если вы хотите выполнить сравнение с учетом регистра в конкретном столбце или таблице, измените параметры сортировки для столбца или таблицы на utf8_bin
.
Обратите внимание, что в соответствии с наборами символов MySQL Unicode сравнения с сопоставлением utf8_general_ci
выполняются быстрее, но немного менее корректны, чем сравнения с utf8_unicode_ci
. Если это приемлемо для вашего приложения, лучше использовать, utf8_general_ci
потому что это быстрее. В противном случае (например, если вам нужен порядок словаря немецкого языка) используйте, utf8_unicode_ci
потому что это сопоставление более правильное.
Предупреждение
Подчиненные формы шаблона проверяют уникальные поля с учетом регистра. Таким образом, при использовании сортировки базы данных без учета регистра подформы, содержащие уникальные значения полей, которые отличаются только своим регистром, успешно пройдут проверку, но во время проверки. запись по save()
, произойдет исключение IntegrityError
.
Подключение к базе данных ¶
См. Документацию по настройкам .
Параметры подключения используются в таком порядке:
Другими словами, если вы установите имя базы данных в OPTIONS
, это определение имеет приоритет NAME
, что само по себе будет иметь приоритет над любым значением в файле опций MySQL .
Вот пример конфигурации, в которой используется файл опций MySQL:
# settings.py
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'OPTIONS': {
'read_default_file': '/path/to/my.cnf',
},
}
}
# my.cnf
[client]
database = NAME
user = USER
password = PASSWORD
default-character-set = utf8
Могут быть полезны некоторые другие параметры подключения MySQLdb , например ssl
, init_command
или sql_mode
.
Определение sql_mode
¶
Начиная с MySQL 5.7 и для новых установок MySQL 5.6 значение параметра по умолчанию sql_mode
содержит STRICT_TRANS_TABLES
. Эта опция превращает предупреждения в ошибки, когда данные усекаются во время вставки. Django настоятельно рекомендует включить строгий режим для MySQL, чтобы избежать потери данных ( STRICT_TRANS_TABLES
или STRICT_ALL_TABLES
).
ЕСЛИ вам нужно настроить режим SQL, vuos может установить эту переменную, sql_mode
как и любой другой параметр MySQL: либо в файле конфигурации, либо с помощью строки в части конфигурации базы данных в .'init_command': "SET sql_mode='STRICT_TRANS_TABLES'"
OPTIONS
DATABASES
Уровень изоляции ¶
При работе с конкурентной нагрузкой транзакции базы данных из разных сеансов (например, отдельные потоки, обрабатывающие разные запросы) могут взаимодействовать друг с другом. На эти взаимодействия влияет уровень изоляции транзакции каждого сеанса. Можно установить уровень изоляции транзакции соединения с ключом 'isolation_level'
части OPTIONS
конфигурации базы данных в DATABASES
. Допустимые значения для этого ключа - четыре стандартных уровня изоляции:
'read uncommitted'
'read committed'
'repeatable read'
'serializable'
или None
использовать уровень изоляции, настроенный на сервере. Однако Django лучше работает с (выбор Django по умолчанию), чем с MySQL по умолчанию . Возможна потеря данных с уровнем . В частности, вы можете столкнуться со случаями, когда возникает исключение, но объект не появляется в будущих вызовах .read committed
repeatable read
repeatable read
get_or_create()
IntegrityError
get()
Создание таблиц ¶
Когда Django генерирует схему, он не указывает механизм хранения, поэтому таблицы будут созданы с механизмом хранения по умолчанию для вашего сервера базы данных. Самое простое решение - установить желаемый механизм в качестве механизма хранения по умолчанию для вашего сервера базы данных.
Если вы пользуетесь услугами хостинга и не можете изменить механизм хранения по умолчанию на своем сервере, у вас есть несколько вариантов.
После создания таблиц запустите команду SQL, чтобы преобразовать таблицу в новый механизм хранения (например, InnoDB):
ALTER TABLE
ALTER TABLE <tablename> ENGINE=INNODB;
Это может быть утомительно, если у вас много таблиц.
Другая возможность - использовать опцию
init_command
MySQLdb перед созданием таблиц:'OPTIONS': { 'init_command': 'SET default_storage_engine=INNODB', }
Это устанавливает механизм хранения по умолчанию при подключении к базе данных. После создания таблиц вы должны удалить этот параметр, поскольку он добавляет запрос при каждом подключении к базе данных, что необходимо только при создании таблицы.
Имена таблиц ¶
Некоторые известные проблемы , даже в последних версиях MySQL, могут вызывать изменение имени таблицы, когда определенные операторы SQL выполняются при определенных условиях. Рекомендуется по возможности использовать имена таблиц в нижнем регистре, чтобы избежать проблем, которые могут возникнуть в результате такого поведения. Django использует имена таблиц в нижнем регистре, когда автоматически генерирует имена таблиц из моделей, поэтому это нужно учитывать, особенно если вы переопределяете имя таблицы с помощью параметра db_table
.
Точки сохранения ¶
И ORM Django, и MySQL (когда используется механизм хранения InnoDB) поддерживают точки сохранения базы данных.
Если вы используете механизм хранения MyISAM, вы получите ошибки, созданные базой данных, если попытаетесь использовать методы API транзакций точки сохранения . В самом деле, поскольку обнаружение механизма хранения таблицы или базы данных MySQL является очень затратной операцией в ресурсах, было решено не преобразовывать эти методы динамически в нейтральные методы, основанные на этом виде. обнаружение.
Примечания по отдельным полям ¶
Поля символов ¶
Любые поля, которые хранятся с VARCHAR
типами столбцов, могут иметь
max_length
ограничение до 255 символов, если вы используете unique=True
это поле. Это касается CharField
,
SlugField
. См. Дополнительную информацию в документации MySQL .
Пределы поля ¶
MySQL может индексировать только первые N символов столбца BLOB
или TEXT
. Поскольку у TextField
него нет определенной длины, пометить такое поле значком невозможно unique=True
. MySQL выдаст ошибку: «Столбец BLOB / TEXT« <db_column> »используется в спецификации ключа без длины ключа».
Поддержка дробных секунд для времени и полей даты / времени ¶
Начиная с версии 5.6.4, MySQL может хранить доли секунды, если определения столбцов содержат соответствующее указание (например, DATETIME(6)
). В предыдущих версиях это вообще не поддерживалось.
Сам Django не будет обновлять существующие столбцы, чтобы включать доли секунд, если сервер базы данных поддерживает это. Если вы хотите активировать их в существующей базе данных, вам нужно вручную обновить столбец в базе данных, выполнив такую команду, как:
ALTER TABLE `your_table` MODIFY `your_datetime_column` DATETIME(6)
или с помощью операции RunSQL
в миграции данных .
Столбцы TIMESTAMP
¶
Если вы используете существующую базу данных, содержащую столбцы TIMESTAMP
, вы должны установить ее, чтобы избежать повреждения данных. сопоставляет эти столбцы с полями, и если вы включите поддержку часового пояса, MySQL и Django попытаются преобразовать значения из UTC в местное время.USE_TZ = False
inspectdb
DateTimeField
Блокировка ряда с помощью QuerySet.select_for_update()
¶
MySQL и MariaDB не поддерживают некоторые параметры оператора . Если используется с неподдерживаемым параметром, создается исключение .SELECT ... FOR UPDATE
select_for_update()
NotSupportedError
вариант | MariaDB | MySQL |
---|---|---|
SKIP LOCKED |
Х (≥8.0.1) | |
NOWAIT |
Х (≥10,3) | Х (≥8.0.1) |
OF |
При использовании select_for_update()
с MySQL обязательно отфильтруйте запрос по крайней мере с одним полем, содержащимся в ограничениях уникальности, или только с полями, имеющими индексы. В противном случае будет получена исключительная блокировка записи для всей таблицы в течение всей транзакции.
Автоматический повторный ввод может привести к неожиданным результатам ¶
При выполнении запроса к строковому типу, но с целочисленным значением, MySQL переводит типы всех значений в таблицу в целые числа перед выполнением сравнения. Если таблица содержит значение 'abc'
, 'def'
и поиски запроса , два ряда будет совпадать. Таким же образом соответствует значение . Вот почему поля строкового типа, включенные в Django, всегда приводят значение к строке, прежде чем использовать ее в запросе.WHERE macolonne=0
WHERE macolonne=1
'abc1'
Если вы реализуете пользовательские модели поля , которые наследуют непосредственно из Field
, переопределения get_prep_value()
или использования RawSQL
, extra()
или raw()
, вы должны убедиться , что вы выполняете соответствующие подкрепления типа.
Примечания к SQLite ¶
Django поддерживает SQLite версии 3.8.3 и новее.
SQLite представляет собой отличную альтернативу для разработки приложений, которые в основном предназначены только для чтения или требуют установки меньшего размера. Однако, как и в случае со всеми серверами баз данных, есть несколько специфических отличий SQLite, о которых следует помнить.
Поиск частей строк и чувствительности к регистру ¶
Для всех версий SQLite наблюдается неинтуитивное поведение при попытке сопоставить определенные типы строк. Это поведение срабатывает при использовании фильтров iexact
или contains
в QuerySets. Поведение делится на два случая:
1. Для сопоставления подстрок все совпадения выполняются без учета регистра. Это фильтр, который filter(name__contains="aa")
будет соответствовать имени "Aabb"
.
2. Для строк, содержащих символы вне диапазона ASCII, все точные совпадения строк выполняются с учетом регистра, даже если в запрос передаются параметры без учета регистра. Таким образом, в этих случаях iexact
фильтр будет вести себя точно так же, как и exact
фильтр.
На sqlite.org есть несколько обходных путей , но они не используются механизмом SQLite по умолчанию Django, так как это потребовало бы определенных трудностей для надежной работы. Таким образом, Django демонстрирует поведение SQLite по умолчанию, и вы должны знать об этом при фильтрации подстрок или строк без учета регистра.
Обработка десятичных знаков ¶
SQLite не имеет внутреннего типа десятичного числа. Десятичные значения преобразуются в тип данных REAL
(8-байтовое число с плавающей запятой IEEE), как показано в документации по типам данных SQLite , поэтому арифметические операции с десятичными числами с плавающей запятой не выполняются. обработано правильно (проблемы с округлением).
Ошибки «База данных заблокирована» ¶
Предполагается, что SQLite является легкой базой данных и поэтому не может обрабатывать высокий уровень параллелизма. Ошибки указывают на то, что приложение испытывает более высокую конкуренцию, чем может обрабатывать его конфигурация по умолчанию. Эта ошибка означает, что процесс или поток имеют монопольную блокировку соединения с базой данных, а другому потоку пришлось слишком долго ждать снятия блокировки.OperationalError: database is locked
sqlite
Адаптер Python SQLite имеет значение тайм-аута по умолчанию, которое определяет максимальное время ожидания разблокировки другого потока до истечения времени ожидания с ошибкой .OperationalError: database is locked
Если вы получили эту ошибку, вы можете решить проблему следующим образом:
Переход на другой движок базы данных. В какой-то момент SQLite действительно становится слишком легким для реальных приложений, и такая ошибка параллелизма указывает на то, что точка была достигнута.
Переписать код, чтобы уменьшить параллелизм и сделать транзакции базы данных как можно короче.
Увеличьте значение срока действия по умолчанию, установив параметр базы данных
timeout
:'OPTIONS': { # ... 'timeout': 20, # ... }
Это заставит SQLite ждать немного дольше, прежде чем возникнет ошибка «база данных заблокирована»; но поэтому основная проблема не решена.
QuerySet.select_for_update()
не поддерживается ¶
SQLite не поддерживает синтаксис . Вызов этого метода ни на что не влияет.SELECT ... FOR UPDATE
Стиль параметра "pyformat" в необработанных запросах не поддерживается ¶
Для большинства движков необработанные ( Manager.raw()
или cursor.execute()
) запросы могут использовать стиль параметра "pyformat", где заполнители в запросе записываются как, '%(nom)s'
а параметры передаются как словарь, а не список. SQLite не поддерживает этот синтаксис.
Изоляция при использовании QuerySet.iterator()
¶
В разделе «Изоляция в SQLite» описаны особые ситуации при изменении таблицы при ее просмотре с помощью QuerySet.iterator()
. Если строка добавляется, изменяется или уничтожается в цикле, эта строка может появляться или не появляться, или даже появляться дважды в последующих результатах от итератора. Ваш код должен справиться с этим.
Включение расширения JSON1 на SQLite ¶
Для использования JSONField
в SQLite вам необходимо включить
расширение JSON1 в sqlite3
библиотеке Python . Если расширение не включено в вашей установке, появится системная ошибка ( fields.E180
).
Чтобы включить расширение JSON1, следуйте инструкциям на вики-странице .
Примечания к Oracle ¶
Django поддерживает версии 12.2 и новее сервера баз данных Oracle . Требуется версия драйвера cx_Oracle Python не ниже 6.0 .
Чтобы команда работала, пользователь базы данных Oracle должен иметь права на выполнение следующих команд:python manage.py migrate
- СОЗДАТЬ ТАБЛИЦУ
- СОЗДАТЬ ПОСЛЕДОВАТЕЛЬНОСТЬ
- СОЗДАТЬ ПРОЦЕДУРУ
- СОЗДАТЬ ТРИГГЕР
Для запуска набора тестов проекта пользователю обычно требуются следующие дополнительные права :
- СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ
- ИЗМЕНИТЬ ПОЛЬЗОВАТЕЛЯ
- УДАЛИТЬ ПОЛЬЗОВАТЕЛЯ
- СОЗДАТЬ ТАБЛИЧНОЕ ПРОСТРАНСТВО
- DROP TABLESPACE
- СОЗДАТЬ СЕССИЮ С ОПЦИЕЙ АДМИНИСТРАТОРА
- СОЗДАТЬ ТАБЛИЦУ С ОПЦИЕЙ АДМИНИСТРАТОРА
- СОЗДАТЬ ПОСЛЕДОВАТЕЛЬНОСТЬ С ОПЦИЕЙ АДМИНИСТРАТОРА
- СОЗДАТЬ ПРОЦЕДУРУ С ОПЦИЕЙ АДМИНИСТРАТОРА
- СОЗДАТЬ ТРИГГЕР С ОПЦИЕЙ АДМИНИСТРАТОРА
Хотя роль RESOURCE
имеет необходимые привилегии , , и , и пользователь с может предоставить привилегию , что пользователь не может предоставить индивидуальные привилегии (например. ), Так что , как правило , не достаточно запустить тесты.CREATE TABLE
CREATE SEQUENCE
CREATE PROCEDURE
CREATE TRIGGER
RESOURCE WITH ADMIN OPTION
RESOURCE
CREATE TABLE
RESOURCE WITH ADMIN OPTION
Некоторые наборы тестов также создают представления или материализованные представления; для выполнения этого, пользователь также нуждается и привилегии . Это особенно необходимо для собственного набора тестов Django.CREATE VIEW WITH ADMIN OPTION
CREATE MATERIALIZED VIEW WITH ADMIN OPTION
Все эти привилегии включены в роль администратора базы данных, что подходит для частной базы данных разработки.
Oracle Database Engine использует пакеты SYS.DBMS_LOB
и SYS.DBMS_RANDOM
, таким образом, пользователь должен иметь права на выполнение для него. Обычно он доступен по умолчанию для всех пользователей, но если это не так, вы должны назначить такие разрешения:
GRANT EXECUTE ON SYS.DBMS_LOB TO user;
GRANT EXECUTE ON SYS.DBMS_RANDOM TO user;
Подключение к базе данных ¶
Чтобы подключиться с использованием имени службы базы данных Oracle, файл settings.py
должен выглядеть примерно так:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.oracle',
'NAME': 'xe',
'USER': 'a_user',
'PASSWORD': 'a_password',
'HOST': '',
'PORT': '',
}
}
В этом случае, вы должны оставить два ключа HOST
и опорожнить PORT
. Однако, если вы не используете файл tnsnames.ora
или аналогичный метод именования и хотите подключиться с использованием SID («xe» в этом примере), заполните оба HOST
и PORT
, например:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.oracle',
'NAME': 'xe',
'USER': 'a_user',
'PASSWORD': 'a_password',
'HOST': 'dbprod01ned.mycompany.com',
'PORT': '1540',
}
}
Либо заполните оба ключа, HOST
но PORT
оставьте оба пустыми. Django использует другой дескриптор подключения в зависимости от этого выбора.
Полный DSN и Easy Connect ¶
Можно использовать полную цепочку DSN или Easy Connect, NAME
если оба HOST
и PORT
пустые. Этот формат необходим, например, при использовании RAC или подключаемых баз данных без tnsnames.ora
.
Пример канала Easy Connect
'NAME': 'localhost:1521/orclpdb1',
Пример полной цепочки DSN
'NAME': (
'(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))'
'(CONNECT_DATA=(SERVICE_NAME=orclpdb1)))'
),
Вариант с резьбой ¶
Если вы планируете запускать Django в многопоточной (многопоточной) среде, например, с Apache и модулем MPM по умолчанию в любой современной операционной системе), вам следует установить свой True
параметр threaded
конфигурации База данных Oracle:
'OPTIONS': {
'threaded': True,
},
Если вы этого не сделаете, вы рискуете получить посадку и другое странное поведение.
ВСТАВИТЬ… ВОЗВРАЩЕНИЕ В ¶
По умолчанию механизм Oracle использует предложение для эффективного получения значения поля при вставке новых строк. Такое поведение может привести к ошибкам в некоторых конкретных конфигурациях, например, при вставке в удаленную таблицу или в представление с триггером . Предложение можно отключить, установив для параметра конфигурации базы данных значение :RETURNING INTO
AutoField
DatabaseError
INSTEAD OF
RETURNING INTO
use_returning_into
False
'OPTIONS': {
'use_returning_into': False,
},
В этом случае механизм Oracle использует SELECT
отдельный запрос для получения значений AutoField
.
Вопросы по именованию ¶
Oracle устанавливает ограничение на длину имен в 30 символов. Чтобы соответствовать этому, механизм усекает идентификаторы базы данных по мере необходимости, заменяя последние четыре символа усеченного имени воспроизводимым значением хеш-функции MD5. Вдобавок движок преобразует все идентификаторы базы данных в верхний регистр.
Чтобы предотвратить эти преобразования (которые обычно необходимы только при работе с существующими базами данных или когда вам нужен доступ к таблицам, принадлежащим другим пользователям), заключите значение в db_table
кавычки:
class LegacyModel(models.Model):
class Meta:
db_table = '"name_left_in_lowercase"'
class ForeignModel(models.Model):
class Meta:
db_table = '"OTHER_USER"."NAME_ONLY_SEEMS_OVER_30"'
Имена в кавычках также могут использоваться с другими механизмами баз данных, поддерживаемыми Django; но эти цитаты действуют только на Oracle.
При запуске может возникнуть migrate
ошибка, ORA-06552
если определенные ключевые слова Oracle используются в качестве имен полей модели или в качестве значения параметра db_column
. Django заключает все идентификаторы, используемые в запросах, в кавычки, чтобы предотвратить большинство подобных проблем, но эта ошибка все равно может возникать, когда в качестве имени столбца используется тип данных Oracle. В частности, стараются избегать использования имен date
, timestamp
, number
или float
как имена полей.
NULL и пустые строки ¶
Django обычно предпочитает использовать пустую строку ( ''
) NULL
, но Oracle рассматривает эти два значения как одно и то же. Чтобы обойти это, механизм Oracle игнорирует явную опцию null
для полей, где пустая строка является возможным значением, и генерирует операторы SQL как если бы null=True
. При чтении из базы данных Django предполагает, что значение NULL
в одном из этих полей на самом деле является пустой строкой, и данные автоматически преобразуются в соответствии с этим принципом.
Пределы поля ¶
Механизм Oracle хранит поля TextFields
в столбцах NCLOB
. Oracle накладывает некоторые ограничения на использование таких столбцов LOB в целом:
- Столбцы больших объектов нельзя использовать в качестве первичных ключей.
- Столбцы больших объектов нельзя использовать в индексах.
- Столбцы больших объектов нельзя использовать в списке . Это означает, что попытка использовать метод для модели, содержащей столбцы, приведет к ошибке вместе с предотвращением включения столбцов в список .
SELECT DISTINCT
QuerySet.distinct
TextField
ORA-00932``avec Oracle. Pour contourner ce problème, utilisez la méthode ``QuerySet.defer
distinct()
TextField
SELECT DISTINCT
Создание подкласса интегрированного движка базы данных ¶
Django поставляется со встроенными механизмами баз данных. Можно создавать подклассы для изменения их поведения, функциональности или конфигурации.
Представьте, например, что вам нужно изменить одну функцию базы данных. Во-первых, нужно создать новый каталог, содержащий модуль base
. например
mysite/
...
mydbengine/
__init__.py
base.py
Модуль base.py
должен содержать именованный класс DatabaseWrapper
, наследующий существующий механизм от модуля django.db.backends
. Вот пример подкласса движка PostgreSQL с целью изменения функциональности класса allows_group_by_selected_pks_on_model
:
from django.db.backends.postgresql import base, features
class DatabaseFeatures(features.DatabaseFeatures):
def allows_group_by_selected_pks_on_model(self, model):
return True
class DatabaseWrapper(base.DatabaseWrapper):
features_class = DatabaseFeatures
Наконец, вы должны указать значение DATABASE-ENGINE
в вашем файле settings.py
:
DATABASES = {
'default': {
'ENGINE': 'mydbengine',
...
},
}
Вы можете увидеть текущий список движков баз данных, просмотрев каталог django / db / backends .
Использование внешнего механизма базы данных ¶
Помимо официально поддерживаемых баз данных, существуют внешние по отношению к Django механизмы, которые позволяют использовать другие базы данных с Django:
Версии Django и функций ORM, поддерживаемые этими неофициальными движками, сильно различаются. Если у вас есть какие-либо вопросы относительно конкретных возможностей этих неофициальных движков или вопросы поддержки, вам следует обратиться по каналам помощи, предлагаемым каждым из этих внешних проектов.