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.django-admin version

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

1.4.dev17026
1.4a1
1.4

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

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

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

check

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

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

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

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

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

django-admin check --tag models --tag compatibility
--database DATABASE
Новое в Django 3.1.

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

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

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

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

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
Новое в Django 3.1.

Любые аргументы, следующие за --разделителем, будут переданы базовому клиенту командной строки. Например, с PostgreSQL вы можете использовать psql командование -cфлаг для выполнения необработанного запроса SQL непосредственно:

$ django-admin dbshell -- -c 'select current_user'
 current_user
--------------
 postgres
(1 row)

...\> django-admin dbshell -- -c 'select current_user'
 current_user
--------------
 postgres
(1 row)

На MySQL / MariaDB, вы можете сделать это с помощью mysqlкомандования -eфлага:

$ django-admin dbshell -- -e "select user()"
+----------------------+
| user()               |
+----------------------+
| [email protected] |
+----------------------+

...\> django-admin dbshell -- -e "select user()"
+----------------------+
| user()               |
+----------------------+
| [email protected] |
+----------------------+

Примечание

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

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

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

--pks PRIMARY_KEYS

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

--output OUTPUT, -o OUTPUT

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

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

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

Новое в Django 3.2.

Выходной файл может быть сжат с одним из 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 рядом с полем в сгенерированной модели. Распознаваемые поля могут зависеть от приложений, перечисленных в . Например, добавляет распознавание для нескольких типов полей, специфичных для PostgreSQL.'This field type is a guess.'INSTALLED_APPSdjango.contrib.postgres
  • Если имя столбца базы данных является зарезервированным словом 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поле модели указано a. Точно так же значения по умолчанию для базы данных не преобразуются в значения по умолчанию для полей модели и не обнаруживаются каким-либо образом с помощью inspectdb.

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

Примечания к базе данных

Оракул
  • Модели создаются для материализованных представлений, если они --include-viewsиспользуются.
PostgreSQL
  • Созданы модели для сторонних таблиц.
  • Модели создаются для материализованных представлений, если они --include-viewsиспользуются.
  • Модели создаются для таблиц разделов, если они --include-partitionsиспользуются.
--database DATABASE

Задает базу данных для самоанализа. По умолчанию default.

--include-partitions

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

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

--include-views

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

loaddata

django-admin loaddata fixture [fixture ...]

Ищет и загружает содержимое названного прибора в базу данных.

--database DATABASE

Задает базу данных, в которую будут загружены данные. По умолчанию default.

--ignorenonexistent, -i

Игнорирует поля и модели, которые могли быть удалены с момента создания прибора.

--app APP_LABEL

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

--format FORMAT

Задает формат сериализации (например, jsonили xml) для фикстур, считываемых из stdin .

--exclude EXCLUDE, -e EXCLUDE

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

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

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

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

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

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

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

django-admin loaddata mydata.json

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

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

django-admin loaddata mydata

искал бы любое приспособление любого названного типа приспособления mydata. Если каталог фикстур содержался mydata.json, то этот фикстур был бы загружен как фикстур JSON.

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

django-admin loaddata foo/bar/mydata.json

будет искать <app_label>/fixtures/foo/bar/mydata.jsonкаждое установленное приложение, <dirname>/foo/bar/mydata.jsonкаждый каталог в FIXTURE_DIRSи буквальный путь foo/bar/mydata.json.

При обработке файлов фикстур данные сохраняются в базе данных как есть. save()Методы, определенные моделью , не вызываются, и будут вызываться любые сигналы pre_saveили, поскольку экземпляр содержит только атрибуты, которые являются локальными для модели. Например, вы можете отключить обработчики, которые обращаются к связанным полям, которые отсутствуют во время загрузки фикстуры, и в противном случае могут вызвать исключение:post_saveraw=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, вы не получите проверки данных фикстуры или отката, если будет найдено несколько файлов транзакций.

Изменено в Django 3.2:

Добавлена поддержка архивов XZ ( .xz) и архивов LZMA ( .lzma).

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

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

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

Загрузка светильников из stdin

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

django-admin loaddata --format=json -

При чтении с stdin, то --formatопция требуется указать формат сериализации на входе (например, jsonили xml).

Загрузка из stdinполезна со стандартными перенаправлениями ввода и вывода. Например:

django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -

makemessages

django-admin makemessages

Обходит все исходное дерево текущего каталога и извлекает все строки, отмеченные для перевода. Он создает (или обновляет) файл сообщения в каталоге conf / locale (в дереве Django) или locale (для проекта и приложения). После внесения изменений в файлы сообщений вам необходимо скомпилировать их compilemessagesдля использования со встроенной поддержкой gettext. Подробности см. В документации i18n .

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

Требуется версия gettext0.19 или новее.

--keep-pot

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

Смотрите также

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

makemigrations

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

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

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

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

--noinput, --no-input

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

--empty

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

--dry-run

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

--merge

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

--name NAME, -n NAME

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

--no-header

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

--check

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

Изменено в Django 3.2:

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

migrate

django-admin migrate [app_label] [migration_name]

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

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

  • Без аргументов: у всех приложений все миграции выполняются.
  • <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
Новое в Django 3.1.

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

runserver

django-admin runserver [addrport]

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

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

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

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

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

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

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

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

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

DJANGO_WATCHMAN_TIMEOUT

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

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

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

Обратите внимание, что IP-адрес по умолчанию 127.0.0.1недоступен с других компьютеров в вашей сети. Чтобы сделать ваш сервер разработки доступным для просмотра на других машинах в сети, используйте его собственный IP-адрес (например 192.168.2.1) или 0.0.0.0или ::(с включенным IPv6).

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

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

Если приложение staticfiles 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

Отправляет электронные сообщения на адреса электронной почты, указанные в MANAGERSusing mail_managers().

--admins

Отправляет электронные сообщения на адреса электронной почты, указанные в ADMINSusing 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_labelАргументы s ограничивают вывод, однако также могут быть включены зависимости предоставленных приложений.

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

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

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

Например:

django-admin startapp myapp /Users/jezdez/Code/myapp
--template TEMPLATE

Предоставляет путь к папке с файлом шаблона пользовательских приложений, или путь к несжатого архива ( .tar) или сжатого архива ( .tar.gz, .tar.bz2, .tar.xz, .tar.lzma, .tgz, .tbz2, .txz, .tlz, .zip) , содержащий файлы шаблонов приложений.

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

django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp

Джанго также будет принимать 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 содержит строку документации, объясняющую конкретную функцию, связанную с отрисовкой шаблона, это может привести к неверному примеру.

Чтобы обойти эту проблему, вы можете использовать templatetag тег шаблона для «экранирования» различных частей синтаксиса шаблона.

Кроме того, чтобы разрешить файлы шаблонов Python, содержащие синтаксис языка шаблонов Django, а также предотвратить попытки систем упаковки компилировать недопустимые *.pyфайлы, файлы шаблонов, заканчивающиеся на, .py-tpl будут переименованы в .py.

startproject

django-admin startproject name [directory]

Создает структуру каталогов проекта Django для данного имени проекта в текущем каталоге или в указанном месте назначения.

По умолчанию новый каталог содержит manage.pyи пакет проекта (содержащий a 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'

См. Также предупреждение о рендеринге, указанное для startapp.

test

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

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

--failfast

Останавливает выполнение тестов и сообщает о сбое сразу после сбоя теста.

--testrunner TESTRUNNER

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

--noinput, --no-input

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

Параметры тестового запуска

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

--keepdb

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

--reverse, -r

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

--debug-mode

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

--debug-sql, -d

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

--parallel [N]
DJANGO_TEST_PROCESSES

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

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

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

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

Примечание

Если у вас есть тестовые классы, которые нельзя запускать параллельно, вы можете использовать SerializeMixinих для последовательного запуска. См. Раздел Принудительное выполнение тестовых классов последовательно .

Эта опция требует, чтобы сторонний tblibпакет правильно отображал трассировку:

$ python -m pip install tblib

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

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

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

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

Это известное ограничение. Это возникает из-за необходимости сериализации объектов, чтобы обмениваться ими между процессами. См. Что можно мариновать и не мариновать? для подробностей.

--tag TAGS

Запускает только тесты, отмеченные указанными тегами . Можно указывать несколько раз и сочетать с .test --exclude-tag

--exclude-tag EXCLUDE_TAGS

Исключает тесты, отмеченные указанными тегами . Можно указывать несколько раз и сочетать с .test --tag

-k TEST_NAME_PATTERNS

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

Python 3.7 и новее

Эта функция доступна только для Python 3.7 и новее.

--pdb

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

--buffer, -b
Новое в Django 3.1.

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

--no-faulthandler
Новое в Django 3.2.

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

--timing
Новое в Django 3.2.

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

testserver

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

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

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

django-admin testserver mydata.json

… Будет выполнять следующие шаги:

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

Это полезно по-разному:

  • Когда вы пишете модульные тесты того, как ваши представления действуют с определенными данными фикстур, вы можете использовать их testserverдля взаимодействия с представлениями в веб-браузере вручную.
  • Допустим, вы разрабатываете свое приложение Django и имеете «чистую» копию базы данных, с которой хотите взаимодействовать. Вы можете выгрузить свою базу данных в прибор (используя dumpdataкоманду, описанную выше), а затем использовать ее testserverдля запуска вашего веб-приложения с этими данными. Благодаря такому расположению у вас есть возможность испортить ваши данные любым способом, зная, что любые изменения данных, которые вы вносите, вносятся только в тестовую базу данных.

Обратите внимание , что этот сервер не не автоматически обнаруживает изменения в исходном коде Python (как runserverделает). Однако он обнаруживает изменения в шаблонах.

--addrport ADDRPORT

Задает порт или IP-адрес и порт, отличный от значения по умолчанию 127.0.0.1:8000. Это значение соответствует точно такому же формату и выполняет ту же функцию, что и аргумент runserverкоманды.

Примеры:

Чтобы запустить тестовый сервер на порту 7000 с помощью fixture1и fixture2:

django-admin testserver --addrport 7000 fixture1 fixture2
django-admin testserver fixture1 fixture2 --addrport 7000

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

Чтобы запустить 1.2.3.4:7000 с testприспособлением:

django-admin testserver --addrport 1.2.3.4:7000 test
--noinput, --no-input

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

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

Некоторые команды доступны только тогда, когда django.contribприложение, реализующее их, было enabled. В этом разделе они описаны, сгруппированные по их применению.

django.contrib.auth

changepassword

django-admin changepassword [<username>]

Эта команда доступна, только если установлена система аутентификации Django ( django.contrib.auth).

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

--database DATABASE

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

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

django-admin changepassword ringo

createsuperuser

django-admin createsuperuser
DJANGO_SUPERUSER_PASSWORD

Эта команда доступна, только если установлена система аутентификации Django ( django.contrib.auth).

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

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

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

--noinput, --no-input

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

--username USERNAME
--email EMAIL

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

--database DATABASE

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

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

django.contrib.contenttypes

remove_stale_contenttypes

django-admin remove_stale_contenttypes

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

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

--database DATABASE

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

--include-stale-apps
Новое в Django 3.1.

Удаляет устаревшие типы контента, в том числе из ранее установленных приложений, которые были удалены из 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 ( django.contrib.sitemaps).

См. Его descriptionв документации по файлам Sitemap.

django.contrib.staticfiles

collectstatic

Эта команда доступна, только если установлено приложение статических файлов ( django.contrib.staticfiles).

См. Его descriptionв документации по статическим файлам .

findstatic

Эта команда доступна, только если установлено приложение статических файлов ( django.contrib.staticfiles).

См. Его descriptionв документации по статическим файлам .

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

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

--pythonpath PYTHONPATH

Добавляет указанный путь файловой системы к пути поиска импорта Python . Если это не предусмотрено, django-adminбудет использоватьсяPYTHONPATH переменная окружения.

В этой опции нет необходимости manage.py, потому что она устанавливает путь Python за вас.

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

django-admin migrate --pythonpath='/home/djangoprojects/myproject'
--settings SETTINGS

Задает используемый модуль настроек. Модуль настроек должен быть в синтаксисе пакета Python, например mysite.settings. Если это не предусмотрено, django-adminбудет использоватьсяDJANGO_SETTINGS_MODULE переменная окружения.

В этом параметре нет необходимости manage.py, поскольку он settings.pyпо умолчанию использует из текущего проекта.

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

django-admin migrate --settings=mysite.settings
--traceback

Отображает полную трассировку стека, когда CommandError поднимается. По умолчанию django-adminпри возникновении ошибки отображается сообщение об ошибке CommandErrorи полная трассировка стека для любого другого исключения.

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

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

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

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

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

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

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

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

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

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

--skip-checks

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

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

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собственная консоль не поддерживает escape-последовательности 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 3.2:

Обновлена ​​поддержка раскраски синтаксиса в Windows.

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

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

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

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

export DJANGO_COLORS="light"

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

  • error - Крупная ошибка.
  • notice - Незначительная ошибка.
  • success - Успех.
  • warning - Предупреждение.
  • sql_field - Имя поля модели в SQL.
  • sql_coltype - Тип поля модели в SQL.
  • sql_keyword - Ключевое слово SQL.
  • sql_table - Название модели в SQL.
  • http_info - Ответ информационного сервера HTTP 1XX.
  • http_success - Ответ сервера 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( имя , * аргументы , ** параметры )

Для вызова команды управления из кода используйте 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-inputcall_command('createsuperuser', interactive=False)call_command()destparser.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 Docs

Copyright ©2021 All rights reserved