Что такое manage py в python

Введение ⇧

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

Это непосредственно относится к написанию тестируемого кода: код, который делает много вещей, достаточно часто является чересчур сложным для тестирования. Когда я ловлю себя на мысли: «Хорошо, этот кусок кода слишком сложен, чтобы писать для него тесты — это просто не стоит потраченных усилий» — вот сигнал к тому, чтобы вернутся назад и сосредоточиться на упрощении. Тестируемый код — такой код, который позволяет просто писать для него тесты; код, в котором легко найти проблемы.

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

Моя цель — убедить вас в важности этих принципов, и предоставить примеры того, как следуя им, построить более стойкое Django-приложение. Я собираюсь последовательно пройти через процесс построения приложения для управления контактами, рассказывая про решения и стратегию тестирования, которые я использую.

Эти документы являются сочетанием заметок и примеров подготовленных для PyCon 2012, PyOhio 2012, и PyCon 2013, а также для web-разработки Eventbrite. Я все еще работаю над объединением их в один документ, но надеюсь вы найдете их полезными.

Примеры кода для этого руководства доступны на github’е. Отзывы, предложения и вопросы можете присылать на nathan@yergler.net.
Этот документ доступен на сайте, а также в форматах PDF и EPub.

Видео этого руководства с PyCon можно посмотреть на YouTube.

Глава 1. Приступая к работе ⇧

1.1. Ваша среда разработки

Изоляция означает, что вы не сможете случайно воспользоватся инструментами или пакетами установленными вне вашего окружения. Это особенно важно, когда подобное происходит с чем-то, похожим на пакеты Python с расширениями написанными на C: если вы используете что-то установленное на системном уровне и не знаете об этом, то при развертывании или распространении своего кода вы можете обнаружить, что он работает не так как предполагалось. Инструменты наподобие virtualenv могут помочь создать нечто похожее на изолированную среду.

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

1.1.1. Изоляция

• Мы хотим избежать использования неизвестных зависимостей или неизвестных версий. предоставляет простой путь для работы над проектом, без использования системных site-packages.

1.1.2. Предопределенность

• Предопределенность означает управление зависимостями.
• Выберете один из инструментов и используйте как при разработке, так на «боевом» сервере:
  и специальные файлы зависимостей; ; в setup.py .

  1.1.3. Сходство

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

  1.2. Настройка вашего окружения

  1.2.1. Создание чистого рабочего пространства

  Примечание переводчика:
  Для начала создадим каталог ( tutorial ), в котором будем работать:

  В каталоге venv будет находится наше виртуальное окружение, а в каталоге project — Django-проект

  1.2.2. Создание файла зависимостей

  Создайте файл requirements.txt в директории tutorial с единственной строкой (зависимостью) в нем:

  1.2.3. Установка зависимостей

  А теперь мы можем использовать pip для установки зависимостей:

  1.3. Начало проекта Django

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

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

  HTTP-скаффолдинг управляет, например, преобразованием HTTP-запроса в объект языка Python, а также предоставляет инструменты для более простого создания серверных ответов. Скаффолдинг файловой системы иной: это набор соглашений по организации вашего кода. Эти соглашения облегчают добавление новых инженеров в проект, так как инженеры (гипотетически) уже понимают как организован код. В терминах Django, проект — это конечный продукт, и он объединяет внутри себя одно или несколько приложений . В Django 1.4 было изменено то, как проекты и приложения размещаются на диске, что облегчило разъединение и повторное использование приложений в разных проектах.

  1.3.1. Создание проекта

  Django устанавливает в систему скрипт django-admin.py для обработки задач скаффолдинга. Для создания файлов проекта используется задача startproject . Мы определим имя проекта и имя директории, в которой хотим разместить проект. Так как, мы уже находимся в изолированной среде, можно просто написать:

  /tutorial/project/ и в дальнейшем будем работать только из этой директории (под $ далее будем подразумевать

  Созданный проект имеет следующую структуру

  1.3.2. Скаффолдинг проекта

  • manage.py — является ссылкой на скрипт django-admin , но с уже предустановленными переменными окружения, указывающими на ваш проект, как для чтения настроек оттуда, так и для управления им при необходимости;
  • settings.py — здесь находятся настройки вашего проекта. Файл уже содержит несколько разумных настроек, но база данных не указана;
  • urls.py — содержит URL’ы для маппирования (отображения) представлений: мы вскоре (в дальнейших главах) поговорим об этом подробнее;
  • wsgi.py — это WSGIобёртка для вашего приложения. Этот файл используется сервером разработки Django и возможно другими контейнерами, такими как mod_wsgi , uwsgi и др. на «боевом» сервере.

  1.3.3. Создание приложения

  Созданное приложение имеет следующую структуру:

  • Начиная с Django 1.4, приложения размещаются внутри пакета с проектом. Это замечательное улучшение, особенно когда приходит время разворачивать проект на «боевом» сервере;
  • models.py будет содержать Django ORM-модели для вашего приложения;
  • views.py будет содержать код представлений;
  • tests.py будет содержать написанные вами модульные и интеграционные тесты.
  • Django 1.7: admin.py будет содержать модель для административного интерфейса.
  • Django 1.7: migrations/ содержит файлы миграций

  /tutorial/ содержит файл зависимостей ( requirements.txt ), директорию с виртуальным окружением ( venv/ ), один проект ( project/addressbook ), одно приложение ( project/contacts ) и имеет следующее содержание:

  Глава 2. Используем модель ⇧

  2.1. Конфигурирование базы данных

  Django поддерживает «из коробки» MySQL, PostgreSQL, SQLite3 и Oracle. SQLite3 входит в состав Python начиная с версии 2.5, так что мы будем использовать его в нашем проекте (для простоты). Если вы хотите, к примеру, использовать MySQL, то нужно добавить mysql-python в ваш requirements.txt .

  Для того чтобы в качестве базы данных использовать SQLite, отредактируйте определение DATABASES в файле addressbook/settings.py . Файл settings.py содержит настройки Django для нашего проекта. В нем есть несколько настроек, которые вы обязаны указать — например DATABASES — а так же другие, необязательные, настройки. Django устанавливает некоторые настройки сам, когда генерирует проект. Документация содержит полный список настроек. К тому же вы можете добавить свои собственные настройки, если это необходимо.

  Для использования SQLite нам нужно указать движок ( ENGINE ) и имя базы ( NAME ). SQLite интерпертирует имя базы как имя файла для базы данных:

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

  Вам редко придется непосредственно импортировать файл настроек: Django импортирует его за вас, и делает настройки доступными как django.conf.settings . Вы, как правило, импортируете настройки из django.conf :

  2.2. Создание модели

  Модели Django отображают (грубо говоря) таблицы базы данных, и предоставляют место для инкапсулирования бизнес-логики. Все модели являются наследниками базового класса Model и содержат поля определений. Давайте создадим простую модель Contacts для нашего приложения в файле contacts/models.py :

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

  После того, как вы создали модель, необходимо дополнить вашу базу данных новыми таблицами. Команда Django syncdb смотрит установленные модели и создает (если нужно) таблицы для них:

  Примечание переводчика:
  Если вы используете Django версии 1.7 и выше — вывод будет следующий:

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

  Настройка INSTALLED_APPS содержит список приложений, используемых в проекте. Этот список содержит в себе строки, которые отображают пакеты Python. Django будет импортировать каждый из указанных пакетов, а потом смотреть модуль models . Давайте добавим наше приложение contacts в настройки проекта ( addressbook/settings.py ):

  После этого запустите syncdb снова:

  Примечание переводчика:
  Вывод для Django 1.7 и выше:

  Заметьте, что Django создает таблицу с именем contacts_contact : по умолчанию Dj ango дает таблицам имена используя комбинацию имени приложения и имени модели. Вы можете изменить это с помощью опций модели Meta.

  2.3. Взаимодействие с моделью

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

  Здесь использовалось несколько новых штук. Во-первых, команда manage.py shell запускает для нас интерактивную оболочку Python’а с правильно установленными путями для Django. Если вы попробуете запустить интерпретатор Python и просто импортировать ваше приложения, будет выброшено исключение, потому что Django не знает, какие настройки использовать, и не может отобразить экземпляры модели на базу данных.

  Во-вторых, здесь использовалось свойство objects нашей модели. Это менеджер модели. Так, если один экземпляр модели является аналогией для строки в базе, то менеджер модели — аналогией для таблицы. По умолчанию менеджер модели предоставляет функциональность запросов и может быть настроен. Когда мы вызываем all() , filter() или сам менеджер, возвращается объект QuerySet . QuerySet является итерируемым объектом и загружает данные из базы по необходимости.

  И последнее — выше использовалось поле с именем id , которое мы не определяли в нашей модели. Django добавляет это поле как первичный ключ для модели, но только в том случае если вы сами не определили какое поле будет первичным ключом.

  2.4. Написание тестов

  Вы можете запустить тесты для вашего приложения используя команду manage.py test :

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

  Если же вы захотите запустить тесты для определенного приложения — укажите имя приложения в команде:

  Еще одна интересная вещь на заметку, прежде чем двигаться дальше — первая и последняя строка вывода: Creating test database и Destroying test database . Некоторым тестам необходим доступ к базе данных, и поскольку мы не хотим мешать тестовые данные с «реальными» (по разным причинам, не последней из которых является предопределенность), Django услужливо создает тестовую базу для нас, прежде чем запускать тесты. По существу, создается новая база данных, и потом запускается syncdb для нее. Если тестовый класс является потомком класса TestCase (как у нас), Django так же сбросит данные в значения по умолчанию после запуска каждого теста, так что изменения в одном из тестов не затронут другие.

  2.5. Резюме

  • Модель определяет поля в таблице, и содержит бизнес-логику.
  • Команда syncdb создает таблицы в вашей базе данных из моделей. В Django версии 1.7 и выше вместо команды syncdb необходимо использовать сначала команду makemigrations — для создания миграций, а после этого команду migrate — для внесение изменений в базу.
  • Менеджер модели позволяет вам оперировать коллекциями экземпляров: запросы, создание и т. д..
  • Пишите модульные тесты для методов, которые вы добавили в модель.
  • Команда управления test запускает модульные тесты на выполнение.

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

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

  An Introduction To Django¶

  A quick introduction to the basics of Django projects, apps and Models.

  Starting a Project¶

  Everything in Django stems from the project

  When you install Django into a virtualenv, it provides a utility script, django-admin.py . This script can be used to create a new project:

  Project Structure¶

  Running this command will create a folder called ‘mysite’. It contains the following structure:

  If after running the command you see a structure different than this, you’ll want to check the version of Django you installed. It should be 1.6.5.

  Here’s what you have:

  • outer *mysite* folder: this is just a container and can be renamed or moved at will
  • inner *mysite* folder: this is your project directory. It should not be renamed.
  • __init__.py: magic file that makes mysite a python package.
  • settings.py: file which holds configuration for your project, more soon.
  • urls.py: file which holds top-level URL configuration for your project, more soon.
  • wsgi.py: binds a wsgi application created from your project to the symbol application
  • manage.py: a management control script.

  django-admin.py vs. manage.py ¶

  django-admin.py provides a hook for administrative tasks and abilities:

  • creating a new project or app
  • running the development server
  • executing tests
  • entering a python interpreter
  • entering a database shell session with your database
  • much much more (run django-admin.py without an argument)

  manage.py wraps this functionality, adding the full environment of your project.

  When you look in the manage.py script Django created for you. You’ll see this:

  The environmental var DJANGO_SETTINGS_MODULE is how the manage.py script is made aware of your project’s environment.

  This is why you shouldn’t rename the project package.

  Since manage.py contains information about your specific environment, it is the tool you should use to run the development server:

  Django runs on port 8000 by default. Once it starts, you can view a new project by loading http://localhost:8000/ . You should see this:

  

  Django and Databases¶

  Django is really strongly tied to the idea of a database-driven application.

  You can create a Django site without a database, but that falls under the sin of fighting the framework, don’t do it.

  You must provide connection information for the database you use through Django configuration.

  All Django configuration takes place in settings.py in your project folder.

  In settings.py, add the following to connect to a postgres DB via psycopg2:

  Note that you will need to use createdb to create the postgresql database you intend to use before Django can use it.

  You can designate more than one database, if needed. The settings for all databases are formatted as a dictionary of dictionaries:

  As with any other framework, you have to start by initializing the database so it has the right tables.

  In Django, this is done with the syncdb command:

  You can (and should) add your superuser at this prompt.

  I usually use ‘admin’ and ‘admin’ for the username and password while playing.

  If you choose a fancy name and password and then forget them, or if you forget to create one when initializing your database, you can always create a new superuser by using the createsuperuser manage.py subcommand:

  Django Apps¶

  The app is Django’s top-level unit of work.

  Projects vs. Apps¶

  We’ve created a Django project. In Django a project represents a whole website:

  • global configuration settings
  • inclusion points for additional functionality
  • master list of URL endpoints

  A Django app encapsulates a unit of functionality:

  • A blog section
  • A discussion forum
  • A content tagging system

  One project can (and likely will) consist of many apps. Apps are made available to a project by including them in the INSTALLED_APPS setting in the active settings.py file.

  Django already includes some apps for you.

  You can extend your Django site by creating an app of your own or by installing apps created by other Django programmers.

  As stated above, an app represents a unit of work within a system, the project. Once you have a project, you can create an app. This is accomplished using manage.py .

  This should leave you with the following structure:

  Installing Your App¶

  Extending Django with your app is accomplished by installing. This is pretty simple:

  Once your app is in this list, you can begin defining your data model by adding the models you will want.

  The Django ORM¶

  As stated above, Django is predicated on interactions with a database.

  To simplify those interactions, Django uses an ORM (Object Relational Mapper).

  The purpose of an ORM is to map the attributes of a software object onto the rows of a relational database.

  The ORM is an abstraction of the database itself, and having it allows you to:

  • Work with objects without needing to know SQL
  • Use different databases without caring about syntax variations

  Django Models¶

  An ORM works by representing database tables as objects. In Django these are called models.

  The other well-known Python ORM, sqlalchemy , uses the same concept, but calls it a declarative_base .

  Flask-Sqlalchemy masks this difference by returning the model language.

  Any Python class in Django that is meant to be persisted must inherit from the Django Model class.

  This base class hooks in to the ORM functionality converting Python code to SQL.

  Learn more about models.

  Models must be defined in the models.py Python module in your app.

  As an example, consider a model similar to the one you created for your learning journal project:

  This creates a subclass of the Django base Model class. These few first attributes are instances of types of Django Model Fields.

  Model Fields¶

  • Field classes are defined in Django (or in add-on packages)
  • Field attributes on a model map to columns in a database table
  • The arguments you provide to each Field customize how it works
    • This means both how it operates in Django and how it is defined in SQL

    There are some features of our fields worth mentioning in specific.

    For example, we have no field that is designated as the primary key.

    • You can make a field the primary key by adding primary_key=True in the arguments
    • If you do not, Django will automatically create one. This field is always called id
    • No matter what the primary key field is called, its value is always available on a model instance as the pk attribute.

    The required max_length argument is specific to CharField fields.

    It affects both the Python and SQL behavior of a field.

    In python, it is used to validate supplied values during model validation

    In SQL it is used in the column definition: VARCHAR(128)

    Django also models SQL relationships as specific field types.

    The required positional argument is the class of the related Model.

    By default, the reverse relation is implemented as the attribute <fieldname>_set .

    You can override this naming behavior by providing the related_name argument. You can also prevent the reverse lookup through customization.

    auto_now_add is available on all date and time fields. It sets the value of the field to now when an instance is first saved.

    auto_now is similar, but sets the value anew each time an instance is saved.

    Setting either of these will cause the editable attribute of a field to be set to False .

    The argument blank is shared across all field types. The default is False

    This argument affects only the Python behavior of a field, determining if the field is required

    The related null argument affects the SQL definition of a field: is the column NULL or NOT NULL

    It is generally advised that you not use null for text-type fields. This allows Django to by-default provide an empty string if blank input is allowed.

    Initializing Your Tables¶

    Once your models are set, you have to create the database tables they define. This is accomplished in the same basic way as for the pre-installed apps:

    Django has now created a table for the new model. Notice that the table name is a combination of the name of the app and the name of the model. You can manually determine the names of the tables, but it’s not suggested.

    Django and WSGI¶

    As with Flask and other modern Python web frameworks, Django operates as a WSGI application.

    Let’s take a moment to trace how that works.

    WSGI Plumbing¶

    In your project, you’ll find a file called wsgi.py . Open it and you’ll find the following code:

    That points us to a functon called get_wsgi_application in the django.core package.

    Again, it would appear that the application is a class instance. It must be callable. Let’s look it up:

    Next Steps¶

    Tonight, you’ll explore the basics of Django further by walking through the Django Tutorial.

    As you go along, pay attention to how the steps you take are similar to (and different from) working in Flask.

    In our next session, we’ll begin defining models for our class Django project, a photo-sharing site with features like Flickr or Instagram.

    django-admin and manage.py

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

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

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

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

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

    Usage

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

    Получение справки о прогоне

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

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

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

    App names

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

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

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

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

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

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

    Available commands

    check

    Использует систему проверки системы, чтобы проверить весь проект Django на наличие общих проблем.

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

    —tag TAGS, -t TAGS

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

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

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

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

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

    Вы можете использовать эту опцию в своей локальной среде разработки, но поскольку ваш локальный модуль настроек разработки может не иметь многих из ваших производственных настроек, вы, вероятно, захотите указать команду check в другом модуле настроек, либо установив переменную среды DJANGO_SETTINGS_MODULE , или передав параметр —settings :

    Или вы можете запустить его непосредственно в производственном или промежуточном развертывании, чтобы убедиться, что используются правильные параметры (без —settings ). Вы даже можете сделать его частью своего набора интеграционных тестов.

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

    compilemessages

    Компилирует файлы .po , созданные makemessages , в файлы .mo для использования со встроенной поддержкой gettext. Смотрите Интернационализация и локализация .

    —locale LOCALE, -l LOCALE

    Определяет локаль(ы)для обработки.Если не указано,то обрабатываются все локали.

    —exclude EXCLUDE, -x EXCLUDE

    Указывает локаль(ы),которую(ые)следует исключить из обработки.Если это не предусмотрено,никакие локали не исключаются.

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

    —ignore PATTERN, -i PATTERN

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

    createcachetable

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

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

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

    dbshell

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

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

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

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

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

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

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

    diffsettings

    Отображает различия между текущим файлом настроек и настройками Django по умолчанию (или другим файлом настроек, указанным —default ).

    Параметры, которые не отображаются по умолчанию, сопровождаются «###» . Например, настройки по умолчанию не определяют ROOT_URLCONF , поэтому за ROOT_URLCONF следует «###» в выводе diffsettings .

    Отображает все настройки, даже если они имеют значение Django по умолчанию. Такие настройки имеют префикс «###» .

    Модуль настроек для сравнения с текущими настройками.Оставьте пустым,чтобы сравнить с настройками Django по умолчанию.

    Задает выходной формат. Доступные значения: hash и unified . hash — это режим по умолчанию, который отображает вывод, описанный выше. unified отображает вывод, аналогичный diff -u . Настройки по умолчанию имеют префикс со знаком минус, за которым следует измененный параметр со знаком плюс.

    dumpdata

    Выводит на стандартный вывод все данные в базе данных,связанные с именованным приложением (приложениями).

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

    Вывод dumpdata может использоваться как ввод для loaddata .

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

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

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

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

    —exclude EXCLUDE, -e EXCLUDE

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

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

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

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

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

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

    —output OUTPUT, -o OUTPUT

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

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

    Fixtures compression

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

    flush

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

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

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

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

    inspectdb

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

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

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

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

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

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

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

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

    Database-specific notes

    Oracle

    • Модели создаются для материализованных представлений, если используется —include-views .

    PostgreSQL

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

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

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

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

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

    loaddata

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

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

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

    Определяет одно приложение для поиска исправлений,а не во всех приложениях.

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

    —exclude EXCLUDE, -e EXCLUDE

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

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

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

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

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

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

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

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

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

    будет искать любой прибор любого типа, называемый mydata . Если каталог приборов содержит mydata.json , этот прибор будет загружен как прибор 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 , поскольку экземпляр содержит только атрибуты, которые являются локальными для модели. Вы можете, например, захотеть отключить обработчики, которые обращаются к связанным полям, которые отсутствуют во время загрузки фикстуры и в противном случае вызвали бы исключение:

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

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

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

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

    Compressed fixtures

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

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

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

    MySQL с MyISAM и исправлениями

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

    Database-specific fixtures

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

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

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

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

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

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

    makemessages

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

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

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

    —extension EXTENSIONS, -e EXTENSIONS

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

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

    —locale LOCALE, -l LOCALE

    Определяет локаль(ы)для обработки.

    —exclude EXCLUDE, -x EXCLUDE

    Указывает локаль(ы),которую(ые)следует исключить из обработки.Если это не предусмотрено,никакие локали не исключаются.

    —domain DOMAIN, -d DOMAIN

    Указание домена файлов сообщений.Поддерживаются следующие опции:

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

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

    —ignore PATTERN, -i PATTERN

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

    Эти шаблоны используются по умолчанию: ‘CVS’ , ‘.*’ , ‘*

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

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

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

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

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

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

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

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

    makemigrations

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

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

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

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

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

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

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

    —name NAME, -n NAME

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

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

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

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

    migrate

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

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

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

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

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

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

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

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

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

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

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

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

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

    optimizemigration

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

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

    runserver

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Добавлена поддержка параметра —skip-checks .

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

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

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

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

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

    Порт 8000 по адресу IPv6 ::1 :

    Порт 7000 по адресу IPv6 ::1 :

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

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

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

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

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

    sendtestemail

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

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

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

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

    shell

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

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

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

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

    —command COMMAND, -c COMMAND

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

    Вы также можете передать код на стандартный вход для его выполнения.Например:

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

    showmigrations

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

    Перечисляет все приложения, о которых Django знает, миграции, доступные для каждого приложения, и то, применяется ли каждая миграция (отмечена [X] рядом с именем миграции). Для —verbosity от 2 и выше также показаны примененные даты и время.

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

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

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

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

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

    sqlflush

    Печатает операторы SQL, которые будут выполнены для команды flush .

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

    sqlmigrate

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

    Обратите внимание, что sqlmigrate не раскрашивает свой вывод.

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

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

    sqlsequencereset

    Распечатывает SQL-операторы для сброса последовательностей для заданного имени (имен)приложения.

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

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

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

    squashmigrations

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

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

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

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

    Устанавливает имя подавленной миграции. Если опущено, имя основывается на первой и последней миграции с _squashed_ между ними.

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

    startapp

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

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

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

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

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

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

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

    —extension EXTENSIONS, -e EXTENSIONS

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

    —name FILES, -n FILES

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

    —exclude DIRECTORIES, -x DIRECTORIES

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

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

    • Любой параметр, переданный команде startapp (среди поддерживаемых параметров команды)
    • app_name — имя приложения, переданное команде
    • app_directory — полный путь к только что созданному приложению
    • camel_case_app_name — название приложения в формате верблюжьего регистра .
    • docs_version — версия документации: ‘dev’ или ‘1.x’
    • django_version — версия Django, например ‘2.0.3’

    Когда файлы шаблонов приложения отображаются с помощью механизма шаблонов Django (по умолчанию все файлы *.py ), Django также заменит все переменные шаблона. Например, если один из файлов Python содержит строку документации, объясняющую конкретную функцию, связанную с отображением шаблона, это может привести к неверному примеру.

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

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

    startproject

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

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

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

    Если указано необязательное место назначения, Django будет использовать этот существующий каталог в качестве каталога проекта и создаст в нем manage.py и пакет проекта. Использовать ‘.’ для обозначения текущего рабочего каталога.

    Указывает каталог, путь к файлу или URL пользовательского шаблона проекта. Посмотрите документацию startapp —template для примеров и использования.

    —extension EXTENSIONS, -e EXTENSIONS

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

    —name FILES, -n FILES

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

    —exclude DIRECTORIES, -x DIRECTORIES

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

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

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

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

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

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

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

    Варианты тестовых бегунов

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

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

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

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

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

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

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

    —parallel [N] DJANGO_TEST_PROCESSES

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    testserver

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

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

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

    Это полезно во многих отношениях:

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

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

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

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

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

    Для запуска на 1.2.3.4:7000 с test прибором :

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

    Что такое manage py в python

    

    Python Django is a web framework that is used to create web applications very efficiently and quickly. Django is called a battery included framework because it contains a lot of in-built features such as Django Admin Interface, default database – SQLite3, etc. Django provides various ready-made components such as a way to handle user authentication, a management panel for your website, forms, a way to upload files, etc.

    In this article, we will learn Django by creating a basic blogging web application.

    Why Django Framework?

    • Django is a rapid web development framework that can be used to develop fully fleshed web applications in a short period of time.
    • It’s very easy to switch databases in the Django framework.
    • It has a built-in admin interface which makes it easy to work with it.
    • Django is a fully functional framework that requires nothing else.
    • It has thousands of additional packages available.
    • It is very scalable.

    Structure of Django Web Application

    Django is based on MVT (Model-View-Template) architecture. MVT is a software design pattern for developing a web application.

    The model is going to act as the interface of your data. It is responsible for maintaining data. It is the logical data structure behind the entire application and is represented by a database (generally relational databases such as MySql, Postgres). The View is the user interface — what you see in your browser when you render a website. It is represented by HTML/CSS/Javascript and Jinja files. A template consists of static parts of the desired HTML output as well as some special syntax describing how dynamic content will be inserted.

    

    Setting the Development Environment

    It is always advisable to use a virtual environment before starting any Django project because sometimes when you are working on multiple projects you might need different versions of Django. The virtual environment creates a separate environment for different projects and you can install dependencies of each project separately. To create a virtual environment type the below command in the terminal –

    Here the name is the name of the virtual environment. We can give any name to our environment. Let’s create the virtual environment with the name as venv only. So the command to create the environment will be –

    After running the above command you will see a folder named venv with the following sub-directories.

    

    After creating the virtual environment let’s activate it. To activate it type the below command in the terminal.

    Note: If you have your virtual environment set up in another location and your terminal opened up in another location, then provide the location to the venv folder i.e. our virtual environment folder.

    After you run the above command you should see (venv) at the starting of every line of your terminal as shown in the below image.

    

    Installing Django

    We can install Django using the pip command. To install this type the below command in the terminal.

    

    Starting the Project

    • To initiate a project of Django on Your PC, open Terminal and Enter the following command
    • A New Folder with the name projectName will be created. To enter in the project using the terminal enter command
    • Now let’s run the server and see everything is working fine or not. To run the server type the below command in the terminal.

    After running the server go to http://127.0.0.1:8000/ and you’ll see something like this –

    

    Project Structure

    A Django Project when initialized contains basic files by default such as manage.py, view.py, etc. A simple project structure is enough to create a single-page application. Here are the major files and their explanations. Inside the geeks_site folder ( project folder ) there will be the following files-

    

    Let’s discuss these files in detail –

    manage.py: This file is used to interact with your project via the command line(start the server, sync the database… etc). For getting the full list of commands that can be executed by manage.py type this code in the command window-

    • _init_.py: It is a python package. It is invoked when the package or a module in the package is imported. We usually use this to execute package initialization code, for example for the initialization of package-level data.
    • settings.py: As the name indicates it contains all the website settings. In this file, we register any applications we create, the location of our static files, database configuration details, etc.
    • urls.py: In this file, we store all links of the project and functions to call.
    • wsgi.py: This file is used in deploying the project in WSGI. It is used to help your Django application communicate with the webserver.

    Creating App

    Till now we have created the Django project and now we will create an app. Django is famous for its unique and fully managed app structure. For every functionality, an app can be created like a completely independent module. To create an app we need to go to the directory containing manage.py and run the following command –

    Now let’s create an app called post, so the command to create the app would be –

    Now our directory looks like this –

    

    To consider the project i our project we need to specify the project name in the INSTALLED_APPS list in settings.py –

    Python3

    Defining Models

    Now for the post app, we need some models. A Django model is the built-in feature that Django uses to create tables, their fields, and various constraints. In short, Django Models is the SQL of Database one uses with Django. SQL (Structured Query Language) is complex and involves a lot of different queries for creating, deleting, updating, or any other stuff related to the database. Django models simplify the tasks and organize tables into models. Generally, each model maps to a single database table.

    Syntax:

    Example:

    Python3

    In the above model, each field represents a column in the SQLite database. We have also created a foreign key for the User model. The user model comes built-in with Django.

    Note: The on_delete=models.CASCADE command will delete all the posts of an author if the profile for that author is deleted.

    Whenever we create a Model, Delete a Model, or update anything in any of models.py of our project. We need to run two commands makemigrations and migrate. makemigrations basically generates the SQL commands for preinstalled apps (which can be viewed in installed apps in settings.py) and your newly created app’s model which you add in installed apps whereas migrate executes those SQL commands in the database file.

    SQL Query to create the above Model as a Table is created. We can see this under the migrations folder as 0001_initial.py.

    

    To create the table in the database type

    Now we have created a model we can perform various operations such as creating a Row for the table or in terms of Django Creating an instance of Model. To know more visit – Django Basic App Model – Makemigrations and Migrate.

    Render Model in Django Admin

    After creating the model we need to add data from to our model. We can add data in two ways. These are –

    • Django Shell
    • Django Admin

    In this article, we will focus on rendering model data through Admin Interface. If you want to learn about rendering data through Django Shell refer to Django ORM – Inserting, Updating & Deleting Data.

    We need to create a superuser for our web application that will access the admin panel. To create a superuser type the below command in the terminal –

    

    Now go to http://127.0.0.1:8000/admin on the browser to access the admin interface panel.

    

    Give the username and password created for the superuser and then the admin dashboard will open.

    

    To render our model onto our admin panel we need to make changes to the post/admin.py file. Enter the following code to the admin.py file –

    Python3

    Refreshing your admin panel will let you see the model that we created.

    

    Note: For more information refer to Render Model in Django Admin Interface.

    Let’s add some data to our database. Clicking on the Geeks Model we will see something like this –

    

    We can click on the Add Post button on the right top corner and then we will be able to see the fields for adding data. See the below image –

    

    After adding the required data we will see something like this on our admin dashboard –

    

    Django Views

    After creating and adding data to our models, we need to display the data to our site. Rendering data is a two-step process. First we need to create our view function and then we need to pass the data to our template. Here we will focus on the view function.

    A view function is a Python function that takes a Web request and returns a Web response. This response can be the HTML contents of a Web page, or a redirect, or a 404 error, or an XML document, or an image, anything that a web browser can display. Django views are part of the user interface — they usually render the HTML/CSS/Javascript in your Template files into what you see in your browser when you render a web page.

    

    At first, let’s create a sample view function that will simply show normal HTML content.

    Python3

    Let’s step through this code one line at a time:

    • First, we import the class HttpResponse from the django.http module, along with Python’s datetime library.
    • Next, we define a function called home. This is the view function. Each view function takes an HttpRequest object as its first parameter, which is typically named request.
    • The view returns an HttpResponse object that contains the generated response. Each view function is responsible for returning an HttpResponse object.

    The above Function will render the text Welcome to GeeksforGeeks as h1 on the page. Now the question that may be arising is at what URL this function will be called and how will we handle such URLs. Don’t worry we will handle URL in the section but in this section let us continue with the Django views only.

    Types of Views

    Django views are divided into two major categories:-

    • Function-Based Views
    • Class-Based Views

    

    Function-Based Views

    Function-based views are writer using a function in python which receives as an argument HttpRequest object and returns an HttpResponse object. Function-based views are generally divided into 4 basic strategies, i.e., CRUD (Create, Retrieve, Update, Delete). CRUD is the base of any framework one is using for development. The one we created above is a function-basedClass-Based Views

    Class-Based Views

    Class-based views provide an alternative way to implement views as Python objects instead of functions. They do not replace function-based views, but have certain differences and advantages when compared to function-based views:

    • Organization of code related to specific HTTP methods (GET, POST, etc.) can be addressed by separate methods instead of conditional branching.
    • Object-oriented techniques such as mixins (multiple inheritances) can be used to factor code into reusable components. view.

    Django URL Patterns

    In Django, each view needs to be mapped to a corresponding URL pattern. This is done via a Python module called URLConf(URL configuration). Every URLConf module must contain a variable urlpatterns which is a set of URL patterns to be matched against the requested URL. These patterns will be checked in sequence until the first match is found. Then the view corresponding to the first match is invoked. If no URL pattern matches, Django invokes an appropriate error handling view.

    Похожие публикации:

    1. Df iloc python как работает
    2. Import glob python что это
    3. Keyword arguments python что это
    4. Np allclose python 3 описание как работает