django-admin – это консольный инструмент Django. Этот раздел описывает его возможности.
До Django 1.7 django-admin устанавливался только как django-admin.py.
Также для каждого проекта автоматически создается manage.py. manage.py – это простой интерфейс для django-admin, который выполняет некоторые вещи перед тем, как обратиться к django-admin:
Добавляет пакет проекта в sys.path.
Устанавливает переменную окружения DJANGO_SETTINGS_MODULE, чтобы она указывала на файл settings.py проекта.
Вызывает django.setup() для инициализации Django.
django.setup() отсутствовала в предыдущих версиях Django.
Если вы установили Django через setup.py, скрипт django-admin уже должен находиться в путях поиска(переменная окружения PATH) вашей системы. Если система не может его найти, поищите его в подкаталоге site-packages/django/bin каталога установленного Python. Вы можете создать симлинк на скрипт в каталоге, который находится в путях поиска системы, например /usr/local/bin.
Пользователи Windows, где нет симлинков, могут скопировать django-admin.exe в каталог, который уже находится в путях поиска системы, или отредактировать переменную окружения PATH (можно найти через Settings - Control Panel - System - Advanced - Environment...) и добавить каталог с установленным django-admin.exe.
При работе с одним проектом Django удобнее использоваться manage.py, чем django-admin. Если вам необходимо переключаться между различными фалами настройки, используйте django-admin с переменной окружения DJANGO_SETTINGS_MODULE или опцией --settings.
Во всех примерах в этом разделе используется django-admin, но вы можете использовать и manage.py, ничего не изменится.
$ django-admin <command> [options]
$ manage.py <command> [options]
command – одна из команд, описанных в этом разделе. options – необязательные опции команды.
Выполните django-admin help, что бы увидеть помощь и список доступных команд.
Выполните django-admin help --commands, чтобы увидеть список доступных команд.
Выполните django-admin help <command>, чтобы увидеть описание указанной команды и список доступных опций.
Большая часть команд принимает список “названий приложений”. “Название приложения” – это название основного пакета приложения. Например, если настройка INSTALLED_APPS содержит строку 'mysite.blog', название приложения будет blog.
Выполните django-admin version, чтобы получить текущую версию Django.
Вывод соответствует формату, описанному в PEP 386:
1.4.dev17026
1.4a1
1.4
Укажите --verbosity, чтобы определить уровень выводимых в консоль django-admin уведомлений и отладочной информации. Подробности смотрите в описании опции --verbosity.
Использует приложение проверки, чтобы проанализировать проект Django на наличие распространенных проблем.
Приложение проверки проекта проверит модели на наличие ошибок, также проверить инициализацию интерфейса администратора. Также предоставит предупреждения о проблемах совместимости, которые могут возникнуть при обновлении Django. Вы можете создать свои функции проверки.
По умолчанию проверяются все приложения. Вы можете указать список приложений в аргументах команды:
python manage.py check auth admin myapp
Если приложения не указаны, будут проверены все установленные приложения.
Приложение проверки выполняет большое количество различных типов проверок. Это типы определяются тегами. Вы можете указать список тегов, чтобы ограничить выполняемые проверки. Например, чтобы проверить проект только на безопасность и совместимость, выполните:
python manage.py check --tag security --tag compatibility
Выводит список всех доступных тегов.
Опция --deploy выполняет дополнительные проверки, которые уместны только для настроек сервера, а не окружения для разработки.
Вы можете использовать эту опцию и при разработке, но т.к. локальное окружение не содержит всех настроек сервера, вам может понадобиться указать команде check другой модуль с настройками через переменную окружения DJANGO_SETTINGS_MODULE, или передав опцию --settings:
python manage.py check --deploy --settings=production_settings
Вы можете использовать эту опцию на “боевом” или тестовом сервере (без --settings). Вы даже можете сделать проверку частью тестов.
Компилирует .po файлы, созданные командой makemessages, в файлы .mo, которые используются gettext для локализации проекта. Смотрите Интернационализация и локализация.
Вы можете указать список локалей с помощью опции --locale (сокращенный вариант -l). Если опция не указана, будут обработаны все локали.
Опция --exclude (или короткий вариант -x) позволяет исключить локали из обработки. Если не указана, ни одна локаль не будет исключена.
Вы можете указать опцию --use-fuzzy (или -f), чтобы включить неточный перевод в скомпилированные файлы перевода.
Добавлены опции --exclude и --use-fuzzy.
Пример использования:
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
Создает таблицу в базе данных, которая будет использоваться соответствующим бэкендом кеша. Смотрите Система кэширования Django.
Опция --database позволяет указать базу данных, в которой будет создана таблица.
Больше не обязательно указывать название таблицы или опцию --database. Django берет эту информацию из файла настроек. Если вы указали несколько кешей или баз данных, будут созданы все необходимые таблицы.
Запускает консольный клиент для подключения к базе данных. Консольный клиент определяется настройкой ENGINE, параметры подключения – настройками USER, PASSWORD, и т.д.
Для PostgreSQL используется консольный клиент psql .
Для MySQL используется mysql.
Для SQLite используется sqlite3.
Эта команда подразумевает, что клиент находится в PATH системы, и запуск клиента в консоли (psql, mysql, sqlite3) работает. Нет способа указать путь к клиенту.
Опция --database позволяет указать базу данных, к которой будет выполнено подключение.
Показывает разницу между текущими настройками и настройками Django по умолчанию.
Настройки, которые не указаны в настройках по умолчанию, выводятся с "###" в конце. Например, в настройках по умолчанию не указан ROOT_URLCONF, и в выводе diffsettings, к ROOT_URLCONF будет добавлен "###" в конце.
Опция --all позволяет вывести все настройки, даже если они не отличаются от настроек по умолчанию. Такие настройки выводятся с префиксом "###".
Выводит в консоль все данные из базы данных, которые связаны с указанными приложениями.
Если приложение не указано, будет выполнен дамп данных для всех приложений.
Вывод команды dumpdata может использоваться для команды loaddata.
Обратите внимание, dumpdata использует менеджер по умолчанию модели для получения данных. Если вы используете собственный менеджер как менеджер по умолчанию, который отфильтровывает часть данных, отфильтрованные данные не попадут в результат команды.
Опция --all позволяет указать dumpdata использовать базовый менеджер Django, чтобы исключить фильтрацию данных собственным менеджером модели.
По умолчанию dumpdata будет выводить данные в формате JSON. Вы можете указать другой формат с помощью опции --format. Доступные форматы описаны в Serialization formats.
По умолчанию dumpdata выведет все данные одной строкой. Это не очень удобно для понимая человеком. Для читабельного вывода вы можете указать опцию --indent. Указанное значение будет использоваться как величина отступа.
Опция --exclude позволяет исключить определенные приложения или модели (формат значений – app_label.ModelName). Если в аргументах dumpdata указать модель, будет выведен дамп данных только для этой модели, а не всего приложения. Вы можете указать модели и приложения вместе.
Опция --database позволяет указать базу данных, с которой будут загружаться данные.
Если указана эта опция, Django будут использовать метод связанной модели natural_key() для внешних ключей и связей многое-ко-многим. Если вы делаете дамп contrib.auth Permission или contrib.contenttypes ContentType, вам следует использовать эту опцию. Подробности смотрите в разделе о натуральных ключах.
Если указана эта опция, Django не будет добавлять первичный ключ в результат, т.к. он может быть вычислен при десирализации данных.
Не рекомендуется, начиная с версии 1.7: Аналог опции --natural-foreign, используйте её вместо этой опции.
Django будут использовать натуральные ключи для внешних ключей и связей многое-ко-многим.
По умолчанию dumpdata выведет все объекты модели, но вы можете использовать опцию --pks, чтобы указать через запятую список ID объектов, которые необходимо вывести. Эта опция доступна только при дампе одной модели.
По умолчанию dumpdata выведет результат в консоль. Эта опция позволяет указать файл, в который будет записан результат.
Удаляет все данные из базы данных, запускает “post-synchronization” обработчики и загружает начальные данные из фикстур.
Опция --noinput отключить вывод в консоль.
Опция --database позволяет указать базу данных, которая будет очищена.
Опция --no-initial-data позволяет отключить загрузку начальных данных из “initial_data” фикстур.
Анализирует таблицы в базе данных, указанной настройкой NAME, и выводит сгенерированные модели Django (файл models.py) в стандартный вывод.
Вы можете использовать эту команду, чтобы создать модели для уже существующей базы данных. Команда анализирует базу данных и создает модель для каждой таблицы или представления(VIEW).
Сгенерированные модели будут содержать атрибут поля для каждого поля таблицы или представления. Обратите внимание, есть несколько особенностей в работе этой команды:
Если inspectdb не может подобрать подходящий тип поля модели, будет использоваться поле TextField с комментарием в коде 'This field type is a guess.' возле этого поля.
Если название колонки в таблице входит в зарезервированные слова Python (такие как 'pass', 'class' или 'for'), inspectdb добавит '_field' к названию атрибута. Например, если таблица содержит колонку 'for', сгенерированная модель будет содержать поле 'for_field', с параметром db_column равным 'for'. inspectdb добавит комментарий в коде 'Field renamed because it was a Python reserved word.' возле поля.
Эту команду можно использовать для генерации начальных моделей. После выполнения команды вам следует проверить сгенерированные модели и внести необходимые изменения. Также вам следует изменить порядок моделей в соответствии с внешними связями.
Первичные ключи автоматически определяются для PostgreSQL, MySQL и SQLite, и Django добавит для соответствующих полей primary_key=True.
inspectdb работает с PostgreSQL, MySQL и SQLite. Определение внешних ключей работает только для PostgreSQL и некоторых типов таблиц MySQL.
Django не добавляет значение по умолчанию для колонки в таблице, если поле модели содержит default. Аналогично команда inspectdb не добавляет в поле модели значение по умолчанию из колонки в таблице.
По умолчанию inspectdb создает неуправляемые модели. То есть с managed=False``в классе ``Meta модели, что указывает Django не управляет созданием, изменением или удалением таблицы. Чтобы позволить Django управлять моделью, установите параметр managed в True (или просто удалите его, True является значением по умолчанию).
Опция --database позволяет указать базу данных.
Была добавлена возможность анализировать представления базы данных. Ранее работало только для таблиц.
Ищет и загружает указанные фикстуры в базу данных.
Опция --database позволяет указать базу данных, в которую будут загружены данные..
Опция --ignorenonexistent позволяет игнорировать отсутствие полей в модели и моделей, если они были удалены после создания фикстуры.
Опция --app позволяет указать приложение, которое будет использоваться для поиска фикстур. Без этой опции фикстуры ищутся во всех приложениях.
Была добавлена опция --app.
--ignorenonexistent теперь игнорирует отсутствующие модели.
Фикстура – это файл с сериализированными данными из базы данных. У каждой фикстуры уникальное название Фикстуры могут находиться в различных каталогах и приложениях.
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
выполнит поиск в <app_label>/fixtures/foo/bar/mydata.json в каждом установленном приложении, <dirname>/foo/bar/mydata.json – для каждого каталога из FIXTURE_DIRS, и foo/bar/mydata.json.
После обработки фикстур данные будут загружены непосредственно в базу данных. Метод save() модели не будет вызван. Обработчики сигналов pre_save и post_save будут вызваны с аргументом raw=True т.к. экземпляр модели содержит только локальные атрибуты. Вы можете, например, отключить обработчик, который обращается к внешним ключам т.к. они не определены при загрузке фикстуры, что вызовет исключение:
from django.db.models.signals import post_save
from .models import MyModel
def my_handler(**kwargs):
# disable the handler during fixture loading
if kwargs['raw']:
return
...
post_save.connect(my_handler, sender=MyModel)
Также вы можете для этого создать простой декоратор:
from functools import wraps
def disable_for_loaddata(signal_handler):
"""
Decorator that turns off signal handlers when loading fixture data.
"""
@wraps(signal_handler)
def wrapper(*args, **kwargs):
if kwargs['raw']:
return
signal_handler(*args, **kwargs)
return wrapper
@disable_for_loaddata
def my_handler(**kwargs):
...
Учитывайте, что этот код отключает обработку сигналов при любой загрузке фикстур, а не только для команды loaddata.
Обратите внимание, не известно в каком порядке будут загружены фикстуры. Но все данные будут добавлены в базу данных в одной транзакции, и данные из одной фикстуры могут ссылаться на данные из другой фикстуры. Если база данных содержит проверку внешних ключей, она будет выполнена в конце транзакции.
Для генерации фикстур для loaddata можно использовать команду dumpdata.
Фикстуры могут быть сжаты в zip, gz или bz2 архив. Например:
django-admin loaddata mydata.json
будет искать mydata.json, mydata.json.zip, mydata.json.gz или mydata.json.bz2. Первый файл из архива будет загружен как фикстура.
Обратите внимание, если найдено две фикстуры с одинаковым именем, но разного формата (например, mydata.json и mydata.xml.gz были найдены в одном каталоге), загрузка фикстур будет остановлена, и загруженные loaddata до этого данные будет удалены из базы данных.
MySQL с MyISAM и фикстуры
Хранилище MyISAM в MySQL не поддерживает транзакции и проверку внешних ключей. Если вы используйете MyISAM, проверка данных из фикстур не будет выполнена, как и откат изменений, если было найдено несколько фикстур с одинаковыми названиями.
Если вы используете несколько баз данных, вам может понадобиться загрузить фикстуры в одну базу данных, но не загружать в другую. В таком случае вы можете добавить идентификатор базы данных в название фикстуры.
Например, если настройка DATABASES содержит базу данных ‘master’, назовите фикстуру mydata.master.json или mydata.master.json.gz и она будет загружена в базу данных master.
Анализирует все файлы в текущем каталоге и парсит строки, которые помечены для перевода. Создает (или обновляет) файл переводимых сообщений в conf/locale (в каталоге проекта) или каталоге переводов (для проекта или приложения). Чтобы использовать файлы перевода с помощью gettext, необходимо их скомпилировать командой compilemessages. Смотрите раздел о i18n
Используйте опцию --all или -a чтобы обновить файлы перевода для всех языков.
Пример использования:
django-admin makemessages --all
С помощью опции --extension или -e можно указать список расширений файлов, которые будут обрабатываться командой (по умолчанию: ”.html”, ”.txt”).
Пример использования:
django-admin makemessages --locale=de --extension xhtml
Вы можете укать несколько расширений через запятую, или указав опцию -e или –extension несколько раз:
django-admin makemessages --locale=de --extension=html,txt --extension xml
Опция --locale (или короткий вариант -l) позволяет указать обрабатываемые локали.
Опция --exclude (или короткий вариант -x) позволяет исключить локали из обработки. Если не указана, ни одна локаль не будет исключена.
Пример использования:
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
Была добавлена опция --previous для команды msgmerge, которая используется для создания po файлов.
Опция --domain или -d позволяет изменить “домен” файлов перевода. Поддерживается:
django для *.py, *.html и *.txt файлов (по умолчанию)
djangojs для файлов *.js
Опция --symlinks или -s позволяет указать следовать ли по символическим ссылкам при поиске файлов.
Пример использования:
django-admin makemessages --locale=de --symlinks
Опция --ignore или -i позволяет игнорировать файлы или каталоги, которые соответствуют указанному шаблону в стиле glob. Можно указать несколько раз.
По умолчанию используются следующие шаблоны: 'CVS', '.*', '*~', '*.pyc'
Пример использования:
django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
Опция --no-default-ignore позволяет отключить значения по умолчанию для --ignore.
Опция --no-wrap позволяет отключить разбивку длинных сообщений на несколько строк в файле перевода.
Опция --no-location позволяет отключить добавление ‘#: filename:line’ в файлы перевода. Обратите внимание, использование этой опции может усложнить работу технически образованным переводчикам, которым такие комментарии помогают понять смысл переводимого сообщения.
Опция --keep-pot указывает Django не удалять временные .pot файлы, которые создаются перед созданием .po файлов. Это полезно при отладке ошибок, которые мешают созданию файлов перевода.
См.также
В Настройка команды makemessages вы можете узнать как настроить параметры, которые makemessages передает в xgettext.
Создает новые миграции на основе изменений в моделях. Подробнее о миграциях вы можете прочитать в соответствующем разделе.
Вы можете указать приложения, для которых следует создать миграции, также будут учитываться связанные приложения (например, которые содержат модели, на которые ссылаются ForeignKey).
Опция --empty укажет makemigrations создать пустую миграцию для последующего редактирования вручную. Эту опцию следует использоваться только продвинутым пользователям, которые хорошо знают как работают миграции в Django.
Опция --dry-run позволяет вывести все действия, которые будут выполнять создаваемые миграции, не создавая файл с миграцией. Если дополнительно указать --verbosity 3, будет выведено содержимое файлов миграций, которые будут созданы.
Опция --merge позволяет исправлять конфликты в миграциях. Опция --noinput позволяет отключить запрос на ввод пользователя при мерже миграций.
Опция --name позволяет указать миграции название.
Опция --exit указывает makemigrations завершиться с кодом ошибки 1, если миграция не была создана (или не была бы создана, если используется с --dry-run).
Синхронизирует состояние базы данных с текущим состоянием моделей и миграций. Подробнее о миграциях вы можете прочитать в соответствующем разделе.
Поведение команды зависит от указанных аргументов:
Без аргументов: будет выполнена синхронизация всех приложений,
<app_label>: Будут выполнены миграции для указанного приложения до самой последней миграции. Это может вызвать миграцию других приложений через зависимости в миграциях.
<app_label> <migrationname>: Приводит базу данных к состоянию, которые было бы после завершения указанной миграции, но последующие миграции не выполнены. Обратите внимание, это может привести к отмене миграций, если были выполнены миграции, которые следуют после указанной вами. Используйте zero, чтобы отменить все миграции для приложения.
В отличии от syncdb эта команда не пытается создать супер-пользователя, если такой не существует (подразумевается, что вы используете django.contrib.auth). Для этого используйте команду createsuperuser.
Опция --database позволяет указать базу данных для миграции.
Опция --fake указывает Django пометить миграции как выполненные/невыполненные без выполнения каких-либо SQL запросов.
Эта опция предназначена для опытных пользователей, которые хотят явно указать состояние миграций после применения изменений вручную. Будьте осторожны, использование --fake может “сломать” автоматическое применение миграций.
Опция --fake-initial позволяет Django пропустить начальную миграцию, если уже существуют все таблицы для моделей, которые указанны в операциях :class:`~django.db.migrations.operations.CreateModel`миграции. Эта опция создана для первого выполнения миграции на базе данных, которая существовала до создания миграций. Однако, эта опция не выполняет проверки соответствия структуры таблиц и моделей, поэтому следует использовать её, если вы уверены в правильности миграций.
Не рекомендуется, начиная с версии 1.8: Опция --list была перенесена в команду showmigrations.
Не рекомендуется, начиная с версии 1.7: Поддержка FastCGI устарела и будет удалена в Django 1.9.
Запускает несколько совместимых с FastCGI процессов, которые могут использоваться с Web-сервером, который поддерживает FastCGI протокол. Смотрите раздел о FastCGI. Требует FastCGI Python модуль из flup.
Внутри выполняет оборачивание объекта WSGI приложения, указанного в настройке WSGI_APPLICATION.
Доступные опции передаются в библиотеку FastCGI и не используют префикс '--', как это принято для остальных команд Django.
protocol=PROTOCOL
Используемый протокол. PROTOCOL может быть fcgi, scgi, ajp и т.д.. (по умолчанию fcgi)
host=HOSTNAME
Имя хоста.
port=PORTNUM
Номер порта.
socket=FILE
UNIX-сокет.
method=IMPL
Доступные значения: prefork или threaded (по умолчанию prefork)
maxrequests=NUMBER
Количество запросов после которого будет перезапущен дочерний процесс (0 - неограниченное количество запрос).
maxspare=NUMBER
Максимальное количество “запасных” процессов / потоков.
minspare=NUMBER
Минимальное количество “запасных” процессов / потоков.
maxchildren=NUMBER
Лимит на количество процессов / потоков.
daemonize=BOOL
“Отвязать” ли от терминала.
pidfile=FILE
Записать ID процесса в файл FILE.
workdir=DIRECTORY
Переключиться на каталог DIRECTORY при создании процесса-демона.
debug=BOOL
Укажите true, чтобы включить полный трейсбек в flup.
outlog=FILE
Записывать stdout в файл FILE.
errlog=FILE
Записывать stderr в файл FILE.
umask=UMASK
Umask, которая будет использоваться при “демонизации” процесс. Значение должно быть восьмеричным числом (по умолчанию 0o22).
Пример использования:
django-admin runfcgi socket=/tmp/fcgi.sock method=prefork daemonize=true \
pidfile=/var/run/django-fcgi.pid
Запускает FastCGI сервер как демон и записывает PID в файл.
Запускает простой локальный Web-сервер для разработки. По умолчанию сервер запускается на 8000 порте и 127.0.0.1 IP адресе. Вы можете явно указать IP адрес и порт.
Если вы запускаете команду как пользователь со стандартными правами (рекомендуется), у вас может не быть доступа к портам с малым номером. Такие порты зарезервированы для супер-пользователя (root).
Этот сервер использует объект WSGI приложения, которое указанно в настройке WSGI_APPLICATION.
НЕ ИСПОЛЬЗУЙТЕ ЭТОТ СЕРВЕР НА БОЕВОМ СЕРВЕРЕ. Этот сервер не анализировался на предмет уязвимостей и не подвергался тестам производительности. (И так оно и будет. Мы умеем делать Web-фреймворки, не Web-серверы, поэтому доработка этого сервера не входит в наши задачи.)
Сервер для разработки автоматически перезапускается при изменении Python кода при необходимости. Нет необходимости перезапускать сервер при каждом изменении. Однако, некоторые изменения, такие как добавление файла, не вызывают перезапуск сервера, и вам необходимо сделать это самостоятельно.
Компилирование файлов перевода теперь перезапускает сервер для разработки.
Если вы используете Linux и установили pyinotify, будут использоваться kernel signals для перезапуска сервера (вместо мониторинга времени изменения файлов). Это улучшает производительность для больших проектов, уменьшает время реакции на изменения кода, более надежное обнаружение изменений, и уменьшает потребление заряда батареи.
Была добавлена поддержка pyinotify.
После запуска сервера при каждом изменении 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 этого приложения.
Если команда migrate ранее не выполнялась, при первом запуске runserver будет создана таблица, которая хранит историю выполнения миграций.
Опция --noreload позволяет отключить автоматическую перезагрузку сервера при изменении Python файлов.
Пример использования:
django-admin runserver --noreload
Сервер для разработки по умолчанию многопоточный. Опция --nothreading позволяет отключить многопоточность.
Опция --ipv6 (или короткий вариант -6) указывает Django использовать IPv6. IP адрес по умолчанию 127.0.0.1 будет заменен на ::1.
Пример использования:
django-admin runserver --ipv6
Порт 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). Как настроить раздачу файлов можно узнать из раздела Работа со статическими файлами (CSS, изображения).
Запускает интерактивный интерпретатор Python.
Django использует IPython или bpython, если они установлены. Если вы хотите использовать “обычный” интерпретатор Python, укажите опцию --plain:
django-admin shell --plain
Если у вас установлен IPython и bpython, вы можете явно указать какой использовать с помощью опции -i или --interface:
IPython:
django-admin shell -i ipython
django-admin shell --interface ipython
bpython:
django-admin shell -i bpython
django-admin shell --interface bpython
При запуске “обычного” интерпретатора Python, он выполняет скрипт, указанный в переменной окружения PYTHONSTARTUP, а также скрипт ~/.pythonrc.py. Опция --no-startup позволяет отключить такое поведение:
django-admin shell --plain --no-startup
Показывает все миграции в проекте.
Опция --list выведет все приложения в проекте, список доступных миграций и пометки были ли они выполнены (знак [X] возле названия миграции).
Приложения без миграций также будут указаны, но с пометкой (no migrations).
Опция --plan показывает план выполнения миграций, которому будет следовать Django для выполнения всех миграций. Указанные приложения игнорируются т.к. план выполнения миграций может содержать миграций из разных приложений. Как и для --list, выполненные миграции помечены [X]. При --verbosity 2 и выше будут выведены все зависимости миграции.
Выводит в консоль CREATE TABLE SQL запросы для указанных приложений.
Опция --database позволяет указать базу данных, для который выводить SQL запросы.
Выводит в консоль CREATE TABLE и все инициализирующие SQL запросы для указанных приложений.
Смотрите описание sqlcustom, чтобы узнать как добавить загрузку начальных данных.
Опция --database позволяет указать базу данных, для который выводить SQL запросы.
Команды sql* теперь учитывают метод allow_migrate() объектов из настройки DATABASE_ROUTERS. Если у вас есть модели, которые синхронизированы не в базу данных по умолчанию, используйте опцию --database, чтобы получить SQL для этих моделей (ранее они всегда включались в вывод команды).
Выводит в консоль DROP TABLE SQL запросы для указанных приложений.
Опция --database позволяет указать базу данных, для который выводить SQL запросы.
Выводит в консоль собственные SQL запросы для указанных приложений.
Для каждой модели указанных приложений эта команда ищет файл <app_label>/sql/<modelname>.sql, где <app_label> - название приложения, а <modelname> - название модели в нижнем регистре. Например, для приложения news и модели Story, sqlcustom будет искать файл news/sql/story.sql и добавит его содержимое в результат выполнения команды.
Каждый найденный SQL файл должен содержать правильные SQL запросы. SQL файлы загружаются непосредственно в базу данных, сразу после создания таблиц для моделей. Используйте их, чтобы внести изменения в таблицу, или добавить SQL функции.
Обратите внимание, порядок, в котором загружаются SQL файлы, не определен.
Опция --database позволяет указать базу данных, для который выводить SQL запросы.
Выводит в консоль DROP INDEX SQL запросы для указанных приложений.
Опция --database позволяет указать базу данных, для который выводить SQL запросы.
Выводить в консоль SQL запросы, которые будут выполнены при выполнении команды flush.
Опция --database позволяет указать базу данных, для который выводить SQL запросы.
Выводит в консоль CREATE INDEX SQL запросы для указанных приложений.
Опция --database позволяет указать базу данных, для который выводить SQL запросы.
Выводит в консоль SQL запросы для указанной миграции. Требует активного подключения к базе данных, чтобы определить доступны имена constraint(FIXME). Это значит, что вы должны создать SQL для копии базы данных, к которой будут применяться запросы.
Обратите внимание, sqlmigrate не использует цветной вывод в консоль.
Опцию --database позволяет указать базу данных, для которой необходимо создать SQL запросы.
По умолчанию SQL создает для применения миграций. Опция --backwards позволяет создать SQL для отмены миграций.
Выводит в консоль SQL запросы для сброса счетчика автоинкрементных полей.
Эти счетчики используются для определения следующего доступного номера.
Вы можете использовать эту команду для генерации SQL запросов, которые помогут исправить несоответствие счетчиков и существующих данных в автоинкрементных полях.
Опция --database позволяет указать базу данных, для который выводить SQL запросы.
Объединяет миграции, если это возможно, для приложения app_label от начальной и до migration_name, включая её. Полученные объединенные миграции могут существовать параллельно с начальными. Подробности смотрите в разделе Объединение миграций.
По умолчанию Django пытается оптимизировать операции в миграциях, чтобы уменьшить размер файла. Опция --no-optimize позволяет отключить такое поведение, если оптимизация привела к созданию неправильной миграции, или ошибке при выполнении команды. Также мы просим сообщить об этом в баг-трекере Django.
Создает структуру каталога приложения Django с указанным названием в текущем каталоге, или в котором вы укажите.
По умолчанию созданный каталог содержит файл models.py и другие файлы шаблона приложения. (Смотрите исходный код). Если вы указали только название приложения, оно будет создано в текущем каталоге.
Если вы указали путь к каталогу, Django будет использовать его, вместо создания нового. Вы можете использовать ‘.’, чтобы указать текущий каталог.
Например:
django-admin startapp myapp /Users/jezdez/Code/myapp
Опция --template позволяет указать путь к своему шаблону приложения. Вы можете указать путь к каталогу или архиву (.tar.gz, .tar.bz2, .tgz, .tbz, .zip), который содержит файлы шаблона приложения.
Например:
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 копирует файлы, он может рендерить определенные файлы как шаблоны Django: все файлы с расширением, указанным опцией --extension (по умолчанию py), и файлы с названием, указанным опцией --name. При рендеринге используется template context со следующими переменными:
Все опции, переданные при вызове команды startapp (только поддерживаемые этой командой)
app_name – название приложение, указанное при вызове команды
app_directory – полный путь к созданному приложению
docs_version – версия документации: 'dev' или '1.x'
Предупреждение
При рендеринге файлов шаблона приложения (по умолчанию все *.py файлы) Django заменит все шаблонные переменные. Например, если какой-то Python файл содержит комментарий, описывающий примеры использования системы шаблонов Django, он может быть искажен в созданном приложении.
Чтобы избежать этого, используйте тег templatetag для “экранирования” синтаксиса шаблонов.
Создает структуру каталога проета Django с указанным названием в текущем каталоге, или в котором вы укажите.
По умолчанию новый каталог содержит manage.py и пакет проекта (содержащий settings.py и другие файлы). Подробности смотрите в исходниках.
Если указано только название проекта, и каталог и Python пакет проекта будет называться <projectname>, и будут созданы в текущем каталоге.
Если указать необязательный путь к каталогу, Django будет использовать его как каталог проекта, создаст в нём manage.py и пакет проекта. Можно использовать ‘.’, чтобы указать текущий каталог.
Например:
django-admin startproject myproject /Users/jezdez/Code/myproject_repo
Как и для команды startapp, опция --template позволяет указать путь или URL к шаблону проекта. Подробности смотрите в описании startapp.
Например, следующая команда будет использоваться указанный шаблон для создания проекта myproject:
django-admin startproject --template=/Users/jezdez/Code/my_project_template myproject
Django также принимает URL-ы (http, https, ftp) к архиву с шаблоном проекта, он будет автоматически загружен и распакован.
Например, используя возможность Github-а предоставлять zip-архив с кодом репозитория, вы можете использовать следующий URL:
django-admin startproject --template=https://github.com/githubuser/django-project-template/archive/master.zip myproject
Когда Django копирует файлы шаблона проекта, он может рендерить определенные файлы как шаблоны Django: все файлы с расширением, указанным опцией --extension (по умолчанию py), и файлы с названием, указанным опцией --name. При рендеринге используется template context со следующими переменными:
Все опции, переданные при вызове команды startproject (только поддерживаемые этой командой)
project_name – название проекта, указанное при вызове команды
project_directory – полный путь к созданному проекту
secret_key – случайный ключ для настройки SECRET_KEY
docs_version – версия документации: 'dev' или '1.x'
Обратите внимание на возможные проблемы при рендеринге, описанные в команде startapp.
Не рекомендуется, начиная с версии 1.7: Эта команда устарела, используйте migrate, которая включает старые функции и выполнение миграций. Теперь это просто синоним новой команды.
Синоним для migrate.
Выполняет тесты для всех установленных моделей(FIXME: models?). Смотрите Тестирование в Django.
Опция --failfast позволяет остановить выполнение тестов после первой ошибки.
Опция --testrunner позволяет указать класс исполнителя тестов, который будет использоваться для запуска тестов. Указанное значение переопределяет значение настройки TEST_RUNNER.
Опция --liveserver позволяет переопределить адрес по умолчанию для тестового сервера (используется с LiveServerTestCase). По умолчанию используется localhost:8081.
Опция --keepdb позволяет сохранить базу данных между запусками тестов. Это позволяет пропустить этапы создания и удаления базы данных, что позволяет ускорить выполнение тестов, особенно для большого количества тестов. Если тестовая база данных не существует, она будет создана при первом запуске и использоваться при последующих. Все невыполненные миграции будут применены к тестовой базе данных перед запуском тестов.
Опция --reverse позволяет отсортировать тесты в обратном порядке. Это может помочь при отладке тестов, которые не полностью изолированы и приводят к изменению окружения. Для этой опции сохранена группировка по классу.
Опция --debug-sql позволяет включить логгирование SQL для “упавших” тестов. Если --verbosity выше 2, будет логгированы запросы и успешно выполненных тестов.
Запускает сервер Django для разработки (как и runserver), используя данные из указанных фикстур.
Например:
django-admin testserver mydata.json
...выполнит следующее:
Создаст тестовую базу данных, как описано вы Тестовая база данных.
Добавит в нее данных из указанных фикстур. (Подробности о фикстурах смотрите в описании loaddata.)
Запускает сервер Django для разработки (как и runserver), сервер будет использовать созданную тестовую базу данных.
Эта команда может быть полезна в следующих случаях:
Когда вы пишете юнит тесты для представлений, вы можете использовать testserver, чтобы проверить работу страниц в браузере с тестовыми данными.
Предположим вы разрабатываете приложение и у вас есть “нетронутая” копия базы данных, с которой вы хотите работать. Вы можете сделать дамп базы в фикстуру (используя команду dumpdata), затем запустить testserver с этими данными. С тестовым сервером вы можете как угодно менять данные, зная, что все изменения применяются к тестовой базе данных.
Обратите внимание, этот сервер не определяет изменения в Python файлах (как это делает команда runserver). Однако, он отслеживает изменения в шаблонах.
Опция --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 отключить вывод в консоль.
Не рекомендуется, начиная с версии 1.7: Заменена командой check.
Проверяет все установленные модели (в соответствии с настройкой INSTALLED_APPS) и выводит ошибки валидации.
Некоторые команды доступны только в случае, если приложение django.contrib, которое реализует их, было установлено. Этот раздел описывает эти команды, сгруппированные по приложениям.
Эта команда работает только, если установлена система авторизации (django.contrib.auth).
Позволяет изменить пароль пользователя. Требует дважды ввести новый пароль для указанного пользователя. Если введённые пароли совпадают, новый пароль будет установлен. Если вы не указали пользователя, команда попытается найти пользователя с именем аналогичным текущему пользователю системы.
Опция --database позволяет указать базу данных, в которой следует искать пользователя. Если не указана, Django будет использовать default базу данных.
Пример использования:
django-admin changepassword ringo
Эта команда работает только, если установлена система авторизации (django.contrib.auth).
Создает суперпользователя (пользователь со всеми правами). Можно использовать для создания самого первого суперпользователя, или чтобы программно создавать суперпользователей.
При запуске через консоль команда потребует ввести пароль. Если выполнить команду программно, не через консоль, будет создан пользователь без пароля, он не сможет авторизоваться, пока не будет установлен пароль для него.
Вы можете указать имя пользователя и email с помощью опций --username и --email. Если одна из опций не указана, createsuperuser попросит ввести значение, при запуске команды через консоль.
Опция --database позволяет указать базу данных, в которой будет создан новый пользователь.
Вы можете унаследоваться от команды и переопределить get_input_data(), если вы хотите настроить данные для ввода и их проверку. Детали реализации и параметры вы можете найти в исходном коде. Например, это может пригодиться, если у вас есть ForeignKey в REQUIRED_FIELDS и вы хотите создавать экземпляр вместо того, чтобы указывать первичный ключ существующего связанного объекта.
Эта команда доступна только при установленном GeoDjango (django.contrib.gis).
Подробности смотрите в документации GeoDjango.
Эта команда доступна, если установлен Sitemap приложение (django.contrib.sitemaps).
Смотрите описание в документации Sitemap.
Команда доступна, если установлено приложение для работы со статикой (django.contrib.staticfiles).
Смотрите описание команды в разделе staticfiles.
Команда доступна, если установлено приложение для работы со статикой (django.contrib.staticfiles).
Смотрите описание команды в разделе staticfiles.
Каждая команда принимает ряд стандартных опций:
Пример использования:
django-admin migrate --pythonpath='/home/djangoprojects/myproject'
Добавляет указанный путь в пути поиска Python. Если опция не указан, django-admin будет использовать переменную окружения PYTHONPATH.
Обратите внимание, эта опция не обязательна при использовании manage.py, т.к. он сам устанавливает необходимые пути поиска Python.
Пример использования:
django-admin migrate --settings=mysite.settings
Опция позволяет явно указать модуль настроек, который следует использовать. Путь к модулю должен быть в Python формате, например mysite.settings. Если опция не указана, django-admin будет использовать значение переменной окружения DJANGO_SETTINGS_MODULE.
Обратите внимание, эта опция не обязательна при использовании manage.py, т.к. он использует settings.py текущего проекта.
Пример использования:
django-admin migrate --traceback
По умолчанию django-admin покажет сообщение ошибки для CommandError, и полный трейсбек для остальных ошибок. Опция --traceback указывает django-admin.py выводить полный трейсбек и для CommandError.
Пример использования:
django-admin migrate --verbosity 2
Опция --verbosity позволяет указать уровень вывода в консоль сообщений и отладочной информации для django-admin.
0 – ничего не выводить.
1 – обычный вывод (по умолчанию).
2 – подробный вывод.
3 – очень подробный вывод.
Пример использования:
django-admin sqlall --no-color
По умолчанию django-admin использует цвета для форматирования вывода. Например, ошибки выводятся красным, а для SQL запросов используется подсветка синтаксиса. Чтобы отключить цветной вывод, используйте опцию --no-color.
Следующие опции не доступны для всех команд, но используются большинством из них.
Позволяет указать базу данных, с которой команда должна работать. Если не указана, будет использоваться база данных с меткой default в настройках.
Например, выполнить дамп данных из базы данных с меткой master:
django-admin dumpdata --database=master
Позволяет исключить приложение из вывода. Например, чтобы исключить приложение auth из вывода dumpdata, выполните:
django-admin dumpdata --exclude=auth
Чтобы исключить несколько приложений, используйте --exclude несколько раз:
django-admin dumpdata --exclude=auth --exclude=contenttypes
Опция --locale или -l позволяет указать локаль, которая будет использоваться при выполнении команды.
Опция --noinput позволяет отключить все запросы на ввод, такие как просьба подтвердить действия “Are you sure?”. Полезна, если django-admin запускает не с консоли, а автоматическим скриптом.
Команды django-admin / manage.py использует цветной вывод, если терминал поддерживает ANSI-цветной вывод. Если вывод передается в другую команду через “pipe”(|), цветной выводе не будет использоваться.
Встроенная в Windows консоль не поддерживает цветной вывод. Но вы можете установить ANSICON, Django определить наличие этой библиотеки и будет использовать цветной вывод.
Вы можете настроить цвета для подсветки синтаксиса. Django предоставляет цветовых темы:
dark, удобна для терминалов, которые выводят белый текст на черном фоне. Используется по умолчанию.
light, для терминалов, которые выводят черный текст на белом фоне.
nocolor, отключает подсветку синтаксиса.
Вы можете указать цветную тему, используя переменную окружения DJANGO_COLORS. Например, чтобы использовать light тему в Unix или OS/X BASH, выполните:
export DJANGO_COLORS="light"
Вы можете указать какие цвета использовать. Django предоставляет несколько типов сообщений, для которых можно указать цвет:
error - Важная ошибка.
notice - Незначительная ошибка.
sql_field - Название поля модели в SQL.
sql_coltype - Тип поля модели в SQL.
sql_keyword - Ключевые слова SQL.
sql_table - Название модели в SQL.
http_info - 1XX HTTP Informational ответ сервера.
http_success - 2XX HTTP Success ответ сервера.
http_not_modified - 304 HTTP Not Modified ответ сервера.
http_redirect - 3XX HTTP Redirect ответ сервера, исключая 304.
http_not_found - 404 HTTP Not Found ответ сервера.
http_bad_request - 4XX HTTP Bad Request ответ сервера, исключая 404.
http_server_error - 5XX HTTP Server Error ответ сервера.
Для каждого сообщения можно указать цвет текста и фона. Доступные цвета:
Можно указать дополнительно следующие параметры:
Цвета можно указать в следующем формате:
где role – это тип сообщения, fg – цвет текста, bg – цвет фона, а каждая option – один из дополнительных параметров. Настройки для нескольких типов сообщений можно указать через точку с запятой. Например:
export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
укажет показывать ошибки мигающим желтым на синем фоне, а уведомления будут пурпурными. Все остальные сообщения будут бесцветные.
Цвета можно унаследовать от существующей цветовой темы, указав ее название в переменной. Например:
export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
укажет использовать цветы из light темы, кроме сообщений об ошибках и уведомлениях, для которых мы явно указали настройки.
В Django 1.7 добавлена поддержка цветного вывода django-admin / manage.py на Windows с использованием ANSICON.
Если вы используете Bash, вы можете установить скрипт автодополнения для Django, который находится в extras/django_bash_completion в пакете Django. Он позволяет автодополнение команд через [TAB] для django-admin и manage.py. Теперь вы можете, например...
Введите django-admin.
Нажать [TAB], чтобы увидеть все доступные команды.
Ввести sql, затем [TAB], чтобы увидеть все доступные команды, название которых начинается на sql.
Смотрите Реализация собственных команд django-admin о том, как добавить свои команды.
Чтобы выполнить команду в коде, используйте call_command.
Название команды.
Список аргументов для команды.
Список опций для команды.
Например:
from django.core import management
management.call_command('flush', verbosity=0, interactive=False)
management.call_command('loaddata', '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)
Первый синтаксис стал доступен благодаря переходу на argparse. Второй синтаксис – так работал Django раннее, передавая опция как есть в команду. Теперь используется параметр dest (который может отличаться от названия опции).
Опции, которые принимают несколько значений, передаются через список:
management.call_command('dumpdata', exclude=['contenttypes', 'auth'])
Обратите внимание, вы можете перенаправить вывод команды т.к. все команды поддерживают опции stdout и stderr. Например:
with open('/tmp/command_output') as f:
management.call_command('dumpdata', stdout=f)
Jun 02, 2016