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-admin с DJANGO_SETTINGS_MODULE или опцию командной строки --settings.

Примеры командной строки в этом документе используют 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-admin version для отображения текущей версии Django.

Вывод следует схеме, описанной в PEP 440:

1.4.dev17026
1.4a1
1.4

Отображение вывода отладки

Используйте --verbosity, где это поддерживается, чтобы указать количество уведомлений и отладочной информации, которую django-admin выводит на консоль.

Доступные команды

check

django-admin check [app_label [app_label ...]]

Использует system check framework для проверки всего проекта Django на наличие общих проблем.

По умолчанию будут проверены все приложения. Вы можете проверить подмножество приложений, предоставив список ярлыков приложений в качестве аргументов:

django-admin check auth admin myapp
--tag TAGS, -t TAGS

Система проверки выполняет множество различных типов проверок, которые относятся к категории categorized with tags. Вы можете использовать эти теги для ограничения выполняемых проверок только теми, которые относятся к определенной категории. Например, чтобы выполнить только проверки моделей и совместимости, выполните:

django-admin check --tag models --tag compatibility
--database DATABASE

Указывает базу данных для запуска проверок, требующих доступа к базе данных:

django-admin check --database default --database other

По умолчанию эти проверки не выполняются.

--list-tags

Перечисляет все доступные теги.

--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

Включает fuzzy translations в скомпилированные файлы.

Пример использования:

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.

Эта команда предполагает, что программы находятся на вашем PATH, так что обращение к имени программы (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()               |
+----------------------+
| djangonaut@localhost |
+----------------------+

...\> django-admin dbshell -- -e "select user()"
+----------------------+
| user()               |
+----------------------+
| djangonaut@localhost |
+----------------------+

Примечание

Помните, что не все параметры, установленные в части OPTIONS конфигурации вашей базы данных в DATABASES, передаются клиенту командной строки, например, 'isolation_level'.

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 использует менеджер по умолчанию в модели для выбора записей для дампа. Если вы используете custom manager в качестве менеджера по умолчанию и он фильтрует некоторые из доступных записей, не все объекты будут сброшены.

--all, -a

Использует базовый менеджер Django, сбрасывая записи, которые в противном случае могли бы быть отфильтрованы или изменены пользовательским менеджером.

--format FORMAT

Определяет формат сериализации вывода. По умолчанию используется JSON. Поддерживаемые форматы перечислены в Форматы сериализации.

--indent INDENT

Определяет количество отступов, которые будут использоваться в выводе. По умолчанию установлено значение None, при котором все данные выводятся в одну строку.

--exclude EXCLUDE, -e EXCLUDE

Предотвращает сброс определенных приложений или моделей (указанных в форме app_label.ModelName). Если вы укажете имя модели, то будет исключена только эта модель, а не все приложение. Вы также можете смешивать имена приложений и моделей.

Если вы хотите исключить несколько приложений, передайте --exclude несколько раз:

django-admin dumpdata --exclude=auth --exclude=contenttypes
--database DATABASE

Указывает базу данных, из которой будет производиться дамп данных. По умолчанию имеет значение default.

--natural-foreign

Использует метод модели natural_key() для сериализации любого внешнего ключа и отношения «многие-ко-многим» к объектам типа, определяющего этот метод. Если вы сбрасываете contrib.auth Permission объекты или contrib.contenttypes ContentType объекты, вам, вероятно, следует использовать этот флаг. Подробнее об этом и следующем параметре см. в документации natural keys.

--natural-primary

Опускает первичный ключ в сериализованных данных этого объекта, поскольку он может быть вычислен при десериализации.

--pks PRIMARY_KEYS

Выводит только объекты, указанные в списке первичных ключей, разделенных запятыми. Это доступно только при выводе одной модели. По умолчанию выводятся все записи модели.

--output OUTPUT, -o OUTPUT

Указывает файл для записи сериализованных данных. По умолчанию данные отправляются в стандартный вывод.

Когда эта опция установлена и --verbosity больше 0 (по умолчанию), в терминале отображается индикатор выполнения.

Сжатие приспособлений

Выходной файл может быть сжат одним из форматов bz2, gz, lzma или xz, завершив имя файла соответствующим расширением. Например, для вывода данных в виде сжатого файла JSON:

django-admin dumpdata -o mydata.json.gz

flush

django-admin flush

Удаляет все данные из базы данных и повторно выполняет все обработчики постсинхронизации. Таблица, к которой были применены миграции, не очищается.

Если вы предпочитаете начать с пустой базы данных и заново выполнить все миграции, вам следует удалить и заново создать базу данных, а затем запустить migrate.

--noinput, --no-input

Подавляет все подсказки пользователя.

--database DATABASE

Указывает базу данных для промывки. По умолчанию имеет значение default.

inspectdb

django-admin inspectdb [table [table ...]]

Интроспекция таблиц базы данных в базе данных, на которую указывает параметр NAME, и вывод модуля модели Django (файл models.py) на стандартный вывод.

Вы можете выбрать, какие таблицы или представления проверять, передав их имена в качестве аргументов. Если аргументы не указаны, модели создаются только для представлений, если используется опция --include-views. Модели для таблиц разделов создаются на PostgreSQL, если используется опция --include-partitions.

Используйте его, если у вас есть унаследованная база данных, с которой вы хотели бы использовать Django. Сценарий проверит базу данных и создаст модель для каждой таблицы в ней.

Как и следовало ожидать, созданные модели будут иметь атрибут для каждого поля в таблице. Обратите внимание, что inspectdb имеет несколько особых случаев в выводе имен полей:

  • Если inspectdb не может сопоставить тип колонки с типом поля модели, он будет использовать TextField и вставит комментарий Python 'This field type is a guess.' рядом с полем в сгенерированной модели. Распознанные поля могут зависеть от приложений, перечисленных в INSTALLED_APPS. Например, django.contrib.postgres добавляет распознавание нескольких типов полей, специфичных для PostgreSQL.
  • Если имя столбца базы данных является зарезервированным словом Python (например, 'pass', 'class' или 'for'), inspectdb добавит '_field' к имени атрибута. Например, если таблица имеет столбец 'for', сгенерированная модель будет иметь поле 'for_field', с атрибутом db_column, установленным в 'for'. inspectdb вставит комментарий Python 'Field renamed because it was a Python reserved word.' рядом с полем.

Эта функция предназначена для сокращения времени, а не для окончательного создания моделей. После ее запуска вы захотите самостоятельно просмотреть сгенерированные модели, чтобы внести изменения. В частности, вам нужно будет изменить порядок моделей, чтобы модели, ссылающиеся на другие модели, были упорядочены должным образом.

Django не создает значения по умолчанию базы данных, когда в поле модели указано default. Аналогично, значения по умолчанию базы данных не переводятся в значения по умолчанию полей модели и не определяются каким-либо образом с помощью inspectdb.

По умолчанию inspectdb создает неуправляемые модели. То есть, managed = False в классе модели Meta указывает Django не управлять созданием, изменением и удалением каждой таблицы. Если вы хотите позволить Django управлять жизненным циклом таблицы, вам нужно изменить параметр managed на True (или удалить его, поскольку True является его значением по умолчанию).

Примечания, относящиеся к конкретной базе данных

Oracle
  • Модели создаются для материализованных представлений, если используется --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

Указывает serialization format (например, json или xml) для фиксаторов read from stdin.

--exclude EXCLUDE, -e EXCLUDE

Исключает загрузку фикстур из заданных приложений и/или моделей (в виде app_label или app_label.ModelName). Используйте опцию несколько раз, чтобы исключить более одного приложения или модели.

Что такое «приспособление»?

Приспособление fixture - это набор файлов, которые содержат сериализованное содержимое базы данных. Каждое приспособление имеет уникальное имя, а файлы, составляющие приспособление, могут быть распределены по нескольким каталогам в нескольких приложениях.

Django будет искать светильники в трех местах:

  1. В каталоге fixtures каждого установленного приложения
  2. В любой директории, названной в настройке FIXTURE_DIRS
  3. В буквальном пути, названном приспособлением

Django загрузит все фикстуры, которые найдет в этих местах и которые соответствуют указанным именам фикстур.

Если названное приспособление имеет расширение файла, будут загружены только приспособления этого типа. Например:

django-admin loaddata mydata.json

будет загружать только JSON-фиксаторы с именем mydata. Расширение приспособления должно соответствовать зарегистрированному имени serializer (например, json или xml).

Если вы опустите расширения, Django будет искать подходящее приспособление во всех доступных типах приспособлений. Например:

django-admin loaddata mydata

будет искать любое приспособление любого типа с именем mydata. Если каталог приспособлений содержит mydata.json, то это приспособление будет загружено как JSON-приспособление.

Названные приспособления могут включать компоненты каталогов. Эти каталоги будут включены в путь поиска. Например:

django-admin loaddata foo/bar/mydata.json

будет искать <app_label>/fixtures/foo/bar/mydata.json для каждого установленного приложения, <dirname>/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.

Обратите внимание, что порядок обработки файлов приспособлений не определен. Однако все данные приспособления устанавливаются как одна транзакция, поэтому данные в одном приспособлении могут ссылаться на данные в другом приспособлении. Если бэкэнд базы данных поддерживает ограничения на уровне строк, эти ограничения будут проверяться в конце транзакции.

Команда dumpdata может быть использована для генерации входных данных для loaddata.

Сжатые приспособления

Фиксики могут быть сжаты в формате zip, gz, bz2, lzma или xz. Например:

django-admin loaddata mydata.json

будет искать любой из mydata.json, mydata.json.zip, mydata.json.gz, mydata.json.bz2, mydata.json.lzma или mydata.json.xz. Используется первый файл, содержащийся в сжатом архиве.

Обратите внимание, что если обнаружены два приспособления с одинаковым именем, но разным типом приспособления (например, если mydata.json и mydata.xml.gz были найдены в одном каталоге приспособлений), установка приспособления будет прервана, а все данные, установленные в вызове loaddata, будут удалены из базы данных.

MySQL с MyISAM и креплениями

Механизм хранения MyISAM в MySQL не поддерживает транзакции или ограничения, поэтому если вы используете MyISAM, вы не получите проверку данных фиксации или откат при обнаружении нескольких файлов транзакций.

Приспособления, специфичные для базы данных

Если вы работаете с несколькими базами данных, у вас могут быть данные приспособлений, которые вы хотите загрузить в одну базу данных, но не в другую. В этой ситуации вы можете добавить идентификатор базы данных в имена ваших приспособлений.

Например, если в настройке DATABASES определена база данных „users“, назовите приспособление mydata.users.json или mydata.users.json.gz, и приспособление будет загружаться только тогда, когда вы укажете, что хотите загрузить данные в базу данных users.

Загрузка приспособлений из stdin

Вы можете использовать тире в качестве имени приспособления для загрузки ввода из sys.stdin. Например:

django-admin loaddata --format=json -

При чтении из stdin, опция --format необходима для указания serialization 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. Подробности смотрите в i18n documentation.

Эта команда не требует настроенных параметров. Однако, когда параметры не настроены, команда не может игнорировать каталоги 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

Следование симлинкам на каталоги при поиске новых строк перевода.

Пример использования:

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}]

Управляет строками комментариев #: filename:line в языковых файлах. Если опция:

  • full (по умолчанию, если не указано): строки включают имя файла и номер строки.
  • file: номер строки опускается.
  • never: линии подавляются (так же, как --no-location).

Требуется gettext 0.19 или новее.

--keep-pot

Предотвращает удаление временных файлов .pot, созданных перед созданием файла .po. Это полезно для отладки ошибок, которые могут помешать созданию окончательных языковых файлов.

См.также

Смотрите Настройка команды makemessages для инструкций по настройке ключевых слов, которые makemessages передает в xgettext.

makemigrations

django-admin makemigrations [app_label [app_label ...]]

Создает новые миграции на основе изменений, обнаруженных в ваших моделях. Миграции, их связь с приложениями и многое другое подробно рассматривается в the migrations documentation.

Предоставление одного или нескольких имен приложений в качестве аргументов ограничит создаваемые миграции указанными приложениями и любыми необходимыми зависимостями (например, таблицей на другом конце ForeignKey).

Чтобы добавить миграции в приложение, у которого нет каталога migrations, запустите makemigrations с каталогом приложения app_label.

--noinput, --no-input

Подавляет все подсказки пользователя. Если подавленная подсказка не может быть разрешена автоматически, команда завершается с кодом ошибки 3.

--empty

Выводит пустую миграцию для указанных приложений для редактирования вручную. Эта функция предназначена для опытных пользователей и не должна использоваться, если вы не знакомы с форматом миграции, операциями миграции и зависимостями между миграциями.

--dry-run

Показывает, какие миграции будут сделаны без фактической записи файлов миграций на диск. Использование этой опции вместе с --verbosity 3 также покажет полные файлы миграций, которые будут записаны.

--merge

Позволяет исправлять конфликты миграции.

--name NAME, -n NAME

Позволяет именовать сгенерированный переход(ы) вместо использования сгенерированного имени. Имя должно быть правильным Python identifier.

--no-header

Генерировать файлы миграции без заголовка версии Django и временной метки.

--check

Заставляет makemigrations выходить с ненулевым статусом при обнаружении изменений модели без миграций.

--scriptable
New in Django 4.1.

Перенаправляет вывод журнала и подсказки ввода в stderr, записывая в stdout только пути сгенерированных файлов миграции.

migrate

django-admin migrate [app_label] [migration_name]

Синхронизирует состояние базы данных с текущим набором моделей и миграций. Миграции, их связь с приложениями и многое другое подробно рассматривается в the migrations documentation.

Поведение этой команды меняется в зависимости от предоставленных аргументов:

  • Без споров: Все приложения выполнили все свои миграции.
  • <app_label>: Для указанного приложения выполняются его миграции, вплоть до самой последней миграции. Это может включать запуск миграций других приложений из-за зависимостей.
  • <app_label> <migrationname>: Приводит схему базы данных в состояние, в котором применяется названная миграция, но не применяются последующие миграции в том же приложении. Это может привести к неприменению миграций, если вы ранее выполнили миграцию после именованной миграции. Вы можете использовать префикс имени миграции, например 0001, если он уникален для данного имени приложения. Используйте имя zero для миграции назад, т.е. для отмены всех примененных миграций для приложения.

Предупреждение

При неприменении миграций все зависимые миграции также будут неприменены, независимо от <app_label>. Вы можете использовать --plan, чтобы проверить, какие миграции будут отменены.

--database DATABASE

Указывает базу данных для миграции. По умолчанию имеет значение default.

--fake

Отмечает миграции до целевой (следуя правилам выше) как примененные, но без фактического выполнения SQL для изменения схемы базы данных.

Это предназначено для опытных пользователей, чтобы напрямую управлять текущим состоянием миграции, если они вручную применяют изменения; предупреждаем, что использование --fake рискует привести таблицу состояния миграции в состояние, когда для корректного выполнения миграций потребуется ручное восстановление.

--fake-initial

Позволяет Django пропустить начальную миграцию приложения, если все таблицы базы данных с именами всех моделей, созданных всеми операциями CreateModel в этой миграции, уже существуют. Эта опция предназначена для использования при первом запуске миграций с базой данных, которая предшествовала использованию миграций. Однако эта опция не проверяет соответствие схемы базы данных, помимо соответствия имен таблиц, и поэтому ее можно использовать только в том случае, если вы уверены, что существующая схема совпадает с той, что записана в начальной миграции.

--plan

Показывает операции миграции, которые будут выполнены для данной команды migrate.

--run-syncdb

Позволяет создавать таблицы для приложений без миграций. Хотя это не рекомендуется, фреймворк миграций иногда слишком медленный в больших проектах с сотнями моделей.

--noinput, --no-input

Подавляет все подсказки пользователя. Примером подсказки является вопрос об удалении устаревших типов содержимого.

--check

Заставляет migrate выходить с ненулевым статусом при обнаружении непримененных миграций.

--prune
New in Django 4.1.

Удаляет несуществующие миграции из таблицы django_migrations. Это полезно, когда файлы миграции, замененные скомканной миграцией, были удалены. См. раздел Сжатие миграций для более подробной информации.

optimizemigration

New in Django 4.1.
django-admin optimizemigration app_label migration_name

Оптимизирует операции для именованной миграции и заменяет существующий файл. Если миграция содержит функции, которые должны быть скопированы вручную, команда создает новый файл миграции с суффиксом _optimized, который предназначен для замены именованной миграции.

--check

Заставляет optimizemigration выходить с ненулевым статусом, когда миграция может быть оптимизирована.

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, рекомендуется игнорировать этот каталог для оптимальной производительности. Смотрите watchman documentation для получения информации о том, как это сделать.

Тайм-аут сторожа

DJANGO_WATCHMAN_TIMEOUT

По умолчанию тайм-аут клиента Watchman составляет 5 секунд. Вы можете изменить его, установив переменную окружения DJANGO_WATCHMAN_TIMEOUT.

Когда вы запускаете сервер, и каждый раз, когда вы изменяете код Python во время работы сервера, фреймворк system check будет проверять весь ваш проект Django на наличие некоторых общих ошибок (см. команду check). Если будут найдены какие-либо ошибки, они будут выведены на стандартный вывод. Вы можете использовать опцию --skip-checks, чтобы пропустить запуск системных проверок.

Вы можете запустить столько параллельных серверов, сколько хотите, если они находятся на разных портах, выполнив django-admin runserver более одного раза.

Note that the default IP address, 127.0.0.1, is not accessible from other machines on your network. To make your development server viewable to other machines on the network, use its own IP address (e.g. 192.168.2.1), 0 (shortcut for 0.0.0.0), 0.0.0.0, or :: (with IPv6 enabled).

Вы можете указать IPv6-адрес, окруженный скобками (например, [200a::1]:8000). Это автоматически включит поддержку IPv6.

Можно также использовать имя хоста, содержащее только символы ASCII.

Если приложение staticfiles contrib включено (по умолчанию в новых проектах), то команда runserver будет отменена своей собственной командой runserver.

Запись каждого запроса и ответа сервера отправляется в логгер django.server.

--noreload

Отключает автозагрузку. Это означает, что любые изменения кода Python, которые вы делаете во время работы сервера, не вступят в силу, если определенные модули Python уже были загружены в память.

--nothreading

Отключает использование многопоточности в сервере разработки. По умолчанию сервер является многопоточным.

--ipv6, -6

Использует IPv6 для сервера разработки. Это изменяет IP-адрес по умолчанию с 127.0.0.1 на ::1.

Changed in Django 4.0:

Добавлена поддержка опции --skip-checks.

Примеры использования различных портов и адресов

Порт 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).

Это формат вывода по умолчанию.

--plan, -p

Показывает план миграции, которому будет следовать Django для применения миграций. Как и --list, примененные миграции отмечаются символом [X]. При значении --verbosity равном 2 и выше, также будут показаны все зависимости миграции.

app_labels аргументы ограничивают вывод, однако, зависимости предоставляемых приложений также могут быть включены.

--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

Сжимает миграции для app_label до migration_name включительно в меньшее количество миграций, если это возможно. Полученные в результате сплющенные миграции могут спокойно жить рядом с несплющенными. Для получения дополнительной информации, пожалуйста, прочитайте Сжатие миграций.

Если указано 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 для заданного имени приложения в текущем каталоге или в заданном месте назначения.

По умолчанию the new directory содержит файл 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 app:

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/main.zip myapp
--extension EXTENSIONS, -e EXTENSIONS

Указывает, какие расширения файлов в шаблоне приложения должны быть отображены с помощью шаблонизатора. По умолчанию имеет значение py.

--name FILES, -n FILES

Указывает, какие файлы в шаблоне приложения (в дополнение к тем, которые соответствуют --extension) должны быть отрисованы с помощью шаблонизатора. По умолчанию задается пустой список.

--exclude DIRECTORIES, -x DIRECTORIES
New in Django 4.0.

Указывает, какие каталоги в шаблоне приложения должны быть исключены, в дополнение к .git и __pycache__. Если этот параметр не указан, будут исключены каталоги с именем __pycache__ или начинающиеся с ..

Для всех совпадающих файлов используется template context:

  • Любая опция, переданная команде startapp (среди поддерживаемых командой опций)
  • app_name – имя приложения, переданное команде
  • app_directory – полный путь только что созданного приложения
  • camel_case_app_name – имя приложения в формате верблюжьего регистра
  • docs_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 для заданного имени проекта в текущем каталоге или в заданном месте назначения.

По умолчанию the new directory содержит manage.py и пакет проекта (содержащий settings.py и другие файлы).

Если указано только имя проекта, то и каталог проекта, и пакет проекта будут названы <projectname>, а каталог проекта будет создан в текущем рабочем каталоге.

Если указан необязательный пункт назначения, 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) должны быть отрисованы с помощью шаблонизатора. По умолчанию задается пустой список.

--exclude DIRECTORIES, -x DIRECTORIES
New in Django 4.0.

Указывает, какие каталоги в шаблоне проекта должны быть исключены, в дополнение к .git и __pycache__. Если этот параметр не указан, будут исключены каталоги с именем __pycache__ или начинающиеся с ..

Используется template context:

  • Любая опция, переданная команде startproject (среди поддерживаемых командой опций)
  • project_name – имя проекта, переданное команде
  • project_directory – полный путь только что созданного проекта
  • secret_key – случайный ключ для настройки SECRET_KEY
  • docs_version – версия документации: 'dev' или '1.x'
  • django_version – версия Django, например, '2.0.3'

Пожалуйста, посмотрите также rendering warning, как указано для startapp.

test

django-admin test [test_label [test_label ...]]

Запускает тесты для всех установленных приложений. Для получения дополнительной информации см. раздел Тестирование в Django.

--failfast

Прекращает выполнение тестов и сообщает о неудаче сразу после того, как тест не прошел.

--testrunner TESTRUNNER

Управляет классом тестового бегуна, который используется для выполнения тестов. Это значение переопределяет значение, предоставляемое параметром TEST_RUNNER.

--noinput, --no-input

Подавляет все подсказки пользователя. Типичной подсказкой является предупреждение об удалении существующей тестовой базы данных.

Параметры программы тестирования

Команда test получает опции от имени указанного --testrunner. Это опции бегущей строки тестирования по умолчанию: DiscoverRunner.

--keepdb

Сохраняет базу данных тестов между запусками тестов. Преимуществом этого способа является пропуск действий создания и уничтожения, что может значительно сократить время выполнения тестов, особенно в большом наборе тестов. Если база данных тестов не существует, она будет создана при первом запуске и затем будет сохраняться для каждого последующего запуска. Если в настройках теста MIGRATE не указано False, все непримененные миграции также будут применены к тестовой базе данных перед запуском набора тестов.

--shuffle [SEED]
New in Django 4.0.

Случайный порядок тестов перед их выполнением. Это может помочь обнаружить тесты, которые не изолированы должным образом. Порядок тестов, генерируемый этой опцией, является детерминированной функцией заданного целочисленного семени. Если семя не передано, семя выбирается случайным образом и выводится на консоль. Чтобы повторить определенный порядок тестирования, передайте семя. Порядки тестов, генерируемые этой опцией, сохраняют Django’s guarantees on test order. Они также сохраняют группировку тестов по классам тестовых примеров.

Перемешанные упорядочения также обладают особым свойством согласованности, полезным при решении проблем изоляции. А именно, для заданного семпла и при выполнении подмножества тестов новым порядком будет исходная перестановка, ограниченная меньшим набором. Аналогично, при добавлении тестов при неизменном семени порядок исходных тестов будет таким же, как и в новом порядке.

--reverse, -r

Сортирует тестовые случаи в обратном порядке выполнения. Это может помочь в отладке побочных эффектов тестов, которые не были должным образом изолированы. Grouping by test class сохраняется при использовании этой опции. Ее можно использовать в сочетании с --shuffle для изменения порядка для конкретного семпла.

--debug-mode

Устанавливает значение DEBUG в True перед запуском тестов. Это может помочь в устранении сбоев в тестировании.

--debug-sql, -d

Включает SQL logging для провальных тестов. Если --verbosity равно 2, то запросы в проходящих тестах также выводятся.

--parallel [N]
DJANGO_TEST_PROCESSES

Выполняет тесты в отдельных параллельных процессах. Поскольку современные процессоры имеют несколько ядер, это позволяет выполнять тесты значительно быстрее.

Использование --parallel без значения или со значением auto запускает один тестовый процесс на ядро в соответствии с multiprocessing.cpu_count(). Вы можете отменить это, передав желаемое количество процессов, например --parallel 4, или установив переменную окружения DJANGO_TEST_PROCESSES.

Django распределяет тестовые случаи - unittest.TestCase подклассы - по подпроцессам. Если тестовых случаев меньше, чем настроенных процессов, Django соответственно уменьшит количество процессов.

Каждый процесс получает свою собственную базу данных. Вы должны убедиться, что разные тестовые примеры не имеют доступа к одним и тем же ресурсам. Например, тестовые примеры, которые обращаются к файловой системе, должны создать временный каталог для собственного использования.

Примечание

Если у вас есть тестовые классы, которые нельзя запускать параллельно, вы можете использовать SerializeMixin для их последовательного запуска. См. Enforce running test classes sequentially.

Эта опция требует наличия стороннего пакета tblib для корректного отображения трассировок:

$ python -m pip install tblib

Эта функция недоступна в Windows. Она также не работает с бэкендом базы данных Oracle.

Если вы хотите использовать pdb при отладке тестов, вы должны отключить параллельное выполнение (--parallel=1). В противном случае вы увидите что-то вроде bdb.BdbQuit.

Предупреждение

Когда распараллеливание тестов включено и тест не работает, Django может не отобразить трассировку исключения. Это может затруднить отладку. Если вы столкнулись с этой проблемой, запустите соответствующий тест без распараллеливания, чтобы увидеть отслеживание ошибки.

Это известное ограничение. Оно возникает из-за необходимости сериализации объектов для обмена ими между процессами. Подробности см. в What can be pickled and unpickled?.

Changed in Django 4.0:

Добавлена поддержка значения auto.

--tag TAGS

Выполняет только тесты marked with the specified tags. Может указываться несколько раз и комбинироваться с test --exclude-tag.

Тесты, которые не загружаются, всегда считаются подходящими.

Changed in Django 4.0:

В старых версиях тесты, которые не загружались, не соответствовали тегам.

--exclude-tag EXCLUDE_TAGS

Исключает тесты marked with the specified tags. Может указываться несколько раз и комбинироваться с test --tag.

-k TEST_NAME_PATTERNS

Запускает тестовые методы и классы, соответствующие шаблонам имен тестов, так же, как и unittest's -k option. Может быть указано несколько раз.

--pdb

Порождает отладчик pdb при каждой ошибке или сбое теста. Если он уже установлен, вместо него используется ipdb.

--buffer, -b

Отбрасывает вывод (stdout и stderr) при прохождении тестов, аналогично unittest's --buffer option.

--no-faulthandler

Django автоматически вызывает faulthandler.enable() при запуске тестов, что позволяет ему вывести traceback в случае сбоя интерпретатора. Передайте --no-faulthandler, чтобы отключить это поведение.

--timing

Выводит временные показатели, включая настройку базы данных и общее время работы.

testserver

django-admin testserver [fixture [fixture ...]]

Запускает сервер разработки Django (как в runserver), используя данные из заданного приспособления (приспособлений).

Например, эта команда:

django-admin testserver mydata.json

…выполнить следующие действия:

  1. Создайте тестовую базу данных, как описано в разделе Тестовая база данных.
  2. Заполнить базу данных тестов данными о приспособлениях из заданных приспособлений. (Подробнее о приспособлениях см. документацию для loaddata выше).
  3. Запускает сервер разработки Django (как в runserver), направленный на эту недавно созданную тестовую базу данных вместо вашей производственной базы данных.

Это полезно в нескольких отношениях:

  • Когда вы пишете unit tests о том, как ваши представления действуют с определенными данными приспособления, вы можете использовать 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, которое implements их выполняет, было enabled. В этом разделе они описаны сгруппированными по их применению.

django.contrib.auth

changepassword

django-admin changepassword [<username>]

Эта команда доступна только в случае установки authentication system (django.contrib.auth) Django.

Позволяет изменить пароль пользователя. Предлагается дважды ввести новый пароль для данного пользователя. Если они одинаковы, то этот пароль сразу же становится новым. Если пользователь не указан, команда попытается изменить пароль пользователя, имя которого совпадает с именем текущего пользователя.

--database DATABASE

Указывает базу данных для запроса пользователя. По умолчанию имеет значение default.

Пример использования:

django-admin changepassword ringo

createsuperuser

django-admin createsuperuser
DJANGO_SUPERUSER_PASSWORD

Эта команда доступна только в случае установки authentication system (django.contrib.auth) Django.

Создает учетную запись суперпользователя (пользователя, обладающего всеми правами). Это полезно, если вам нужно создать начальную учетную запись суперпользователя или если вам нужно программно генерировать учетные записи суперпользователей для вашего сайта (сайтов).

При интерактивном запуске эта команда запросит пароль для новой учетной записи суперпользователя. При неинтерактивном запуске вы можете задать пароль, установив переменную окружения DJANGO_SUPERUSER_PASSWORD. В противном случае пароль не будет установлен, и учетная запись суперпользователя не сможет войти в систему, пока пароль не будет установлен для нее вручную.

В неинтерактивном режиме поля USERNAME_FIELD и обязательные поля (перечисленные в REQUIRED_FIELDS) возвращаются к переменным среды DJANGO_SUPERUSER_<uppercase_field_name>, если они не переопределены аргументом командной строки. Например, чтобы обеспечить поле email, можно использовать переменную окружения DJANGO_SUPERUSER_EMAIL.

--noinput, --no-input

Подавляет все подсказки пользователя. Если подавленная подсказка не может быть разрешена автоматически, команда завершается с кодом ошибки 1.

--username USERNAME
--email EMAIL

Имя пользователя и адрес электронной почты для новой учетной записи можно указать с помощью аргументов --username и --email в командной строке. Если ни один из этих аргументов не указан, --email запросит их при интерактивном запуске.

--database DATABASE

Указывает базу данных, в которую будет сохранен объект суперпользователя.

Вы можете подклассифицировать команду управления и переопределить get_input_data(), если хотите настроить ввод и проверку данных. За подробностями о существующей реализации и параметрах метода обратитесь к исходному коду. Например, это может быть полезно, если у вас есть ForeignKey в REQUIRED_FIELDS и вы хотите разрешить создание экземпляра вместо ввода первичного ключа существующего экземпляра.

django.contrib.contenttypes

remove_stale_contenttypes

django-admin remove_stale_contenttypes

Эта команда доступна только в случае установки contenttypes app (django.contrib.contenttypes) Django.

Удаляет устаревшие типы содержимого (из удаленных моделей) в вашей базе данных. Любые объекты, зависящие от удаленных типов содержимого, также будут удалены. Список удаленных объектов будет отображен до того, как вы подтвердите, что удаление разрешено.

--database DATABASE

Указывает базу данных для использования. По умолчанию имеет значение default.

--include-stale-apps

Удаляет устаревшие типы содержимого, в том числе из ранее установленных приложений, которые были удалены из INSTALLED_APPS. По умолчанию установлено значение False.

django.contrib.gis

ogrinspect

Эта команда доступна только в том случае, если установлен GeoDjango (django.contrib.gis).

Пожалуйста, обратитесь к его description в документации GeoDjango.

django.contrib.sessions

clearsessions

django-admin clearsessions

Может быть запущен как задание cron или напрямую для очистки истекших сессий.

django.contrib.sitemaps

ping_google

Эта команда доступна только при установленном Sitemaps framework (django.contrib.sitemaps).

Пожалуйста, обратитесь к его description в документации Sitemaps.

django.contrib.staticfiles

collectstatic

Эта команда доступна только при установленном static files application (django.contrib.staticfiles).

Пожалуйста, обратитесь к его description в документации staticfiles.

findstatic

Эта команда доступна только при установленном static files application (django.contrib.staticfiles).

Пожалуйста, обратитесь к его description в документации staticfiles.

Параметры по умолчанию

Хотя некоторые команды могут допускать свои собственные опции, каждая команда по умолчанию допускает следующие опции:

--pythonpath PYTHONPATH

Добавляет заданный путь к файловой системе в Python import search path. Если он не указан, 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 и полную трассировку стека при любом другом исключении.

Эта опция игнорируется runserver.

Пример использования:

django-admin migrate --traceback
--verbosity {0,1,2,3}, -v {0,1,2,3}

Определяет количество уведомлений и отладочной информации, которую команда должна выводить на консоль.

  • 0 означает отсутствие вывода.
  • 1 означает нормальный вывод (по умолчанию).
  • 2 означает подробный вывод.
  • 3 означает очень подробный вывод.

Эта опция игнорируется runserver.

Пример использования:

django-admin migrate --verbosity 2
--no-color

Отключает цветной вывод команд. Некоторые команды форматируют свой вывод так, чтобы он был окрашен. Например, ошибки будут выводиться на консоль красным цветом, а операторы SQL будут выделены синтаксисом.

Пример использования:

django-admin runserver --no-color
--force-color

Принудительное окрашивание вывода команды, если в противном случае оно было бы отключено, как обсуждалось в Синтаксическая раскраска. Например, вы можете захотеть передать цветной вывод другой команде.

--skip-checks

Пропускает выполнение системных проверок перед выполнением команды. Эта опция доступна, только если атрибут команды requires_system_checks не является пустым списком или кортежем.

Пример использования:

django-admin migrate --skip-checks

Дополнительные приятности

Синтаксическая раскраска

DJANGO_COLORS

Команды django-admin / manage.py будут использовать красивую цветовую кодировку вывода, если ваш терминал поддерживает цветной вывод ANSI. Она не будет использовать цветовые коды, если вы передаете вывод команды в другую программу, если не используется опция --force-color.

Поддержка Windows

В Windows 10 приложения Windows Terminal, VS Code и PowerShell (где включена обработка виртуального терминала) допускают цветной вывод и поддерживаются по умолчанию.

В Windows устаревшая родная консоль cmd.exe не поддерживает управляющие последовательности ANSI, поэтому по умолчанию цветной вывод отсутствует. В этом случае требуется одна из двух сторонних библиотек:

  • Установите colorama, пакет Python, который переводит цветовые коды ANSI в вызовы Windows API. Команды Django обнаружат его присутствие и будут использовать его сервисы для цветового оформления вывода, как на платформах на базе Unix. colorama может быть установлен через pip:

    ...\> py -m pip install colorama

  • Установите ANSICON, инструмент стороннего производителя, который позволяет cmd.exe обрабатывать цветовые коды ANSI. Команды Django обнаружат его присутствие и будут использовать его сервисы для раскраски вывода, как на платформах на базе Unix.

Другие современные терминальные среды в Windows, которые поддерживают цвета терминала, но которые не определяются автоматически как поддерживаемые Django, могут «сымитировать» установку ANSICON, установив соответствующую переменную окружения ANSICON="on".

Пользовательские цвета

Цвета, используемые для подсветки синтаксиса, можно настраивать. Django поставляется с тремя цветовыми палитрами:

  • dark, подходит для терминалов, отображающих белый текст на черном фоне. Это палитра по умолчанию.
  • light, подходит для терминалов, которые показывают черный текст на белом фоне.
  • nocolor, который отключает подсветку синтаксиса.

Вы выбираете палитру, устанавливая переменную окружения DJANGO_COLORS, чтобы указать палитру, которую вы хотите использовать. Например, чтобы задать палитру light в оболочке BASH под Unix или OS/X, в командной строке нужно выполнить следующее:

export DJANGO_COLORS="light"

Вы также можете настроить используемые цвета. Django определяет ряд ролей, в которых используется цвет:

  • error - Крупная ошибка.
  • notice - Незначительная ошибка.
  • success - Успех.
  • warning - Предупреждение.
  • sql_field - Имя поля модели в SQL.
  • sql_coltype - Тип поля модели в SQL.
  • sql_keyword - Ключевое слово SQL.
  • sql_table - Имя модели в SQL.
  • http_info - Ответ сервера 1XX HTTP Informational.
  • http_success - Ответ сервера 2XX HTTP Success.
  • http_not_modified - Ответ сервера 304 HTTP Not Modified.
  • http_redirect - Ответ сервера 3XX HTTP Redirect, отличный от 304.
  • http_not_found - Ответ сервера 404 HTTP Not Found.
  • http_bad_request - Ответ сервера 4XX HTTP Bad Request, отличный от 404.
  • http_server_error - Ответ 5XX HTTP Server Error.
  • 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.

Черное форматирование

New in Django 4.1.

Файлы Python, созданные командами startproject, startapp, optimizemigration, makemigrations и squashmigrations, форматируются с помощью команды black, если она присутствует на вашем PATH.

Если у вас глобально установлен black, но вы не хотите, чтобы он использовался для текущего проекта, вы можете установить PATH явно:

PATH=path/to/venv/bin django-admin makemigrations

Для команд, использующих stdout, при необходимости можно передать вывод в black:

django-admin inspectdb | black -

Выполнение команд управления из вашего кода

django.core.management.call_command(name, *args, **options)

Для вызова команды управления из кода используйте 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)
Базы данных
Исключения Django
Вернуться на верх