`django-admin` и `manage.py`¶

django-admin - это утилита командной строки Django для выполнения административных задач. В этом документе описано все, что она может делать.

Кроме того, manage.py автоматически создается в каждом проекте Django. Он делает то же самое, что и django-admin, но также устанавливает переменную окружения DJANGO_SETTINGS_MODULE так, чтобы она указывала на файл settings.py вашего проекта.

Скрипт django-admin должен быть в вашем системном пути, если вы установили Django через pip. Если его нет на вашем пути, вы можете найти его в site-packages/django/bin в вашей установке Python. Рассмотрите возможность симлинка его из какого-нибудь места на вашем пути, например, /usr/local/bin.

Для пользователей Windows, которым недоступна функция симлинкинга, вы можете скопировать django-admin.exe в место в существующем пути или отредактировать настройки PATH (в разделе Settings - Control Panel - System - Advanced - Environment...), чтобы указать на его установленное место.

Как правило, при работе над одним проектом 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:

4.dev17026
4a1
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

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

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

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

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

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

Примечание

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

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

Changed in Django 2.2:

Добавлена поддержка внешних таблиц и материализованных представлений.

--database DATABASE¶

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

--include-partitions¶

New in Django 2.2.

Если этот параметр указан, модели создаются и для разделов.

Реализована поддержка только PostgreSQL.

--include-views¶

New in Django 2.1.

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

`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 будет искать светильники в трех местах:

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

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. Например:

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 и креплениями

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

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

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

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

Загрузка приспособлений из `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

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

Управляет строками комментариев #: 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¶

New in Django 2.2.

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

--check¶

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

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

New in Django 2.2.

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

--run-syncdb¶

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

--noinput, --no-input¶

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

`runserver`¶

django-admin runserver [addrport]¶

Запускает легкий Web-сервер разработки на локальной машине. По умолчанию сервер запускается на порту 8000 на IP-адресе 127.0.0.1. Вы можете передать IP-адрес и номер порта в явном виде.

Если вы запускаете этот сценарий от имени пользователя с обычными привилегиями (рекомендуется), у вас может не быть доступа к запуску порта с низким номером порта. Низкие номера портов зарезервированы для суперпользователя (root).

Этот сервер использует объект приложения WSGI, указанный параметром WSGI_APPLICATION.

НЕ ИСПОЛЬЗУЙТЕ ЭТОТ СЕРВЕР В ПРОИЗВОДСТВЕННЫХ УСЛОВИЯХ. Он не проходил аудита безопасности или тестов производительности. (И так оно и останется. Мы занимаемся созданием веб-фреймворков, а не веб-серверов, поэтому улучшение этого сервера для работы в производственной среде выходит за рамки Django).

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

Если вы используете Linux или MacOS и установили как pywatchman, так и службу Watchman, для автозагрузки сервера будут использоваться сигналы ядра (вместо ежесекундного опроса временных меток модификации файлов). Это позволяет повысить производительность больших проектов, уменьшить время отклика после изменения кода, повысить надежность обнаружения изменений и снизить энергопотребление.

Большие каталоги с большим количеством файлов могут вызвать проблемы с производительностью

При использовании Watchman с проектом, включающим большие не-Python каталоги, такие как node_modules, рекомендуется игнорировать этот каталог для оптимальной производительности. Смотрите watchman documentation для получения информации о том, как это сделать.

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

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

Changed in Django 2.2:

Поддержка Watchman заменила поддержку pyinotify.

Когда вы запускаете сервер, и каждый раз, когда вы изменяете код Python во время работы сервера, фреймворк system check будет проверять весь ваш проект 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 contrib включено (по умолчанию в новых проектах), то команда 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] рядом с именем миграции).

Приложения без миграций также перечислены, но под ними напечатано (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¶

New in Django 2.2.

Создайте сплющенный файл миграции без заголовка версии 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.gz, .tar.bz2, .tgz, .tbz, .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/master.zip myapp

--extension EXTENSIONS, -e EXTENSIONS¶

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

--name FILES, -n FILES¶

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

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

Используется 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, -k¶

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

--reverse, -r¶

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

--debug-mode¶

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

--debug-sql, -d¶

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

--parallel [N]¶

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

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

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

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

Примечание

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

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

$ pip install tblib

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

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

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

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

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

--tag TAGS¶

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

--exclude-tag EXCLUDE_TAGS¶

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

`testserver`¶

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

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

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

django-admin testserver mydata.json

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

Создайте тестовую базу данных, как описано в разделе Тестовая база данных.
Заполнить базу данных тестов данными о приспособлениях из заданных приспособлений. (Подробнее о приспособлениях см. документацию для loaddata выше).
Запускает сервер разработки 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¶

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

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

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

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

`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 и полную трассировку стека при любом другом исключении.

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

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¶

New in Django 2.2.

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

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

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

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

Под Windows родная консоль не поддерживает ANSI escape-последовательности, поэтому по умолчанию цветной вывод отсутствует. Но вы можете установить сторонний инструмент 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 - Ответ сервера 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.

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

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

Вернуться на верх

django-admin и manage.py¶

Использование¶

Получение помощи во время выполнения¶

Названия приложений¶

Определение версии¶

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

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

check¶

compilemessages¶

createcachetable¶

dbshell¶

diffsettings¶

dumpdata¶

flush¶

inspectdb¶

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

Oracle¶

PostgreSQL¶

loaddata¶

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

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

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

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

makemessages¶

makemigrations¶

migrate¶

runserver¶

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

Обслуживание статических файлов с помощью сервера разработки¶

sendtestemail¶

shell¶

showmigrations¶

sqlflush¶

sqlmigrate¶

sqlsequencereset¶

squashmigrations¶

startapp¶

startproject¶

test¶

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

testserver¶

Команды, предоставляемые приложениями¶

django.contrib.auth¶

changepassword¶

createsuperuser¶

django.contrib.contenttypes¶

remove_stale_contenttypes¶

django.contrib.gis¶

ogrinspect¶

django.contrib.sessions¶

clearsessions¶

django.contrib.sitemaps¶

ping_google¶

django.contrib.staticfiles¶

collectstatic¶

findstatic¶

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

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

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

Завершение Bash¶

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

Перенаправление выхода¶

Django 2.2

Содержание

Дополнительно

Вы здесь:

`django-admin` и `manage.py`¶

`check`¶

`compilemessages`¶

`createcachetable`¶

`dbshell`¶

`diffsettings`¶

`dumpdata`¶

`flush`¶

`inspectdb`¶

`loaddata`¶

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

`makemessages`¶

`makemigrations`¶

`migrate`¶

`runserver`¶

`sendtestemail`¶

`shell`¶

`showmigrations`¶

`sqlflush`¶

`sqlmigrate`¶

`sqlsequencereset`¶

`squashmigrations`¶

`startapp`¶

`startproject`¶

`test`¶

`testserver`¶

`django.contrib.auth`¶

`changepassword`¶

`createsuperuser`¶

`django.contrib.contenttypes`¶

`remove_stale_contenttypes`¶

`django.contrib.gis`¶

`ogrinspect`¶

`django.contrib.sessions`¶

`clearsessions`¶

`django.contrib.sitemaps`¶

`ping_google`¶

`django.contrib.staticfiles`¶

`collectstatic`¶

`findstatic`¶