django-admin
и manage.py
¶
django-admin
это утилита командной строки Django для административных задач. В этом документе представлено все, на что он способен.
Кроме того, manage.py
он создается автоматически в каждом проекте Django. Он делает то же самое, django-admin
но также устанавливает переменную средыDJANGO_SETTINGS_MODULE
чтобы указать его на файл settings.py
проекта.
django-admin
Сценарий должен быть в вашем системном пути , если вы установили Django с помощью pip
. Если это не на вашем пути, убедитесь, что ваша виртуальная среда активирована.
Как правило, работа с одним проектом Django упрощает его использование, manage.py
а не django-admin
. Если вам нужно переключаться между разными файлами настроек Django, используйте переменнуюDJANGO_SETTINGS_MODULE
или параметр командной строки --settings
команды django-admin
.
Примеры командной строки в этом документе используются django-admin
для единообразия, но во всех примерах так же легко можно использовать manage.py
или .python -m django
Использование ¶
$ django-admin <command> [options]
$ manage.py <command> [options]
$ python -m django <command> [options]
...\> django-admin <command> [options]
...\> manage.py <command> [options]
...\> py -m django <command> [options]
command
должен соответствовать одной из команд, упомянутых в этом документе. options
, который является необязательным, должен соответствовать нулю или более параметрам, доступным для затронутой команды.
Получение помощи ¶
-
django-admin help
¶
Запустите, чтобы просмотреть информацию об использовании и список команд, предоставляемых каждым приложением.django-admin help
Запустить, чтобы отобразить список доступных команд.django-admin help --commands
Запустить, чтобы отобразить описание затронутой команды и список ее доступных параметров.django-admin help <command>
Имена приложений ¶
Некоторые команды принимают список «имен приложений». Имя приложения - это базовое имя пакета, содержащего модели. Например, если ваш параметр INSTALLED_APPS
содержит строку 'mysite.blog'
, имя приложения будет blog
.
Определение версии ¶
-
django-admin version
¶
Запустите, чтобы просмотреть текущую версию Django.django-admin version
Дисплей соответствует схеме, описанной в PEP 440 :
1.4.dev17026
1.4a1
1.4
Отображение отладочного содержимого ¶
Используется --verbosity
для указания количества ориентировочной и отладочной информации, django-admin
отображаемой в консоли.
Доступные команды ¶
check
¶
-
django-admin check [app_label [app_label ...]]
¶
Использует инфраструктуру системного мониторинга для проверки всего проекта Django на предмет общих проблем.
По умолчанию отслеживаются все приложения. Вы можете проверить подмножество приложений, предоставив список меток приложений в качестве параметров:
django-admin check auth admin myapp
Если вы не укажете какое-либо приложение, будут проверены все приложения.
-
--tag
TAGS
,
-t
TAGS
¶
Инфраструктура управления системой выполняет множество типов элементов управления, которые классифицируются по ярлыкам . Это позволяет ограничить выполняемые проверки проверками определенной категории. Например, чтобы выполнить только проверки модели и совместимости, запустите:
django-admin check --tag models --tag compatibility
-
--database
DATABASE
¶
Указывает базу данных для запуска проверок, требующих доступа к базе данных:
django-admin check --database default --database other
По умолчанию эти проверки не запускаются.
Отображает список всех доступных меток.
-
--deploy
¶
Включает некоторые дополнительные элементы управления, действительные только для параметров развертывания.
Вы можете использовать эту опцию в своей локальной среде разработки, но поскольку ваш локальный модуль настроек разработки может не иметь многих из ваших производственных настроек, вы, вероятно, захотите указать check
команду в другом модуле настроек, либо установив параметрDJANGO_SETTINGS_MODULE
переменная окружения, или передав --settings
параметр:
django-admin check --deploy --settings=production_settings
Или вы можете запустить его непосредственно в производственной или подготовительной системе, чтобы убедиться, что установлены правильные настройки (пропуская --settings
). Команду даже можно интегрировать в ваш набор интеграционных тестов.
-
--fail-level
{CRITICAL,ERROR,WARNING,INFO,DEBUG}
¶
Устанавливает уровень сообщения, при котором выводится команда с ненулевым кодом состояния. По умолчанию это ERROR
.
compilemessages
¶
-
django-admin compilemessages
¶
Компилирует файлы, .po
созданные с помощью, makemessages
в файлы, которые .mo
может использовать встроенный инструмент gettext
. См. Интернационализация и регионализация .
-
--locale
LOCALE
,
-l
LOCALE
¶
Указывает язык или языки для обработки. Без информации обрабатываются все языки.
-
--exclude
EXCLUDE
,
-x
EXCLUDE
¶
Указывает языки, которые следует исключить из обработки заказа. Без дополнительной информации ни один язык не исключен.
-
--use-fuzzy
,
-f
¶
Включите приблизительные («нечеткие») переводы в скомпилированные файлы.
Пример использования:
django-admin compilemessages --locale=pt_BR
django-admin compilemessages --locale=pt_BR --locale=fr -f
django-admin compilemessages -l pt_BR
django-admin compilemessages -l pt_BR -l fr --use-fuzzy
django-admin compilemessages --exclude=pt_BR
django-admin compilemessages --exclude=pt_BR --exclude=fr
django-admin compilemessages -x pt_BR
django-admin compilemessages -x pt_BR -x fr
-
--ignore
PATTERN
,
-i
PATTERN
¶
Игнорировать каталоги, соответствующие шаблону glob
данного типа . Опция может быть указана более одного раза по разным причинам.
Пример использования:
django-admin compilemessages --ignore=cache --ignore=outdated/*/locale
createcachetable
¶
-
django-admin createcachetable
¶
Создает таблицы кэша для использования механизмом кеширования базы данных с использованием информации из файла настроек. Дополнительную информацию см. В разделе Инфраструктура кеширования в Django .
-
--database
DATABASE
¶
Задает базу данных, в которой будет создана таблица кэша. По умолчанию это default
.
-
--dry-run
¶
Отображает код SQL, который будет выполняться без фактического выполнения, так что вы можете настроить его или использовать систему миграции.
dbshell
¶
-
django-admin dbshell
¶
Запускает соответствующую команду онлайн-клиента для механизма базы данных, указанного в настройках ENGINE
, с учетом настроек подключения, определенных в настройках USER
, PASSWORD
и т. Д.
- Для PostgreSQL эта команда запускает клиент командной строки
psql
. - Для MySQL эта команда запускает клиент командной строки
mysql
. - Для SQLite эта команда запускает клиент командной строки
sqlite3
. - Для Oracle эта команда запускает клиент командной строки
sqlplus
.
Эта команда опирается на тот факт , что программы доступны на пути выполнения , так что, называя свое имя ( psql
, mysql
, sqlite3
, sqlplus
), правильная программа запущена. Нет никакого трюка, чтобы вручную указать путь к программе базы данных.
-
--database
DATABASE
¶
Задает базу данных, для которой следует открыть оболочку. По умолчанию это 'default'
.
-
--
ARGUMENTS
¶
Любые аргументы, следующие за --
разделителем, будут переданы базовому клиенту командной строки. Например, с PostgreSQL вы можете использовать psql
командование -c
флаг для выполнения необработанного запроса SQL непосредственно:
$ django-admin dbshell -- -c 'select current_user'
current_user
--------------
postgres
(1 row)
...\> django-admin dbshell -- -c 'select current_user'
current_user
--------------
postgres
(1 row)
На MySQL / MariaDB, вы можете сделать это с помощью mysql
командования -e
флага:
$ django-admin dbshell -- -e "select user()"
+----------------------+
| user() |
+----------------------+
| [email protected] |
+----------------------+
...\> django-admin dbshell -- -e "select user()"
+----------------------+
| user() |
+----------------------+
| [email protected] |
+----------------------+
diffsettings
¶
-
django-admin diffsettings
¶
Отображает различия между текущим файлом настроек и настройками по умолчанию Django (или другим файлом настроек, обозначенным --default
).
За настройками, которых нет в настройках по умолчанию, следует "###"
. Например, настройки по умолчанию не установлен ROOT_URLCONF
, поэтому ROOT_URLCONF
следует "###"
на дисплее , как производится diffsettings
.
-
--all
¶
Показать все настройки, даже если они содержат настройки Django по умолчанию. Затем эти настройки имеют префикс "###"
.
-
--default
MODULE
¶
Модуль настроек, с которым сравниваются текущие настройки. Оставьте поле пустым, чтобы сравнить с настройками Django по умолчанию.
-
--output
{hash,unified}
¶
Определяет выходной формат. Доступные значения: hash
и unified
. hash
- это режим по умолчанию, который дает результат, описанный выше. unified
отображает результат, похожий на . Настройки по умолчанию имеют префикс со знаком минус, за которым следует измененный параметр с префиксом плюс.diff -u
dumpdata
¶
-
django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName] ...]]
¶
Отображает все данные в базе данных, связанные с указанными приложениями, на стандартный вывод.
Если имя приложения не указано, отображается содержимое всех установленных приложений.
Выходные данные dumpdata
можно использовать в качестве источника входных данных для loaddata
.
Обратите внимание, что dumpdata
менеджер шаблонов по умолчанию использует при выборе записей для отображения. Если вы настроили настраиваемый обработчик в качестве обработчика по умолчанию, и он исключает некоторые из существующих записей, то вы не получите все объекты в представлении.
-
--all
,
-a
¶
Использует базовый менеджер Django, показывая таким образом записи, которые не будут видны или будут изменены из-за специального менеджера.
-
--format
FORMAT
¶
Задает формат сериализации результата. По умолчанию это JSON. Поддерживаемые форматы перечислены в разделе «Форматы сериализации» .
-
--indent
INDENT
¶
Задает количество пробелов для отступов, используемых для результата. По умолчанию его нет, поэтому все данные отображаются в одной строке.
-
--exclude
EXCLUDE
,
-e
EXCLUDE
¶
Запрещает étiquette_app.NomModèle
отображение определенных приложений или моделей (обозначенных как ). Если вы укажете название модели, отображение продукта будет ограничено этой моделью, а не всем приложением. Также возможно смешивать названия приложений и названия моделей.
Чтобы исключить несколько приложений, укажите несколько раз --exclude
:
django-admin dumpdata --exclude=auth --exclude=contenttypes
-
--database
DATABASE
¶
Задает базу данных, из которой будут производиться данные. По умолчанию это 'default'
.
-
--natural-foreign
¶
Использует шаблонный метод natural_key()
для сериализации любых внешних отношений или отношений «многие ко многим» с объектами типа, определяемого методом. Если вы экспортируете объекты Permission
из contrib.auth
или объекты ContentType
из contrib.contenttypes
, рекомендуется использовать эту опцию. См. Документацию по естественному ключу для получения более подробной информации об этой и следующей опциях.
-
--natural-primary
¶
Опускает первичный ключ из сериализованных данных этого объекта, поскольку он может быть вычислен во время десериализации.
-
--pks
PRIMARY_KEYS
¶
Отображает только объекты, обозначенные списком первичных ключей, разделенных запятыми. Эта опция действительна только в том случае, если экспорт касается одной модели. По умолчанию все записи модели экспортируются.
-
--output
OUTPUT
,
-o
OUTPUT
¶
Задает файл, в который должны быть записаны сериализованные данные. По умолчанию данные отображаются в стандартном выводе.
Если этот параметр установлен и --verbosity
больше 0 (по умолчанию), в терминале отображается индикатор выполнения.
flush
¶
-
django-admin flush
¶
Удаляет все данные из базы данных и повторно запускает любой пост-синхронизирующий менеджер. Таблица, содержащая информацию о приложении миграции, не очищается.
Если вы предпочитаете начать с пустой базы данных и воспроизвести все миграции, рекомендуется удалить и воссоздать базу данных, а затем запустить migrate
.
-
--noinput
,
--no-input
¶
Избегайте каких-либо интерактивных запросов к пользователю.
-
--database
DATABASE
¶
Указывает базу данных для сброса. По умолчанию это default
.
inspectdb
¶
-
django-admin inspectdb [table [table ...]]
¶
Просмотрите таблицы базы данных для базы данных, названной в настройке, NAME
и models.py
выведите модуль модели Django (файл ) на стандартный вывод.
Вы можете выбрать, какие таблицы или представления проверять, передав их имя в качестве параметра. Если параметры не указаны, шаблоны для представлений создаются, только если --include-views
указана опция . Шаблоны для таблиц разделов создаются с помощью PostgreSQL, если --include-partitions
указана опция .
Эта команда полезна в случае существующей базы данных, которую вы хотите использовать с Django. Сценарий проверяет базу данных и создает модель для каждой из ее таблиц.
Как и следовало ожидать, созданные модели имеют атрибут для каждого поля таблицы. Обратите внимание, что в inspectdb
некоторых особых случаях обрабатываются имена полей:
- Если
inspectdb
не удается сопоставить тип столбца с типом поля модели, он используетTextField
и добавляет комментарий (этот тип поля является приблизительным) рядом с определением поля в сгенерированной модели. Распознаваемые поля могут зависеть от приложений, перечисленных в . Например, добавляет распознавание нескольких типов полей, специфичных для PostgreSQL.'This field type is a guess.'
INSTALLED_APPS
django.contrib.postgres
- Если имя столбца базы данных является зарезервированным словом Python (например
'pass'
,'class'
или'for'
),inspectdb
добавьте его'_field'
к имени атрибута. Например, если в таблице есть столбец «для» , атрибут которого будет иметь значение . добавляет комментарий Python (переименованное поле, потому что это зарезервированное слово Python) после поля., le modèle généré contiendra un champ ``'for_field'
db_column
'for'
inspectdb
'Field renamed because it was a Python reserved word.'
Эту функциональность следует понимать как ярлык, а не как окончательную генерацию модели. После выполнения команды необходимо самостоятельно доработать сгенерированные модели для внесения необходимых корректировок. В частности, обычно полезно изменить порядок моделей, чтобы модели, относящиеся к другим моделям, отображались в правильном порядке.
Django не создает значение по умолчанию в базе данных, когда параметр default
определен для поля модели. И наоборот, значения по умолчанию для базы данных не преобразуются в значения по умолчанию для полей шаблона и не обнаруживаются каким-либо другим способом с помощью
По умолчанию inspectdb
создает беспилотные модели. То есть наличие в классе моделей указывает Django не контролировать создание соответствующей таблицы, ее модификацию или уничтожение. Если вы хотите разрешить Django управлять жизненным циклом таблиц, вам нужно изменить параметр, чтобы присвоить ему значение (или вообще удалить его, потому что он используется по умолчанию).managed = False
Meta
managed
True
True
Примечания, относящиеся к определенным базам данных ¶
Оракул ¶
- Шаблоны создаются для материализованных представлений, если
--include-views
указана опция .
PostgreSQL ¶
- Шаблоны созданы для сторонних таблиц.
- Шаблоны создаются для материализованных представлений, если
--include-views
указана опция . - Шаблоны создаются для таблиц разделов, если
--include-partitions
указана опция .
-
--database
DATABASE
¶
Указывает базу данных для проверки. По умолчанию это default
.
-
--include-partitions
¶
Если этот параметр присутствует, модели также создаются для перегородок.
Реализована только поддержка PostgreSQL.
-
--include-views
¶
Если этот параметр присутствует, модели также создаются для представлений базы данных.
loaddata
¶
-
django-admin loaddata fixture [fixture ...]
¶
Находит и загружает содержимое указанного снимка в базу данных.
-
--database
DATABASE
¶
Задает базу данных, в которую будут загружены данные. По умолчанию это default
.
-
--ignorenonexistent
,
-i
¶
Игнорирует поля и шаблоны, которые могли быть удалены с момента создания моментального снимка.
-
--app
APP_LABEL
¶
Назначает одно приложение для поиска снимков вместо поиска по всем приложениям.
-
--format
FORMAT
¶
Задает формат сериализации (например, json
или xml
) для снимков, считываемых из стандартного ввода stdin .
-
--exclude
EXCLUDE
,
-e
EXCLUDE
¶
Исключает загрузку снимков указанных приложений и моделей (в форме étiquette_app
или app_label.ModelName). Параметр можно указать несколько раз, чтобы исключить более одного приложения или модели.
Что такое «снимок» (приспособление на английском языке)? ¶
Снимок представляет собой набор файлов, содержащие сериализованное содержимое базы данных. Каждый снимок имеет уникальное имя, и файлы, составляющие снимок, могут быть распределены по нескольким каталогам и нескольким приложениям.
Django ищет снимки в трех местах:
- В каталоге
fixtures
каждого установленного приложения - В любом каталоге, указанном в настройке
FIXTURE_DIRS
- В пути, явно содержащемся в имени снимка
Django загружает любые найденные в этих местах снимки, соответствующие указанным именам снимков.
Если имя снимка имеет расширение файла, будут загружены только снимки этого типа. Например :
django-admin loaddata mydata.json
загружает только именованные снимки JSON mydata
. Расширение моментального снимка должно соответствовать зарегистрированному имени сериализатора (например, json
или xml
).
Если вы опустите расширение, Django будет искать все доступные типы снимков для каждого найденного снимка. Например :
django-admin loaddata mydata
находит любой снимок или именованный тип снимка mydata
. Если каталог моментальных снимков содержит mydata.json
, этот моментальный снимок будет загружен как моментальный снимок JSON.
Имена снимков могут содержать часть «пути». Эти каталоги затем включаются в путь поиска. Например :
django-admin loaddata foo/bar/mydata.json
поиск <étiquette_app>/fixtures/foo/bar/mydata.json
каждого установленного приложения, <nom_rép>/foo/bar/mydata.json
каждого каталога в, а FIXTURE_DIRS
также буквального пути foo/bar/mydata.json
.
При обработке файлов моментальных снимков данные сохраняются в базе данных. Методы, save()
определенные в моделях, не вызываются и никакие сигналы pre_save
или post_save
вызываются с помощью, raw=True
потому что экземпляр содержит только локальные атрибуты модели. Например, можно деактивировать менеджеров, обращающихся к отсутствующим связанным полям при загрузке снимков, потому что в противном случае будет сгенерировано исключение:
from django.db.models.signals import post_save
from .models import MyModel
def my_handler(**kwargs):
# disable the handler during fixture loading
if kwargs['raw']:
return
...
post_save.connect(my_handler, sender=MyModel)
Мы также могли бы написать декоратор для инкапсуляции этой логики:
from functools import wraps
def disable_for_loaddata(signal_handler):
"""
Decorator that turns off signal handlers when loading fixture data.
"""
@wraps(signal_handler)
def wrapper(*args, **kwargs):
if kwargs['raw']:
return
signal_handler(*args, **kwargs)
return wrapper
@disable_for_loaddata
def my_handler(**kwargs):
...
Однако имейте в виду, что эта логика будет отключать сигналы во время каждой десериализации снимков, а не только во время loaddata
.
Обратите внимание, что порядок, в котором загружаются файлы моментальных снимков, не определен. Однако все данные снимка устанавливаются в одной транзакции, поэтому данные из одного снимка могут ссылаться на данные из другого снимка. Если компонент Database Engine поддерживает ограничения на уровне строк, эти ограничения проверяются в конце транзакции.
Команду dumpdata
можно использовать для создания содержимого, предоставленного loaddata
.
Сжатые снимки ¶
Снимки могут быть сжаты в zip
, gz
или bz2
. Например :
django-admin loaddata mydata.json
поиск любой из файлов mydata.json
, mydata.json.zip
, mydata.json.gz
или mydata.json.bz2
. Используется первый файл, содержащийся в сжатом zip-архиве.
Обратите внимание: если обнаружены два снимка с одинаковым именем, но разного типа (например, если mydata.json
и mydata.xml.gz
находятся в одном каталоге снимков), установка снимков прерывается, и все данные, уже установленные вызовом, loaddata
удаляются из база данных.
MySQL с MyISAM и снимками
Механизм хранения MySQL MyISAM не управляет транзакциями или ограничениями. Если вы используете этот механизм, данные моментальных снимков не проверяются, и любые данные, уже загруженные в базу данных, не стираются в случае обнаружения конфликтующих файлов моментальных снимков.
Снимки, относящиеся к определенным базам данных ¶
Если вы используете конфигурацию с несколькими базами данных, вы можете захотеть загрузить несколько снимков в одну базу данных, но не в другую. В этом случае вы можете вставить идентификаторы базы данных в имена снимков.
Например, если ваш параметр DATABASES
содержит «главную» базу данных, назовите снимок mesdonnees.master.json
или mesdonnees.master.json.gz
этот снимок не будет загружен, пока вы не укажете, что хотите загрузить данные в базу данных master
.
Загрузка снимков из stdin
¶
Вы можете использовать дефис в качестве имени снимка, из которого загружаются данные sys.stdin
. например
django-admin loaddata --format=json -
При чтении из stdin
параметра --format
требуется указать формат сериализации данных (например, json
или xml
).
Загрузка из stdin
полезна со стандартными перенаправлениями ввода-вывода. например
django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -
makemessages
¶
-
django-admin makemessages
¶
Перемещает все дерево исходного кода из текущего каталога и извлекает все строки, отмеченные для перевода. Он создает (или обновляет) файл сообщений в каталоге conf/locale
(для дерева Django) или locale
(для проектов и приложений). После обновления файлов сообщений их по-прежнему необходимо скомпилировать, compilemessages
чтобы они могли использоваться интегрированным инструментом gettext
. См. Дополнительную информацию в документации по интернационализации .
Эта команда не запрашивает никаких настроенных параметров. Однако, если параметры не настроены, команда не может игнорировать MEDIA_ROOT
и / STATIC_ROOT
или включать каталоги LOCALE_PATHS
.
-
--all
,
-a
¶
Обновляет файлы сообщений для всех доступных языков.
-
--extension
EXTENSIONS
,
-e
EXTENSIONS
¶
Указывает список расширений файлов для изучения ( по умолчанию: html
, txt
, py
или , js
если --domain
есть js
).
Пример использования:
django-admin makemessages --locale=de --extension xhtml
Разделите несколько расширений запятыми или используйте несколько вхождений -e
или --extension
:
django-admin makemessages --locale=de --extension=html,txt --extension xml
-
--locale
LOCALE
,
-l
LOCALE
¶
Задает языки для обработки.
-
--exclude
EXCLUDE
,
-x
EXCLUDE
¶
Указывает языки, которые следует исключить из обработки заказа. Без дополнительной информации ни один язык не исключен.
Пример использования:
django-admin makemessages --locale=pt_BR
django-admin makemessages --locale=pt_BR --locale=fr
django-admin makemessages -l pt_BR
django-admin makemessages -l pt_BR -l fr
django-admin makemessages --exclude=pt_BR
django-admin makemessages --exclude=pt_BR --exclude=fr
django-admin makemessages -x pt_BR
django-admin makemessages -x pt_BR -x fr
-
--domain
DOMAIN
,
-d
DOMAIN
¶
Задает домен файлов сообщений. Допустимые варианты:
django
для всех файлов*.py
,*.html
и*.txt
( по умолчанию)djangojs
для файлов*.js
-
--symlinks
,
-s
¶
Переходит по символическим ссылкам на каталоги при поиске новых строк для перевода.
Пример использования:
django-admin makemessages --locale=de --symlinks
-
--ignore
PATTERN
,
-i
PATTERN
¶
Игнорировать файлы или каталоги, соответствующие glob
данному шаблону типа . Опция может быть указана более одного раза по разным причинам.
Эти основания используются по умолчанию: 'CVS'
, '.*'
, '*~'
, '*.pyc'
.
Пример использования:
django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
-
--no-default-ignore
¶
Отключает значения по умолчанию --ignore
.
-
--no-wrap
¶
Отключает сегментацию длинных строк сообщений на несколько строк в языковых файлах.
-
--no-location
¶
Подавляет запись строк комментариев в языковых файлах. С этой опцией переводчикам с хорошими техническими знаниями будет сложнее понять контекст каждого сообщения.#: filename:line
-
--add-location
[{full,file,never}]
¶
Управляет строками комментариев в языковых файлах. Если вариант:#: nom_fichier:ligne
full
(по умолчанию): строки содержат как имена файлов, так и номера строк.file
: номер строки опущен.never
: строки удаляются (эффект идентичен--no-location
).
Требуется версия gettext
0.19 или новее.
-
--keep-pot
¶
Предотвращает удаление временных файлов .pot, созданных перед созданием файла (ов) .po
. Это может быть полезно для отладки любых ошибок, препятствующих созданию окончательных языковых файлов.
Смотрите также
См. Раздел Настройка команды makemessages для получения инструкций о том, как настроить ключевые слова, которые makemessages
передаются xgettext
.
makemigrations
¶
-
django-admin makemigrations [app_label [app_label ...]]
¶
Создает новые миграции на основе изменений, обнаруженных в моделях. Миграции, их связь с приложениями и многое другое подробно описано в документации по миграции .
Указав одно или несколько имен приложений в качестве параметра, он ограничивает создание миграций указанными приложениями, а также их зависимостями (например, таблица на другом конце ключа ForeignKey
).
Чтобы добавить миграции в приложение, у которого нет каталога migrations
, запустите makemigrations
с меткой приложения в качестве параметра.
-
--noinput
,
--no-input
¶
Подавляет любой запрос к пользователю. Если удаленный запрос не может быть разрешен автоматически, заказ завершается с кодом ошибки 3.
-
--empty
¶
Производит пустую миграцию для данных приложений для ручной модификации. Этот параметр предназначен только для опытных пользователей, и его не следует использовать, если вы не знакомы с форматом миграции, операциями миграции и зависимостями между миграциями.
-
--dry-run
¶
Показывает миграции, которые могут быть произведены, но без фактической записи файла миграции на диск. Использование этой опции вместе с также показывает полные файлы миграции в том виде, в котором они должны быть записаны.--verbosity 3
-
--merge
¶
Позволяет разрешать конфликты миграции.
-
--name
NAME
,
-n
NAME
¶
Позволяет давать миграции имя по вашему выбору вместо автоматически созданного. Имя должно быть действительным идентификатором Python.
-
--no-header
¶
Создает файлы миграции без метки времени и заголовка версии Django.
-
--check
¶
Выйти makemigrations
со статусом, отличным от 0, если обнаружены изменения модели без соответствующей миграции.
migrate
¶
-
django-admin migrate [app_label] [migration_name]
¶
Обновляет состояние базы данных в соответствии со всеми текущими моделями и миграциями. Миграции, их связь с приложениями и многое другое подробно описано в документации по миграции .
Поведение этой команды меняется в зависимости от предоставленных параметров:
- Нет настройки: все приложения применяют все свои миграции.
<étiquette_app>
: Миграции для указанного приложения применяются до самой последней миграции. Это также может привести к миграции приложения из других приложений в зависимости от зависимостей.<étiquette_app> <nom_migration>
: Изменяет схему базы данных на состояние, в котором применяется указанная миграция, но без применения последующих миграций того же приложения; это может привести к отмене некоторых миграций, если миграции после именованной миграции уже были применены. Вы можете использовать префикс имени миграции, например.0001
, если он уникален для указанного имени приложения. Используйте это имя,zero
чтобы перенести все назад, то есть отменить все миграции для приложения.
Предупреждение
Когда вы отменяете миграции, все зависимые миграции также будут отменены, независимо от имени <app_label>
. Vuos можно использовать --plan
для предварительного контроля того, какие миграции будут отменены.
-
--database
DATABASE
¶
Указывает базу данных для миграции. По умолчанию это 'default'
.
-
--fake
¶
Отмечает миграции как примененные до целевой миграции (в соответствии с приведенными выше правилами), но без фактического выполнения операторов SQL для изменения схемы базы данных.
Это предназначено для опытных пользователей, чтобы напрямую управлять текущим состоянием миграции в случае, если они вручную применяют некоторые изменения; Имейте в виду, что использование --fake
создает риск помещения таблицы состояния миграции в состояние, при котором ручное вмешательство станет необходимым для правильного функционирования миграции.
-
--fake-initial
¶
Позволяет Django пропустить начальную миграцию приложения, если все таблицы базы данных с именами всех моделей, созданных всеми операциями CreateModel
в этой миграции, уже существуют. Эта опция предназначена для первого запуска миграций в базе данных, которая уже существовала до использования миграций. Однако, кроме имени таблиц, этот параметр не проверяет, что схема базы данных точно соответствует моделям, а это означает, что ее следует использовать только в том случае, если вы знаете, что текущая схема действительно совпадает. что записано в начальной миграции.
-
--plan
¶
Показывает операции миграции, которые будут выполнены для migrate
указанного порядка .
-
--run-syncdb
¶
Позволяет создавать таблицы приложений без миграций. Хотя это не рекомендуется, система миграции иногда работает слишком медленно с большими проектами с сотнями шаблонов.
-
--noinput
,
--no-input
¶
Подавляет любой интерактивный запрос к пользователю. Пример запроса может относиться к удалению устаревших типов контента.
-
--check
¶
Выполняет migrate
выход с ненулевым статусом при обнаружении непримененных миграций.
runserver
¶
-
django-admin runserver [addrport]
¶
Запускает облегченный веб-сервер разработки на локальном компьютере. По умолчанию сервер работает на порту 8000 по IP-адресу 127.0.0.1
. Вы можете явно передать ему IP-адрес и номер порта.
Если вы запустите этот сценарий от имени пользователя с обычными привилегиями (что рекомендуется), у вас может не быть разрешений на использование небольшого номера порта. Маленькие номера портов зарезервированы для суперпользователя (root).
Этот сервер использует объект приложения WSGI, указанный в настройке WSGI_APPLICATION
.
НЕ ИСПОЛЬЗУЙТЕ ДАННЫЙ СЕРВЕР В ПРОИЗВОДСТВЕННОЙ СРЕДЕ. Он не подвергался аудитам безопасности или тестам производительности. (И этого не ожидается. Наша задача - заботиться о веб-фреймворке, а не о веб-сервере, и улучшение этого сервера для работы в производственной среде выходит за рамки целей Django).
Сервер разработки автоматически перезагружает код Python во время каждого запроса, если это необходимо. Вам не нужно перезапускать сервер, чтобы изменения кода вступили в силу. Однако некоторые действия, такие как добавление файлов, не вызывают перезапуска, поэтому в этих случаях необходимо вручную перезапустить сервер.
Если вы используете Linux или MacOS и устанавливаете и pywatchman, и службу Watchman , это сигналы ядра, которые автоматически перезагружают сервер (вместо того, чтобы проверять даты изменения файлов каждую секунду). Таким образом, повышается производительность для крупных проектов, а также сокращается время отклика после изменения кода, более надежное обнаружение изменений и снижается энергопотребление. Django поддерживает pywatchman
1.2.0 или новее.
Большие папки с большим количеством файлов могут вызвать проблемы с производительностью
При использовании Watchman в проекте, включающем большие папки, отличные от Python, например node_modules
, например , рекомендуется игнорировать эти каталоги для повышения производительности. См. Документацию сторожа для получения дополнительной информации по этой теме.
Тайм-аут сторожа
-
DJANGO_WATCHMAN_TIMEOUT
¶
По умолчанию время ожидания Watchman
клиента составляет 5 секунд. Вы можете изменить его, установивDJANGO_WATCHMAN_TIMEOUT
переменная окружения.
Когда сервер запускается и всякий раз, когда код Python изменяется во время работы сервера, инфраструктура управления системой проверяет общие ошибки во всем проекте Django (см. Команду check
). Если обнаружены какие-либо ошибки, они отображаются в стандартном выводе.
Вы можете запускать столько серверов параллельно, сколько вам нужно, при условии, что они находятся на разных портах, выполняя их несколько раз .django-admin runserver
Обратите внимание, что IP-адрес по умолчанию ,, 127.0.0.1
недоступен с других компьютеров в сети. Чтобы сделать сервер разработки видимым с других машин в сети, используйте его собственный IP-адрес (например 192.168.2.1
) или 0.0.0.0
или ::
(если IPv6 включен).
Вы можете указать IPv6-адрес в квадратных скобках (например [200a::1]:8000
). Это автоматически включает поддержку IPv6.
Также можно указать имя хоста, состоящее только из символов ASCII.
Если приложение- компаньон staticfiles включено (это по умолчанию в новых проектах), команда переопределяетсяrunserver
собственной командой runserver .
Регистрация каждого запроса и ответа с сервера отправляется в регистратор django.server .
-
--noreload
¶
Отключает обращение к автоматическому перезапуску. Это означает, что любые изменения кода Python, сделанные во время работы сервера, не будут приняты во внимание, если затронутый модуль Python уже был загружен в память.
-
--nothreading
¶
Отключает использование потоков с сервером разработки. По умолчанию сервер использует несколько потоков (многопоточность).
-
--ipv6
,
-6
¶
Использует IPv6 для сервера разработки. Затем IP-адрес по умолчанию изменится с 127.0.0.1
на ::1
.
Примеры использования разных портов и адресов ¶
Порт 8000 на IP-адресе 127.0.0.1
:
django-admin runserver
Порт 8000 на IP-адресе 1.2.3.4
:
django-admin runserver 1.2.3.4:8000
Порт 7000 на IP-адресе 127.0.0.1
:
django-admin runserver 7000
Порт 7000 на IP-адресе 1.2.3.4
:
django-admin runserver 1.2.3.4:7000
Порт 8000 на IPv6-адресе ::1
:
django-admin runserver -6
Порт 7000 на IPv6-адресе ::1
:
django-admin runserver -6 7000
Порт 7000 на IPv6-адресе 2001:0db8:1234:5678::9
:
django-admin runserver [2001:0db8:1234:5678::9]:7000
Порт 8000 на IPv4-адресе хоста localhost
:
django-admin runserver localhost:8000
Порт 8000 на IPv6-адресе хоста localhost
:
django-admin runserver -6 localhost:8000
Обслуживание статических файлов с помощью сервера разработки ¶
По умолчанию сервер разработки не заботится об обслуживании статических файлов вашего сайта (таких как файлы CSS, изображения, содержимое и MEDIA_URL
т. Д.). Если вы хотите настроить Django для обслуживания статического контента, см. Раздел Обработка статических файлов (например, изображений, JavaScript, CSS) .
sendtestemail
¶
-
django-admin sendtestemail [email [email ...]]
¶
Отправляет тестовое электронное письмо (чтобы подтвердить, что отправка сообщений работает с Django) указанным получателям. Например :
django-admin sendtestemail foo@example.com bar@example.com
Есть несколько возможных вариантов, и вы без проблем можете комбинировать их:
-
--managers
¶
Отправляет по электронной почте на адреса электронной почты , перечисленных в MANAGERS
с mail_managers()
.
-
--admins
¶
Отправляет по электронной почте на адреса электронной почты , перечисленных в ADMINS
с mail_admins()
.
shell
¶
-
django-admin shell
¶
Запускает интерактивный интерпретатор Python.
-
--interface
{ipython,bpython,python}
,
-i
{ipython,bpython,python}
¶
Определяет используемую оболочку. По умолчанию Django использует IPython или bpython, если они установлены. Если оба установлены, вы можете указать нужный интерпретатор следующим образом:
IPython:
django-admin shell -i ipython
bpython:
django-admin shell -i bpython
Если у вас установлена одна из этих «богатых» оболочек, но вы хотите запустить «необработанный» интерпретатор Python, используйте python
имя интерфейса, например:
django-admin shell -i python
-
--nostartup
¶
Отключает чтение сценария запуска для «простого» интерпретатора Python. По умолчанию считывается сценарий, указанный в переменной среды.PYTHONSTARTUP
или сценарий ~/.pythonrc.py
.
-
--command
COMMAND
,
-c
COMMAND
¶
Позволяет передавать команду в виде текста для выполнения Django, например:
django-admin shell --command="import django; print(django.__version__)"
Вы также можете передать код через стандартный ввод, чтобы выполнить его. Например :
$ django-admin shell <<EOF
> import django
> print(django.__version__)
> EOF
В Windows REPL отображается из-за ограничений реализации select.select()
на этой платформе.
showmigrations
¶
-
django-admin showmigrations [app_label [app_label ...]]
¶
Показывает все миграции для проекта. Вы можете выбрать один из следующих двух форматов:
-
--list
,
-l
¶
Перечисляет все приложения, известные Django, миграции, доступные для каждого приложения, и состояние приложения для каждой миграции (отмечены значком [X]
рядом с именем миграции). При выборе одного --verbosity
из 2 или более также отображаются дата / время подачи заявки.
Приложения без миграции также включены в список, но текст отображается под их названием.(no migrations)
Это формат отображения по умолчанию.
Добавлено отображение даты / времени подачи заявок из многословности 2.
-
--plan
,
-p
¶
Показывает план миграции, которому Django будет следовать, чтобы применить миграции. Что касается --list
примененных миграций, они отмечены значком [X]
. Если уровень детализации больше 1, также отображаются все зависимости миграции.
Настройки app_label
ограничивают отображаемые результаты, но все же возможно, что зависимости указанных приложений также включены.
-
--database
DATABASE
¶
Задает базу данных для проверки. По умолчанию это default
.
sqlflush
¶
-
django-admin sqlflush
¶
Отображает команды SQL, которые были бы сгенерированы, если бы команда flush
была выполнена.
-
--database
DATABASE
¶
Задает базу данных, для которой должны отображаться операторы SQL. По умолчанию это default
.
sqlmigrate
¶
-
django-admin sqlmigrate app_label migration_name
¶
Отображает код SQL, соответствующий названной миграции. Для этого требуется активное соединение с базой данных, которое команда использует для разрешения имен ограничений; это означает, что вам нужно сгенерировать код SQL для копии базы данных, к которой вы позже захотите применить результат.
Обратите внимание, что sqlmigrate
полученный результат не окрашивается.
-
--backwards
¶
Создает код SQL, используемый для отмены миграции. По умолчанию созданный код SQL используется для выполнения миграции в прогрессивном направлении.
-
--database
DATABASE
¶
Задает базу данных, для которой должны быть созданы операторы SQL. По умолчанию это default
.
sqlsequencereset
¶
-
django-admin sqlsequencereset app_label [app_label ...]
¶
Отображает операторы SQL для сброса последовательности для заданных имен приложений.
Последовательности - это индексы, используемые некоторыми механизмами баз данных для получения следующего доступного числа для автоматически увеличиваемых полей.
Используйте эту команду для генерации кода SQL, который можно использовать для исправления ситуаций, когда последовательность не синхронизируется с данными в ее автоматически увеличиваемом поле.
-
--database
DATABASE
¶
Задает базу данных, для которой должны отображаться операторы SQL. По умолчанию это default
.
squashmigrations
¶
-
django-admin squashmigrations app_label [start_migration_name] migration_name
¶
Если возможно, объедините миграции étiquette_app
до и включительно nom_migration
с меньшим количеством миграций. Полученные в результате объединенные миграции могут легко появиться вместе с несвязанными миграциями. Для получения дополнительной информации, пожалуйста, прочтите « Объединение миграций» .
Если start_migration_name
указано, Django включает только миграции, начинающиеся с этой миграции. Это помогает увидеть пределы слияния миграционных операций RunPython
и django.db.migrations.operations.RunSQL
.
-
--no-optimize
¶
Отключает оптимизатор при создании объединенной миграции. По умолчанию Django пытается оптимизировать операции при миграции, чтобы уменьшить размер результирующего файла. Используйте эту опцию, если этот процесс завершился неудачно или создает неправильные миграции. В этом случае, однако, также было бы желательно заполнить отчет об ошибке для Django, поскольку эта оптимизация должна быть безопасной.
-
--noinput
,
--no-input
¶
Избегайте каких-либо интерактивных запросов к пользователю.
-
--squashed-name
SQUASHED_NAME
¶
Определяет имя объединенной миграции. Без этого автоматическое имя основывается на первой и последней миграциях с _squashed_
промежуточными значениями.
-
--no-header
¶
Создает объединенный файл миграции без метки времени и заголовка версии Django.
startapp
¶
-
django-admin startapp name [directory]
¶
Создает структуру каталогов приложения Django с указанным именем приложения в текущем каталоге или в указанном месте назначения.
По умолчанию новый каталог содержит один файл, а models.py
также другие файлы шаблонов приложения. Если указано только имя приложения, каталог приложения будет создан в текущем рабочем каталоге.
Если указан необязательный пункт назначения, Django использует этот существующий каталог, а не создает новый. Ты можешь использовать " . Означает текущий рабочий каталог.
Например :
django-admin startapp myapp /Users/jezdez/Code/myapp
-
--template
TEMPLATE
¶
Предоставляет путь к каталогу , содержащему модель пользовательского приложения, путь к несжатого архива ( .tar
) или сжатого архива ( .tar.gz
, .tar.bz2
, .tar.xz
, .tar.lzma
, .tgz
, .tbz2
, .txz
, .tlz
, .zip
) , содержащий файлы модели структуры приложения.
Например, эта команда ищет шаблон приложения в каталоге, указанном при создании приложения myapp
:
django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp
Django также принимает URL ( http
, https
, ftp
) для сжатых архивов , содержащих образцы файлов приложений, будучи ответственным за загрузку и распаковывать их на лету.
Например, воспользовавшись функцией GitHub, которая предоставляет репозитории в виде zip-файлов, вы можете использовать такой URL-адрес:
django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp
Добавлена поддержка архивов XZ ( .tar.xz
, .txz
) и LZMA ( .tar.lzma
, .tlz
).
-
--extension
EXTENSIONS
,
-e
EXTENSIONS
¶
Задает расширения файлов в шаблоне приложения, который должен создаваться механизмом шаблонов. py
по умолчанию.
-
--name
FILES
,
-n
FILES
¶
Задает файлы шаблонов приложений (в дополнение к файлам, которые соответствуют --extension
), которые должны создаваться механизмом шаблонов. По умолчанию это пустой список.
Для всех затронутых файлов используется:contexte de gabarit
- Любой вариант, отправленный в заказ
startapp
(среди вариантов, принятых заказом) app_name
- имя приложения, переданное командеapp_directory
- полный путь к вновь созданному приложениюcamel_case_app_name
- название приложения в формате CamelCasedocs_version
- версия документации:'dev'
или'1.x'
django_version
- версия Django, например.'2.0.3'
Предупреждение
Когда файлы шаблонов приложения создаются с помощью механизма шаблонов Django (по умолчанию все файлы *.py
), Django также переопределяет любые нецелевые переменные шаблона. Например, если один из файлов Python содержит строку «docstring», объясняющую некоторые функции, связанные с созданием шаблона, это может привести к неверному примеру.
Чтобы обойти эту проблему, вы можете использовать тег шаблона templatetag
для «экранирования» различных частей синтаксиса шаблона.
Кроме того, чтобы файлы шаблонов Python могли содержать синтаксис языка шаблонов Django, предотвращая попытки систем упаковки предварительно скомпилировать эти *.py
синтаксически недопустимые файлы, файлы шаблонов, заканчивающиеся на, .py-tpl
будут переименованы в .py
.
startproject
¶
-
django-admin startproject name [directory]
¶
Создает структуру каталогов проекта Django с заданным именем проекта в текущем каталоге или в указанном месте назначения.
По умолчанию новый каталог содержит manage.py
пакет проекта (содержащий settings.py
и другие файлы).
Если указано только имя проекта, будут названы <nom_projet>
и каталог проекта, и пакет проекта, а каталог проекта будет создан в текущем рабочем каталоге.
Если указано необязательное назначение, Django использует этот существующий каталог в качестве каталога проекта и, manage.py
таким образом, создает внутри пакет проекта. Ты можешь использовать " . Означает текущий рабочий каталог.
Например :
django-admin startproject myproject /Users/jezdez/Code/myproject_repo
-
--template
TEMPLATE
¶
Задает каталог, путь к файлу или URL-адрес для настраиваемого шаблона проекта. См. Документацию для примеров использования.startapp --template
-
--extension
EXTENSIONS
,
-e
EXTENSIONS
¶
Задает расширения файлов в шаблоне проекта, который должен создаваться механизмом шаблонов. py
по умолчанию.
-
--name
FILES
,
-n
FILES
¶
Указывает файлы шаблонов проекта (в дополнение к файлам --extension
), которые должны быть созданы механизмом шаблонов. По умолчанию это пустой список.
В используется:contexte de gabarit
- Любой вариант, отправленный в заказ
startproject
(среди вариантов, принятых заказом) project_name
- название проекта, отправленного в заказproject_directory
- полный путь к только что созданному проектуsecret_key
- случайный ключ для настройкиSECRET_KEY
docs_version
- версия документации:'dev'
или'1.x'
django_version
- версия Django, например.'2.0.3'
См. Также предупреждение о рендеринге, указанное для команды startapp
.
test
¶
-
django-admin test [test_label [test_label ...]]
¶
Запускает тесты всех установленных приложений. См. Раздел « Тестирование в Django» для получения дополнительной информации.
-
--failfast
¶
Останавливает выполнение теста и отображает отчет о сбое сразу после сбоя теста.
-
--testrunner
TESTRUNNER
¶
Задает класс запуска теста, используемый для запуска тестов. Это значение перезаписывает значение, содержащееся в настройке TEST_RUNNER
.
-
--noinput
,
--no-input
¶
Подавляет любой интерактивный запрос к пользователю. Типичный запрос - это, например, предупреждение об удалении существующей тестовой базы данных.
Параметры тестового запуска ¶
Команда test
получает параметры от --testrunner
указанного средства запуска тестов . Эти параметры теста бегуна по умолчанию: DiscoverRunner
.
-
--keepdb
¶
Сохраняет тестовую базу данных между тестовыми запусками. Это дает то преимущество, что пропускаются как действия создания, так и уничтожения, что может значительно сократить время выполнения тестов, особенно в большом наборе тестов. Если тестовая база данных не существует, она будет создана при первом запуске, а затем сохранена для каждого последующего запуска. Если параметр MIGRATE
тестирования не установлен
False
, любые непримененные миграции также будут применены к тестовой базе данных перед запуском набора тестов.
-
--reverse
,
-r
¶
Сортировка тестовых примеров в обратном порядке выполнения. Это может помочь отладить побочные эффекты в тестах, которые не изолированы правильно. При использовании этой опции сохраняется группировка по тестовым классам .
-
--debug-mode
¶
Устанавливает настройки DEBUG
для True
перед запуском тестов. Это может помочь в расследовании сбоев теста.
-
--debug-sql
,
-d
¶
Включает ведение журнала SQL для неудачных тестов. Если --verbosity
равно 2
, то также отображаются запросы в пройденных тестах.
-
--parallel
[N]
¶
-
DJANGO_TEST_PROCESSES
¶
Запускайте тесты параллельно в отдельных процессах. Поскольку современные процессоры имеют несколько ядер, это значительно ускоряет тестирование.
По умолчанию --parallel
запускается один процесс на ядро в соответствии с
multiprocessing.cpu_count()
. Вы можете настроить количество процессов, указав его как значение параметра, например --parallel=4
, или задавDJANGO_TEST_PROCESSES
переменная окружения.
Django распределяет тестовые примеры (подклассы unittest.TestCase
) по подпроцессам. Если количество тестов меньше, чем настроенных процессов, Django соответственно сокращает количество процессов.
Каждый процесс работает со своей собственной базой данных. Вам необходимо убедиться, что разные тестовые примеры не обращаются к одним и тем же ресурсам. Например, тестовые примеры, влияющие на файловую систему, должны создавать временный каталог для собственного использования.
Заметка
Если у вас есть тестовые классы, которые не могут выполняться параллельно, вы можете использовать SerializeMixin
их для последовательного запуска. См. Последовательное выполнение тестовых классов .
Этот параметр требует, чтобы внешний пакет tblib
правильно отображал стеки вызовов:
$ python -m pip install tblib
Эта функция недоступна в Windows. Он также не работает с базами данных Oracle.
Если вы хотите использовать pdb
при отладке тестов, вы должны отключить параллельное выполнение ( --parallel=1
). Если вы этого не сделаете, вы увидите что-то вроде bdb.BdbQuit
.
Предупреждение
Если включено распараллеливание тестов и тест не проходит, Django может не отображать стек вызовов исключения. Это может затруднить отладку. Если вы столкнулись с этой проблемой, запустите соответствующий тест без распараллеливания, чтобы увидеть стек вызовов на предмет сбоя.
Это известное ограничение. Это происходит из-за необходимости сериализации объектов, чтобы иметь возможность обмениваться ими между процессами. См. Что можно мариновать и не мариновать? Больше подробностей.
-
--tag
TAGS
¶
Выполняйте только тесты, отмеченные упомянутыми этикетками . Возможны несколько случаев и возможна комбинация с .test --exclude-tag
-
--exclude-tag
EXCLUDE_TAGS
¶
Исключает тесты, отмеченные упомянутыми этикетками . Возможны несколько случаев и возможна комбинация с .test --tag
-
-k
TEST_NAME_PATTERNS
¶
Запускает тестовые методы и классы, соответствующие шаблонам имен тестов, по тому же принципу, что и . Может указываться более одного раза.unittest's -k option
Python 3.7 и новее
Эта функция доступна только в Python 3.7.
-
--pdb
¶
Запускает отладчик pdb
при каждой ошибке или сбое теста. Если он установлен, то он ipdb
запускается вместо него.
-
--buffer
,
-b
¶
Отбрасывает вывод ( stdout
и stderr
) для прохождения тестов, так же, как .unittest's --buffer option
testserver
¶
-
django-admin testserver [fixture [fixture ...]]
¶
Запускает сервер разработки Django (как и runserver
) с использованием данных из данных снимков.
Например, эта команда:
django-admin testserver mydata.json
… Выполняет следующие операции:
- Создание тестовой базы данных, как описано в разделе «Тестовая база данных» .
- Заполните тестовую базу данных снимками данных с указанными именами снимков (более подробную информацию о снимках см. В документации
loaddata
). - Запустите сервер разработки Django (как и в случае
runserver
), используя только что созданную тестовую базу данных по ссылке производственной базы данных.
Это полезно в нескольких случаях:
- Когда вы пишете модульные тесты для взаимодействия между представлениями и определенными данными, полезно иметь возможность запускать
testserver
, чтобы вручную взаимодействовать с этими представлениями в веб-браузере. - Допустим, вы разрабатываете приложение Django и имеете «хорошую» копию базы данных, с которой хотели бы взаимодействовать. Вы можете экспортировать эту базу данных в моментальный снимок (с помощью команды,
dumpdata
описанной выше), а затем использоватьtestserver
для запуска веб-приложения с этими данными. С помощью этой системы вы можете свободно манипулировать данными по своему усмотрению, зная, что все эти изменения происходят только в тестовой базе данных.
Обратите внимание , что этот сервер не не автоматически обнаруживает изменения исходного кода Python (как это делает runserver
). С другой стороны, он принимает во внимание модификации шаблонов.
-
--addrport
ADDRPORT
¶
Задает порт или IP-адрес и порт, отличный от значения по умолчанию 127.0.0.1:8000
. Это значение соответствует точно такому же формату и играет ту же роль, что и параметр, заданный команде runserver
.
Примеры:
Чтобы запустить тестовый сервер на порту 7000 с данными fixture1
и fixture2
:
django-admin testserver --addrport 7000 fixture1 fixture2
django-admin testserver fixture1 fixture2 --addrport 7000
(Вышеуказанные команды эквивалентны. Мы написали их обе, чтобы показать, что размещение параметров до или после настроек моментального снимка не имеет значения.)
Чтобы запустить сервер на 1.2.3.4:7000 со снимком test
:
django-admin testserver --addrport 1.2.3.4:7000 test
-
--noinput
,
--no-input
¶
Подавляет любой интерактивный запрос к пользователю. Типичный запрос - это, например, предупреждение об удалении существующей тестовой базы данных.
Команды, предоставляемые приложениями ¶
Некоторые команды доступны только тогда, когда приложение django.contrib
, реализующее их , было activée
. В этом разделе они сгруппированы по приложениям.
django.contrib.auth
¶
changepassword
¶
-
django-admin changepassword [<username>]
¶
Эта команда доступна, только если установлена система аутентификации Django ( django.contrib.auth
).
Позволяет изменить пароль пользователя. Вам будет предложено дважды ввести пароль для указанного пользователя. Если две записи совпадают, новый пароль будет установлен немедленно. Если вы не укажете имя пользователя, команда попытается изменить пароль пользователя, имя которого совпадает с именем текущего пользователя системы.
-
--database
DATABASE
¶
Указывает, в какой базе данных следует искать пользователя. По умолчанию это база данных default
.
Пример использования:
django-admin changepassword ringo
createsuperuser
¶
-
django-admin createsuperuser
¶
-
DJANGO_SUPERUSER_PASSWORD
¶
Эта команда доступна, только если установлена система аутентификации Django ( django.contrib.auth
).
Создайте учетную запись суперпользователя (одного пользователя с полными правами). Это полезно, если вам нужно создать учетную запись суперпользователя или программно создать учетные записи суперпользователя для вашего сайта.
При запуске в интерактивном режиме эта команда запросит пароль для новой учетной записи суперпользователя. При неинтерактивном запуске вы можете указать пароль, установив параметрDJANGO_SUPERUSER_PASSWORD
переменная окружения. В противном случае пароль не будет установлен, и учетная запись суперпользователя не сможет войти в систему, пока для нее не будет вручную установлен пароль.
В неинтерактивном режиме поля USERNAME_FIELD
и обязательные (перечисленные в REQUIRED_FIELDS
) возвращаются к значениям переменных среды, DJANGO_SUPERUSER_<nom_champ_en_majuscules>
если они не включены в параметры командной строки. Например, чтобы email
указать значение для поля , вы можете установить переменную среды DJANGO_SUPERUSER_EMAIL
.
Поддержка переменных окружения DJANGO_SUPERUSER_PASSWORD
и DJANGO_SUPERUSER_<nom_champ_en_majuscules>
была добавлена.
-
--noinput
,
--no-input
¶
Подавляет любой запрос к пользователю. Если удаленный запрос не может быть разрешен автоматически, заказ завершается с кодом ошибки 1.
-
--username
USERNAME
¶
-
--email
EMAIL
¶
Имя пользователя и адрес электронной почты для новой учетной записи можно указать с помощью параметров --username
и --email
из командной строки. Если эти параметры не заполнены, createsuperuser
попросите ввести их в интерактивном режиме.
-
--database
DATABASE
¶
Задает базу данных, в которой будет сохранен объект суперпользователя.
Вы можете создать подкласс команды администратора и переопределить, get_input_data()
если хотите настроить ввод и проверку данных. Изучите исходный код для получения подробной информации о существующей реализации и параметрах метода. Например, это может быть полезно , если у вас есть ключ ForeignKey
в REQUIRED_FIELDS
и хотите разрешить создание экземпляра вместо того , чтобы войти в первичный ключ существующего экземпляра.
django.contrib.contenttypes
¶
remove_stale_contenttypes
¶
-
django-admin remove_stale_contenttypes
¶
Эта команда доступна, только если установлено приложение contenttypes ( django.contrib.contenttypes
).
Удаляет устаревшие типы контента (из удаленных шаблонов) из базы данных. Любой объект, зависящий от типа удаленного содержимого, также будет уничтожен. Список удаленных объектов будет отображен перед подтверждением продолжения удаления.
-
--database
DATABASE
¶
Задает базу данных для использования. По умолчанию это default
.
-
--include-stale-apps
¶
Удаляет устаревшие типы контента, в том числе из ранее установленных приложений, которые были удалены из INSTALLED_APPS
. По умолчанию False
.
django.contrib.gis
¶
ogrinspect
¶
Эта команда доступна, только если установлен GeoDjango ( django.contrib.gis
).
См. Его description
в документации GeoDjango.
django.contrib.sessions
¶
django.contrib.sitemaps
¶
ping_google
¶
Эта команда доступна, только если установлена инфраструктура " sitemap" ( django.contrib.sitemaps
).
См. Его description
в документации по файлам Sitemap.
django.contrib.staticfiles
¶
collectstatic
¶
Эта команда доступна, только если установлено приложение статических файлов ( django.contrib.staticfiles
).
См. Его description
в документации по статическим файлам .
findstatic
¶
Эта команда доступна, только если установлено приложение статических файлов ( django.contrib.staticfiles
).
См. Его description
в документации по статическим файлам .
Параметры по умолчанию ¶
Хотя некоторые команды определяют свои собственные настраиваемые параметры, каждая команда принимает следующие параметры:
-
--pythonpath
PYTHONPATH
¶
Добавляет указанный путь файловой системы к пути поиска импорта Python . Если это не предусмотрено, django-admin
будет использоватьсяPYTHONPATH
переменная окружения.
Эта опция бесполезна manage.py
, потому что она устанавливает путь Python за вас.
Пример использования:
django-admin migrate --pythonpath='/home/djangoprojects/myproject'
-
--settings
SETTINGS
¶
Определяет используемый модуль настроек. Модуль настроек должен быть в синтаксисе пакета Python, например mysite.settings
. Если это не предусмотрено,
django-admin
будет использоватьсяDJANGO_SETTINGS_MODULE
переменная окружения.
Этот параметр не является обязательным manage.py
, поскольку по умолчанию он использует модуль settings.py
текущего проекта.
Пример использования:
django-admin migrate --settings=mysite.settings
-
--traceback
¶
Отображает полную трассировку стека вызовов при возникновении исключения CommandError
. По умолчанию django-admin
при возникновении ошибки отображает сообщение об ошибке CommandError
и полную трассировку стека вызовов для всех других исключений.
Пример использования:
django-admin migrate --traceback
-
--verbosity
{0,1,2,3}
,
-v
{0,1,2,3}
¶
Задает количество ориентировочной и отладочной информации, которую команда должна отображать в консоли.
0
означает отсутствие отображения.1
означает нормальный дисплей (по умолчанию).2
означает болтливый дисплей.3
означает очень подробное отображение .
Пример использования:
django-admin migrate --verbosity 2
-
--no-color
¶
Отключает цветное отображение результатов команды. Некоторые команды форматируют свой результат в цвете. Например, ошибки, отображаемые в консоли, отображаются красным цветом, а синтаксис операторов SQL - цветом.
Пример использования:
django-admin runserver --no-color
-
--force-color
¶
Принудительно раскрашивает результат команды, если он был отключен, как описано в разделе Цветной синтаксис . Например, может потребоваться перенаправить цветной результат другой команде.
-
--skip-checks
¶
Пропускает системные проверки перед подачей команды. Эта опция доступна , только если атрибут команды requires_system_checks
установлен True
.
Пример использования:
django-admin migrate --skip-checks
Дополнительные опции ¶
Цветной синтаксис ¶
-
DJANGO_COLORS
¶
Элементы управления django-admin
/ manage.py
представляют свой дисплей с визуально привлекательным цветовым кодом, если терминал поддерживает цветной дисплей типа ANSI. Цветовые коды не используются, если вы перенаправляете результат команды в другую программу, если --force-color
не указан параметр.
В Windows собственная консоль не поддерживает escape-последовательности ANSI, поэтому результат не окрашивается. Однако вы можете установить внешний инструмент ANSICON , который команды Django будут обнаруживать и использовать для создания цветного вывода, как для Unix-подобных платформ.
Цвета, используемые для цветного синтаксиса, можно настроить. Django содержит три цветовые палитры:
dark
(темный), подходит для терминалов, отображающих белый текст на черном фоне. Это палитра по умолчанию.light
(чистый), подходит для терминалов, отображающих черный текст на белом фоне.nocolor
(без цвета), который отключает цветной синтаксис.
Вы выбираете палитру, устанавливая DJANGO_COLORS
переменная среды, чтобы указать палитру, которую вы хотите использовать. Например, чтобы указать light
палитру в оболочке Unix или OS / X BASH, вы должны запустить в командной строке следующее:
export DJANGO_COLORS="light"
Также можно настроить используемые цвета. Django определяет ряд ролей, используемых цветами:
error
- Большая ошибка.notice
- Небольшая ошибка.success
- Успех.warning
- Предупреждение.sql_field
- Имя поля модели в SQL.sql_coltype
- Тип поля модели в SQL.sql_keyword
- Ключевое слово SQL.sql_table
- Название модели в SQL.http_info
- Ответ HTTP-сервера информационного типа (1XX)http_success
- Успешный ответ HTTP-сервера (2XX)http_not_modified
- Неизмененный ответ HTTP-сервера (304)http_redirect
- Ответ HTTP-сервера с типом перенаправления (3XX, кроме 304).http_not_found
- Ответ HTTP-сервера не найден (404).http_bad_request
- Неверный ответ HTTP-сервера типа запроса (4XX, кроме 404).http_server_error
- Ответ HTTP-сервера типа ошибки (5XX).migrate_heading
- Заголовок в команде администрирования миграции.migrate_label
- Имя миграции.
Каждой из этих ролей может быть назначен определенный цвет переднего плана или фона из следующего списка:
black
(Черный)red
(Красный)green
(Зеленый)yellow
(Желтый)blue
(Синий)magenta
cyan
white
(Белый)
Затем каждый из этих цветов можно изменить, используя следующие параметры отображения:
bold
(смелый)underscore
(Выделено)blink
(указатель поворота)reverse
conceal
(Маска)
Спецификация цвета соответствует одной из следующих причин:
role=fg
role=fg/bg
role=fg,option,option
role=fg/bg,option,option
где role
- имя допустимой цветовой роли, fg
- bg
цвет переднего плана, - цвет фона, и каждый option
- один из вариантов изменения цвета. Затем несколько цветовых обозначений разделяются точкой с запятой. Например :
export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
указывает, что ошибки должны отображаться мигающим желтым цветом поверх синего, а информация отображается пурпурным цветом. Все остальные цветовые роли не имеют определенного цвета.
Цвета также можно указать, расширив базовую палитру. Если вы укажете имя палитры в спецификации цвета, будут загружены все цвета, содержащиеся в этой палитре. Так :
export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
указывает, что следует использовать все цвета в палитре света, кроме цветов для ошибок и информации, которая перегружена, как показано.
Завершение Bash ¶
Если вы используете оболочку Bash, рекомендуется установить сценарий Django завершения Bash, который находится в extras/django_bash_completion
исходном дистрибутиве Django. Он активирует завершение путем табулирования команд django-admin
и для manage.py
того, чтобы иметь возможность, например ...
- Войдите
django-admin
. - Нажмите [TAB], чтобы увидеть все доступные параметры.
- Введите
sql
, затем [TAB], чтобы увидеть все доступные команды, имена которых начинаются сsql
.
См. Раздел Написание пользовательских команд django-admin, чтобы узнать, как добавлять пользовательские действия.
Запуск команд управления из кода ¶
-
django.core.management.
call_command
( имя , * аргументы , ** параметры ) ¶
Чтобы вызвать команду управления из кода, используйте call_command
.
name
- имя вызываемой команды или командного объекта. Желательно передать имя, если только предмет не является обязательным для тестирования.
*args
- список параметров, принимаемых командой. Параметры передаются парсеру параметров, что означает, что вы можете использовать тот же стиль, что и в командной строке. Например, .
call_command('flush', '--verbosity=0')
**options
- Именованные параметры принимаются в командной строке. Параметры передаются команде без вызова парсера параметров, что означает, что необходимо передать правильный тип. Например, (ноль должен быть целым числом, а не строкой).
call_command('flush', verbosity=0)
Примеры:
from django.core import management
from django.core.management.commands import loaddata
management.call_command('flush', verbosity=0, interactive=False)
management.call_command('loaddata', 'test_data', verbosity=0)
management.call_command(loaddata.Command(), 'test_data', verbosity=0)
Обратите внимание, что параметры команды, которые не принимают параметр, передаются как ключевые слова с True
или False
, как вы можете видеть с помощью параметра interactive
выше.
Именованные параметры могут быть переданы с использованием одного из следующих синтаксисов:
# Similar to the command line
management.call_command('dumpdata', '--natural-foreign')
# Named argument similar to the command line minus the initial dashes and
# with internal dashes replaced by underscores
management.call_command('dumpdata', natural_foreign=True)
# `use_natural_foreign_keys` is the option destination variable
management.call_command('dumpdata', use_natural_foreign_keys=True)
Некоторые параметры команды называются по-другому, когда команды вызываются с помощью call_command()
вместо django-admin
или manage.py
. Например, переводится как . Чтобы узнать, для какого именованного имени параметра использовать , просмотрите исходный код команды и найдите переданный параметр .django-admin createsuperuser --no-input
call_command('createsuperuser', interactive=False)
call_command()
dest
parser.add_argument()
Параметры команды, принимающие несколько параметров, передаются в виде списка:
management.call_command('dumpdata', exclude=['contenttypes', 'auth'])
Значение, возвращаемое функцией, call_command()
такое же, как значение, возвращаемое методом handle()
команды.
Перенаправление вывода ¶
Обратите внимание, что вы можете перенаправить стандартный вывод и потоки ошибок, потому что все команды принимают параметры stdout
и stderr
, например, вы можете написать:
with open('/path/to/command_output', 'w') as f:
management.call_command('dumpdata', stdout=f)