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

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

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

django-admin Сценарий должен быть в вашем системном пути , если вы установили Django с помощью pip . Если это не на вашем пути, убедитесь, что ваша виртуальная среда активирована.

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

Примеры командной строки в этом документе используются django-admin для единообразия, но во всех примерах так же легко можно использовать manage.py или .python -m django

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

 /  

$ django-admin <command> [options]
$ manage.py <command> [options]
$ python -m django <command> [options]

...\> django-admin <command> [options]
...\> manage.py <command> [options]
...\> py -m django <command> [options]

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

Получение помощи ¶

django-admin help¶

Запустите, чтобы просмотреть информацию об использовании и список команд, предоставляемых каждым приложением.django-admin help

Запустить, чтобы отобразить список доступных команд.django-admin help --commands

Запустить, чтобы отобразить описание затронутой команды и список ее доступных параметров.django-admin help <command>

Имена приложений ¶

Некоторые команды принимают список «имен приложений». Имя приложения - это базовое имя пакета, содержащего модели. Например, если ваш параметр INSTALLED_APPS содержит строку 'mysite.blog' , имя приложения будет blog .

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

django-admin version¶

Запустите, чтобы просмотреть текущую версию Django.django-admin version

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

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

Новое в Django 3.0.

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

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

django-admin compilemessages --ignore=cache --ignore=outdated/*/locale

`createcachetable` ¶

django-admin createcachetable¶

Создает таблицы кэша для использования механизмом кеширования базы данных с использованием информации из файла настроек. Дополнительную информацию см. В разделе Инфраструктура кеширования в Django .

--database DATABASE¶

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

--dry-run¶

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

`dbshell` ¶

django-admin dbshell¶

Запускает соответствующую команду онлайн-клиента для механизма базы данных, указанного в настройках ENGINE , с учетом настроек подключения, определенных в настройках USER , PASSWORD и т. Д.

Для PostgreSQL эта команда запускает клиент командной строки psql .
Для MySQL эта команда запускает клиент командной строки mysql .
Для SQLite эта команда запускает клиент командной строки sqlite3 .
Для Oracle эта команда запускает клиент командной строки sqlplus .

Эта команда опирается на тот факт , что программы доступны на пути выполнения , так что, называя свое имя ( psql , mysql , sqlite3 , sqlplus ), правильная программа запущена. Нет никакого трюка, чтобы вручную указать путь к программе базы данных.

--database DATABASE¶

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

-- ARGUMENTS¶

Новое в 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¶

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

--exclude EXCLUDE, -e EXCLUDE¶

Запрещает étiquette_app.NomModèle отображение определенных приложений или моделей (обозначенных как ). Если вы укажете название модели, отображение продукта будет ограничено этой моделью, а не всем приложением. Также возможно смешивать названия приложений и названия моделей.

Чтобы исключить несколько приложений, укажите несколько раз --exclude :

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

--database DATABASE¶

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

--natural-foreign¶

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

--natural-primary¶

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

--pks PRIMARY_KEYS¶

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

--output OUTPUT, -o OUTPUT¶

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

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

`flush` ¶

django-admin flush¶

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

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

--noinput, --no-input¶

Избегайте каких-либо интерактивных запросов к пользователю.

--database DATABASE¶

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

`inspectdb` ¶

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

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

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

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

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

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

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

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

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

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

Оракул ¶

Шаблоны создаются для материализованных представлений, если --include-views указана опция .

PostgreSQL ¶

Шаблоны созданы для сторонних таблиц.
Шаблоны создаются для материализованных представлений, если --include-views указана опция .
Шаблоны создаются для таблиц разделов, если --include-partitions указана опция .

--database DATABASE¶

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

--include-partitions¶

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

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

--include-views¶

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

`loaddata` ¶

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

Находит и загружает содержимое указанного снимка в базу данных.

--database DATABASE¶

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

--ignorenonexistent, -i¶

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

--app APP_LABEL¶

Назначает одно приложение для поиска снимков вместо поиска по всем приложениям.

--format FORMAT¶

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

--exclude EXCLUDE, -e EXCLUDE¶

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

Что такое «снимок» (приспособление на английском языке)? ¶

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

Django ищет снимки в трех местах:

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

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

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

django-admin loaddata mydata.json

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

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

django-admin loaddata mydata

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

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

django-admin loaddata foo/bar/mydata.json

поиск <étiquette_app>/fixtures/foo/bar/mydata.json каждого установленного приложения, <nom_rép>/foo/bar/mydata.json каждого каталога в, а FIXTURE_DIRS также буквального пути foo/bar/mydata.json .

При обработке файлов моментальных снимков данные сохраняются в базе данных. Методы, save() определенные в моделях, не вызываются и никакие сигналы pre_save или post_save вызываются с помощью, raw=True потому что экземпляр содержит только локальные атрибуты модели. Например, можно деактивировать менеджеров, обращающихся к отсутствующим связанным полям при загрузке снимков, потому что в противном случае будет сгенерировано исключение:

from django.db.models.signals import post_save
from .models import MyModel

def my_handler(**kwargs):
    # disable the handler during fixture loading
    if kwargs['raw']:
        return
    ...

post_save.connect(my_handler, sender=MyModel)

Мы также могли бы написать декоратор для инкапсуляции этой логики:

from functools import wraps

def disable_for_loaddata(signal_handler):
    """
    Decorator that turns off signal handlers when loading fixture data.
    """
    @wraps(signal_handler)
    def wrapper(*args, **kwargs):
        if kwargs['raw']:
            return
        signal_handler(*args, **kwargs)
    return wrapper

@disable_for_loaddata
def my_handler(**kwargs):
    ...

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

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

Команду dumpdata можно использовать для создания содержимого, предоставленного loaddata .

Сжатые снимки ¶

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

django-admin loaddata mydata.json

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

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

MySQL с MyISAM и снимками

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

Снимки, относящиеся к определенным базам данных ¶

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

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

Загрузка снимков из `stdin` ¶

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

django-admin loaddata --format=json -

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

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

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

`makemessages` ¶

django-admin makemessages¶

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

Эта команда не запрашивает никаких настроенных параметров. Однако, если параметры не настроены, команда не может игнорировать MEDIA_ROOT и / STATIC_ROOT или включать каталоги LOCALE_PATHS .

--all, -a¶

Обновляет файлы сообщений для всех доступных языков.

--extension EXTENSIONS, -e EXTENSIONS¶

Указывает список расширений файлов для изучения ( по умолчанию: html , txt , py или , js если --domain есть js ).

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

django-admin makemessages --locale=de --extension xhtml

Разделите несколько расширений запятыми или используйте несколько вхождений -e или --extension :

django-admin makemessages --locale=de --extension=html,txt --extension xml

--locale LOCALE, -l LOCALE¶

Задает языки для обработки.

--exclude EXCLUDE, -x EXCLUDE¶

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

django-admin makemessages --locale=pt_BR
django-admin makemessages --locale=pt_BR --locale=fr
django-admin makemessages -l pt_BR
django-admin makemessages -l pt_BR -l fr
django-admin makemessages --exclude=pt_BR
django-admin makemessages --exclude=pt_BR --exclude=fr
django-admin makemessages -x pt_BR
django-admin makemessages -x pt_BR -x fr

--domain DOMAIN, -d DOMAIN¶

Задает домен файлов сообщений. Допустимые варианты:

django для всех файлов *.py , *.html и *.txt ( по умолчанию)
djangojs для файлов *.js

--symlinks, -s¶

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

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

django-admin makemessages --locale=de --symlinks

--ignore PATTERN, -i PATTERN¶

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

Эти основания используются по умолчанию: 'CVS' , '.*' , '*~' , '*.pyc' .

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

django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html

--no-default-ignore¶

Отключает значения по умолчанию --ignore .

--no-wrap¶

Отключает сегментацию длинных строк сообщений на несколько строк в языковых файлах.

--no-location¶

Подавляет запись строк комментариев в языковых файлах. С этой опцией переводчикам с хорошими техническими знаниями будет сложнее понять контекст каждого сообщения.#: filename:line

--add-location [{full,file,never}]¶

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

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

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

--keep-pot¶

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

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

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

`makemigrations` ¶

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

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

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

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

--noinput, --no-input¶

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

--empty¶

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

--dry-run¶

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

--merge¶

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

--name NAME, -n NAME¶

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

--no-header¶

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

--check¶

Выйти makemigrations со статусом, отличным от 0, если обнаружены изменения модели без соответствующей миграции.

`migrate` ¶

django-admin migrate [app_label] [migration_name]¶

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

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

Нет настройки: все приложения применяют все свои миграции.
<étiquette_app> : Миграции для указанного приложения применяются до самой последней миграции. Это также может привести к миграции приложения из других приложений в зависимости от зависимостей.
<étiquette_app> <nom_migration> : Изменяет схему базы данных на состояние, в котором применяется указанная миграция, но без применения последующих миграций того же приложения; это может привести к отмене некоторых миграций, если миграции после именованной миграции уже были применены. Вы можете использовать префикс имени миграции, например. 0001 , если он уникален для указанного имени приложения. Используйте это имя, zero чтобы перенести все назад, то есть отменить все миграции для приложения.

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

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

--database DATABASE¶

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

--fake¶

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

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

--fake-initial¶

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

--plan¶

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

--run-syncdb¶

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

--noinput, --no-input¶

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

--check¶

Новое в 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 поддерживает pywatchman 1.2.0 или новее.

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

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

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

DJANGO_WATCHMAN_TIMEOUT¶

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

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

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

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

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

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

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

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

--noreload¶

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

--nothreading¶

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

--ipv6, -6¶

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

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

Порт 8000 на IP-адресе 127.0.0.1 :

django-admin runserver

Порт 8000 на IP-адресе 1.2.3.4 :

django-admin runserver 1.2.3.4:8000

Порт 7000 на IP-адресе 127.0.0.1 :

django-admin runserver 7000

Порт 7000 на IP-адресе 1.2.3.4 :

django-admin runserver 1.2.3.4:7000

Порт 8000 на IPv6-адресе ::1 :

django-admin runserver -6

Порт 7000 на IPv6-адресе ::1 :

django-admin runserver -6 7000

Порт 7000 на IPv6-адресе 2001:0db8:1234:5678::9 :

django-admin runserver [2001:0db8:1234:5678::9]:7000

Порт 8000 на IPv4-адресе хоста localhost :

django-admin runserver localhost:8000

Порт 8000 на IPv6-адресе хоста localhost :

django-admin runserver -6 localhost:8000

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

По умолчанию сервер разработки не заботится об обслуживании статических файлов вашего сайта (таких как файлы CSS, изображения, содержимое и MEDIA_URL т. Д.). Если вы хотите настроить Django для обслуживания статического контента, см. Раздел Обработка статических файлов (например, изображений, JavaScript, CSS) .

`sendtestemail` ¶

django-admin sendtestemail [email [email ...]]¶

Отправляет тестовое электронное письмо (чтобы подтвердить, что отправка сообщений работает с Django) указанным получателям. Например :

django-admin sendtestemail foo@example.com bar@example.com

Есть несколько возможных вариантов, и вы без проблем можете комбинировать их:

--managers¶

Отправляет по электронной почте на адреса электронной почты , перечисленных в MANAGERS с mail_managers() .

--admins¶

Отправляет по электронной почте на адреса электронной почты , перечисленных в ADMINS с mail_admins() .

`shell` ¶

django-admin shell¶

Запускает интерактивный интерпретатор Python.

--interface {ipython,bpython,python}, -i {ipython,bpython,python}¶

Определяет используемую оболочку. По умолчанию Django использует IPython или bpython, если они установлены. Если оба установлены, вы можете указать нужный интерпретатор следующим образом:

IPython:

django-admin shell -i ipython

bpython:

django-admin shell -i bpython

Если у вас установлена одна из этих «богатых» оболочек, но вы хотите запустить «необработанный» интерпретатор Python, используйте python имя интерфейса, например:

django-admin shell -i python

--nostartup¶

Отключает чтение сценария запуска для «простого» интерпретатора Python. По умолчанию считывается сценарий, указанный в переменной среды.PYTHONSTARTUP или сценарий ~/.pythonrc.py .

--command COMMAND, -c COMMAND¶

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

django-admin shell --command="import django; print(django.__version__)"

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

$ django-admin shell <<EOF
> import django
> print(django.__version__)
> EOF

В Windows REPL отображается из-за ограничений реализации select.select() на этой платформе.

`showmigrations` ¶

django-admin showmigrations [app_label [app_label ...]]¶

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

--list, -l¶

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

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

Это формат отображения по умолчанию.

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

Добавлено отображение даты / времени подачи заявок из многословности 2.

--plan, -p¶

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

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

--database DATABASE¶

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

`sqlflush` ¶

django-admin sqlflush¶

Отображает команды SQL, которые были бы сгенерированы, если бы команда flush была выполнена.

--database DATABASE¶

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

`sqlmigrate` ¶

django-admin sqlmigrate app_label migration_name¶

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

Обратите внимание, что sqlmigrate полученный результат не окрашивается.

--backwards¶

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

--database DATABASE¶

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

`sqlsequencereset` ¶

django-admin sqlsequencereset app_label [app_label ...]¶

Отображает операторы SQL для сброса последовательности для заданных имен приложений.

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

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

--database DATABASE¶

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

`squashmigrations` ¶

django-admin squashmigrations app_label [start_migration_name] migration_name¶

Если возможно, объедините миграции étiquette_app до и включительно nom_migration с меньшим количеством миграций. Полученные в результате объединенные миграции могут легко появиться вместе с несвязанными миграциями. Для получения дополнительной информации, пожалуйста, прочтите « Объединение миграций» .

Если start_migration_name указано, Django включает только миграции, начинающиеся с этой миграции. Это помогает увидеть пределы слияния миграционных операций RunPython и django.db.migrations.operations.RunSQL .

--no-optimize¶

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

--noinput, --no-input¶

Избегайте каких-либо интерактивных запросов к пользователю.

--squashed-name SQUASHED_NAME¶

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

--no-header¶

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

`startapp` ¶

django-admin startapp name [directory]¶

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

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

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

Например :

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

--template TEMPLATE¶

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

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

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

Django также принимает URL ( http , https , ftp ) для сжатых архивов , содержащих образцы файлов приложений, будучи ответственным за загрузку и распаковывать их на лету.

Например, воспользовавшись функцией GitHub, которая предоставляет репозитории в виде zip-файлов, вы можете использовать такой URL-адрес:

django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp

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

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

--extension EXTENSIONS, -e EXTENSIONS¶

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

--name FILES, -n FILES¶

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

Для всех затронутых файлов используется:contexte de gabarit

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

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

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

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

Например :

django-admin startproject myproject /Users/jezdez/Code/myproject_repo

--template TEMPLATE¶

Задает каталог, путь к файлу или URL-адрес для настраиваемого шаблона проекта. См. Документацию для примеров использования.startapp --template

--extension EXTENSIONS, -e EXTENSIONS¶

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

--name FILES, -n FILES¶

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

В используется:contexte de gabarit

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

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

`test` ¶

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

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

--failfast¶

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

--testrunner TESTRUNNER¶

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

--noinput, --no-input¶

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

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

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

--keepdb¶

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

--reverse, -r¶

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

--debug-mode¶

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

--debug-sql, -d¶

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

--parallel [N]¶

DJANGO_TEST_PROCESSES¶

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

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

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

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

Заметка

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

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

$ python -m pip install tblib

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

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

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

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

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

--tag TAGS¶

Выполняйте только тесты, отмеченные упомянутыми этикетками . Возможны несколько случаев и возможна комбинация с .test --exclude-tag

--exclude-tag EXCLUDE_TAGS¶

Исключает тесты, отмеченные упомянутыми этикетками . Возможны несколько случаев и возможна комбинация с .test --tag

-k TEST_NAME_PATTERNS¶

Новое в Django 3.0.

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

Python 3.7 и новее

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

--pdb¶

Новое в Django 3.0.

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

--buffer, -b¶

Новое в Django 3.1.

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

`testserver` ¶

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

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

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

django-admin testserver mydata.json

… Выполняет следующие операции:

Создание тестовой базы данных, как описано в разделе «Тестовая база данных» .
Заполните тестовую базу данных снимками данных с указанными именами снимков (более подробную информацию о снимках см. В документации loaddata ).
Запустите сервер разработки Django (как и в случае runserver ), используя только что созданную тестовую базу данных по ссылке производственной базы данных.

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

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

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

--addrport ADDRPORT¶

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

Примеры:

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

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

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

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

django-admin testserver --addrport 1.2.3.4:7000 test

--noinput, --no-input¶

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

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

`django.contrib.auth` ¶

`changepassword` ¶

django-admin changepassword [<username>]¶

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

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

--database DATABASE¶

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

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

django-admin changepassword ringo

`createsuperuser` ¶

django-admin createsuperuser¶

DJANGO_SUPERUSER_PASSWORD¶

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

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

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

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

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

Поддержка переменных окружения DJANGO_SUPERUSER_PASSWORD и DJANGO_SUPERUSER_<nom_champ_en_majuscules> была добавлена.

--noinput, --no-input¶

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

--username USERNAME¶

--email EMAIL¶

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

--database DATABASE¶

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

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

`django.contrib.contenttypes` ¶

`remove_stale_contenttypes` ¶

django-admin remove_stale_contenttypes¶

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

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

--database DATABASE¶

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

--include-stale-apps¶

Новое в 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` ¶

Эта команда доступна, только если установлена инфраструктура " sitemap" ( django.contrib.sitemaps ).

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

`django.contrib.staticfiles` ¶

`collectstatic` ¶

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

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

`findstatic` ¶

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

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

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

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

--pythonpath PYTHONPATH¶

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

Эта опция бесполезна manage.py , потому что она устанавливает путь Python за вас.

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

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

--settings SETTINGS¶

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

Этот параметр не является обязательным manage.py , поскольку по умолчанию он использует модуль settings.py текущего проекта.

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

django-admin migrate --settings=mysite.settings

--traceback¶

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

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

django-admin migrate --traceback

--verbosity {0,1,2,3}, -v {0,1,2,3}¶

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

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

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

django-admin migrate --verbosity 2

--no-color¶

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

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

django-admin runserver --no-color

--force-color¶

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

--skip-checks¶

Новое в Django 3.0.

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

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

django-admin migrate --skip-checks

Дополнительные опции ¶

Цветной синтаксис ¶

DJANGO_COLORS¶

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

В Windows собственная консоль не поддерживает escape-последовательности ANSI, поэтому результат не окрашивается. Однако вы можете установить внешний инструмент ANSICON , который команды Django будут обнаруживать и использовать для создания цветного вывода, как для Unix-подобных платформ.

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

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

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

export DJANGO_COLORS="light"

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

error - Большая ошибка.
notice - Небольшая ошибка.
success - Успех.
warning - Предупреждение.
sql_field - Имя поля модели в SQL.
sql_coltype - Тип поля модели в SQL.
sql_keyword - Ключевое слово SQL.
sql_table - Название модели в SQL.
http_info - Ответ HTTP-сервера информационного типа (1XX)
http_success - Успешный ответ HTTP-сервера (2XX)
http_not_modified - Неизмененный ответ HTTP-сервера (304)
http_redirect - Ответ HTTP-сервера с типом перенаправления (3XX, кроме 304).
http_not_found - Ответ HTTP-сервера не найден (404).
http_bad_request - Неверный ответ HTTP-сервера типа запроса (4XX, кроме 404).
http_server_error - Ответ HTTP-сервера типа ошибки (5XX).
migrate_heading - Заголовок в команде администрирования миграции.
migrate_label - Имя миграции.

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

black (Черный)
red (Красный)
green (Зеленый)
yellow (Желтый)
blue (Синий)
magenta
cyan
white (Белый)

Затем каждый из этих цветов можно изменить, используя следующие параметры отображения:

bold (смелый)
underscore (Выделено)
blink (указатель поворота)
reverse
conceal (Маска)

Спецификация цвета соответствует одной из следующих причин:

role=fg
role=fg/bg
role=fg,option,option
role=fg/bg,option,option

где role - имя допустимой цветовой роли, fg - bg цвет переднего плана, - цвет фона, и каждый option - один из вариантов изменения цвета. Затем несколько цветовых обозначений разделяются точкой с запятой. Например :

export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"

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

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

export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"

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

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

Если вы используете оболочку Bash, рекомендуется установить сценарий Django завершения Bash, который находится в extras/django_bash_completion исходном дистрибутиве Django. Он активирует завершение путем табулирования команд django-admin и для manage.py того, чтобы иметь возможность, например ...

Войдите django-admin .
Нажмите [TAB], чтобы увидеть все доступные параметры.
Введите sql , затем [TAB], чтобы увидеть все доступные команды, имена которых начинаются с sql .

См. Раздел Написание пользовательских команд django-admin, чтобы узнать, как добавлять пользовательские действия.

Запуск команд управления из кода ¶

django.core.management.call_command( имя , * аргументы , ** параметры ) ¶

Чтобы вызвать команду управления из кода, используйте call_command .

name: имя вызываемой команды или командного объекта. Желательно передать имя, если только предмет не является обязательным для тестирования.
*args: список параметров, принимаемых командой. Параметры передаются парсеру параметров, что означает, что вы можете использовать тот же стиль, что и в командной строке. Например, .call_command('flush', '--verbosity=0')
**options: Именованные параметры принимаются в командной строке. Параметры передаются команде без вызова парсера параметров, что означает, что необходимо передать правильный тип. Например, (ноль должен быть целым числом, а не строкой).call_command('flush', verbosity=0)

Примеры:

from django.core import management
from django.core.management.commands import loaddata

management.call_command('flush', verbosity=0, interactive=False)
management.call_command('loaddata', 'test_data', verbosity=0)
management.call_command(loaddata.Command(), 'test_data', verbosity=0)

Обратите внимание, что параметры команды, которые не принимают параметр, передаются как ключевые слова с True или False , как вы можете видеть с помощью параметра interactive выше.

Именованные параметры могут быть переданы с использованием одного из следующих синтаксисов:

# Similar to the command line
management.call_command('dumpdata', '--natural-foreign')

# Named argument similar to the command line minus the initial dashes and
# with internal dashes replaced by underscores
management.call_command('dumpdata', natural_foreign=True)

# `use_natural_foreign_keys` is the option destination variable
management.call_command('dumpdata', use_natural_foreign_keys=True)

Некоторые параметры команды называются по-другому, когда команды вызываются с помощью call_command() вместо django-admin или manage.py . Например, переводится как . Чтобы узнать, для какого именованного имени параметра использовать , просмотрите исходный код команды и найдите переданный параметр .django-admin createsuperuser --no-input call_command('createsuperuser', interactive=False) call_command() dest parser.add_argument()

Параметры команды, принимающие несколько параметров, передаются в виде списка:

management.call_command('dumpdata', exclude=['contenttypes', 'auth'])

Значение, возвращаемое функцией, call_command() такое же, как значение, возвращаемое методом handle() команды.

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

Обратите внимание, что вы можете перенаправить стандартный вывод и потоки ошибок, потому что все команды принимают параметры stdout и stderr , например, вы можете написать:

with open('/path/to/command_output', 'w') as f:
    management.call_command('dumpdata', stdout=f)

3.2
Версия документации: 3.1

django-admin и manage.py ¶ window.yaContextCb.push(()=>{ Ya.Context.AdvManager.render({ renderTo: 'yandex_rtb_R-A-2008230-3', blockId: 'R-A-2008230-3' }) })

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

Получение помощи ¶

Имена приложений ¶

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

Отображение отладочного содержимого ¶

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

check ¶

compilemessages ¶

createcachetable ¶

dbshell ¶

diffsettings ¶

dumpdata ¶

flush ¶

inspectdb ¶

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

Оракул ¶

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 ¶

Запуск команд управления из кода ¶ window.yaContextCb.push(()=>{ Ya.Context.AdvManager.render({ renderTo: 'yandex_rtb_R-A-2008230-3', blockId: 'R-A-2008230-3' }) })

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

Резюме

Просматривать

Вы здесь :

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

Запуск команд управления из кода ¶