Django обмен с 1с
Обновлено: 04.07.2024
Продолжаем начатое в первой части учебника. Мы настроим базу данных, создадим свою первую модель и посмотрим на автоматически созданный интерфейс администратора.
Настройка базы данных¶
Теперь откроем файл mysite/settings.py . Это обычный модуль Python с набором переменных, которые представляют настройки Django.
По умолчанию в настройках указано использование SQLite. Если вы новичок в базах данных, или просто хотите попробовать Django, это самый простой выбор. SQLite уже включен в Python, и вам не нужно дополнительно что-то устанавливать. Однако, создавая свой первый настоящий проект, вам понадобиться более серьезная база данных, например PostgreSQL.
Если вы хотите использовать другую базу данных, установите необходимые библиотеки и поменяйте следующие ключи в элементе 'default' настройки DATABASES , чтобы они соответсвовали настройкам подключения к вашей базе данных:
Если вы используете не SQLite,вам необходимо указать дополнительно USER , PASSWORD и HOST . Подробности смотрите в описании DATABASES .
Если вы используете SQLite, вам ничего не нужно создавать заранее - файл базы данных будет создан автоматически при необходимости.
Отредактируйте mysite/settings.py и укажите в TIME_ZONE ваш часовой пояс.
Также обратите внимание на настройку INSTALLED_APPS в начале файла. Она содержит названия всех приложений Django, которые активированы в вашем проекте. Приложения могут использоваться на разных проектах, вы можете создать пакет, распространить его и позволить другим использовать его на своих проектах.
По умолчанию, INSTALLED_APPS содержит следующие приложение, которые предоставляются Django:
Эти приложения включены по умолчанию для покрытия основных задач.
Некоторые приложения используют минимум одну таблицу в базе данных, поэтому нам необходимо их создать перед тем, как мы будем их использовать. Для этого выполним следующую команду:
Как мы сказали выше, приложения по умолчанию включены для большинства случаев, но не все они могут быть необходимы. Если какое-то приложение вам не нужно, закомментируйте или удалите соответствующие строки из INSTALLED_APPS перед запуском migrate . Команда migrate выполнит миграции только для приложений из INSTALLED_APPS .
Создание моделей¶
Модель - это основной источник данных. Он содержит набор полей и поведение данных, которые вы храните. Django следует принципу DRY .. Смысл в том, чтобы определять модели в одном месте.
Частью работы с данными также являются миграции. В отличии от Ruby On Rails, например, миграции вынесены из файла моделей и являются просто историей, которую Django может использовать для изменения базы данных в соответствии с текущей структурой моделей.
В нашем простом приложении голосования, мы создадим две модели: Question и Choice . Question содержит вопрос и дату публикации. Choice содержит: текст ответа и количество голосов. Каждый объект Choice связан с объектом Question .
Эти понятия отображаются простыми классами Python. Отредактируйте файл polls/models.py , чтобы он выглядел таким образом:
Код очень простой. Каждая модель представлена классом, унаследованным от django.db.models.Model . Каждая модель содержит несколько атрибутов, каждый из которых отображает поле в таблице базы данных.
Некоторые классы, унаследованные от Field , имеют обязательные аргументы. Например, CharField требует, чтобы вы передали ему max_length . Это используется не только в схеме базы данных, но и при валидации, как мы скоро увидим.
Field может принимать различные необязательные аргументы; в нашем примере мы указали default значение для votes` равное 0.
Заметим, что связь между моделями определяется с помощью ForeignKey . Это указывает Django, что каждый Choice связан с одним объектом Question . Django поддерживает все основные типы связей: многие-к-одному, многие-ко-многим и один-к-одному.
Активация моделей¶
Эта небольшая часть кода моделей предоставляет Django большое количество информации, которая позволяет Django:
Создать структуру базы данных ( CREATE TABLE ) для приложения.
Создать Python API для доступа к данным объектов Question и Choice .
Но первым делом мы должны указать нашему проекту, что приложение polls установлено.
Отредактируйте файл mysite/settings.py и измените настройку INSTALLED_APPS добавив строку 'polls' . В результате получим:
Теперь Django знает, что необходимо использовать приложение polls . Давайте выполним следующую команду:
Вы увидите приблизительно такое:
Выполняя makemigrations , вы говорите Django, что внесли некоторые изменения в ваши модели (в нашем случае мы создали несколько новых) и хотели бы сохранить их в миграции.
Миграции используются Django для сохранения изменений ваших моделей (и структуры базы данных) - это просто файлы на диске. Вы можете изучить миграцию для создания ваших моделей, она находится в файле polls/migrations/0001_initial.py . Не волнуйтесь, вам не нужно каждый раз их проверять. Но их формат удобен для чтения на случай, если вы захотите внести изменения.
В Django есть команда, которая выполняет миграции и автоматически обновляет базу данных - она называется migrate . Мы скоро к ней вернемся, но сначала давайте посмотрим какой SQL выполнит эта миграция. Команда sqlmigrate получает название миграции и возвращает SQL:
Вы увидите приблизительно такое (мы отформатировали результат для читабельности):
Обратите внимание на следующее:
Полученные запросы зависят от базы данных, которую вы используете. Пример выше получен для PostgreSQL.
Первичные ключи (ID) добавлены автоматически. (Вы можете переопределить и это.)
Django добавляет "_id" к названию внешнего ключа. (Да, вы можете переопределить и это.)
Связь явно определена через FOREIGN KEY constraint. Не волнуйтесь о DEFERRABLE , это просто указание для PostgreSQL не применять ограничения FOREIGN KEY до окончания транзакции.
Команда sqlmigrate не применяет миграцию к базе данных - она просто выводит запросы на экран, чтобы вы могли увидеть какой SQL создает Django. Это полезно, если вы хотите проверить что выполнит Django, или чтобы предоставить вашему администратору базы данных SQL скрипт.
Если необходимо, можете выполнить python manage.py check . Эта команда ищет проблемы в вашем проекте не применяя миграции и не изменяя базу данных.
Теперь, выполните команду migrate снова, чтобы создать таблицы для этих моделей в базе данных:
Команда migrate выполняет все миграции, которые ещё не выполнялись, (Django следит за всеми миграциями, используя таблицу в базе данных django_migrations ) и применяет изменения к базе данных, синхронизируя структуру базы данных со структурой ваших моделей.
Миграции - очень мощная штука. Они позволяют изменять ваши модели в процессе развития проекта без необходимости пересоздавать таблицы в базе данных. Их задача изменять базу данных без потери данных. Мы ещё вернемся к ним, а пока запомните эти инструкции по изменению моделей:
Внесите изменения в модели (в models.py ).
Выполните python manage.py makemigrations чтобы создать миграцию для ваших изменений
Выполните python manage.py migrate чтобы применить изменения к базе данных.
Две команды необходимы для того, чтобы хранить миграции в системе контроля версий. Они не только помогают вам, но и могут использоваться другими программистами вашего проекта.
О всех возможностях manage.py вы можете прочитать в разделе о django-admin.
Поиграемся с API¶
Теперь, давайте воспользуемся консолью Python и поиграем с API, которое предоставляет Django. Чтобы запустить консоль Python выполните:
Запуск без manage.py
Если вы не желаете использовать manage.py , не проблема. Просто установите переменную окружения DJANGO_SETTINGS_MODULE в mysite.settings , запустите интерпретатор Python и инициализируйте Django:
Если вы получили исключение AttributeError , возможно вы используете версию Django, которая не соответствует этому учебнику. Вам следует читать старую версию учебника или обновить Django.
Запустить python необходимо в каталоге, в котором находится файл manage.py (или убедитесь, что каталог находится в путях Python, и import mysite работает).
Полную информацию обо всем этом смотрите в разделе о django-admin.
Теперь, когда вы в консоли, исследуем API базы данных:
Важно добавить метод __str__() не только для красивого отображения в консоли, но так же и потому, что Django использует строковое представление объекта в интерфейсе администратора.
Заметим, это стандартные методы Python. Давайте добавим свой метод, просто для демонстрации:
Мы добавили import datetime и from django.utils import timezone для использования стандартной библиотеки Python datetime и модуля Django для работы с временными зонами django.utils.timezone соответственно. Если вы не знакомы, как Python работает с временными зонами, вы можете прочитать об этом в разделе о поддержке временных зон.
Сохраните эти изменения и запустите консоль Python снова, выполнив python manage.py shell :
Подробности о работе со связанными объектами смотрите в соответствующем разделе. Подробности об использовании синтаксиса двойного нижнего подчеркивания читайте в разделе о фильтрах полей . Полная информация об API для работы с базой данных содержится в соответствующем разделе.
Введение в интерфейс администратор Django¶
Django создавался для новостных сайтов, у которых есть разделение между публичными страницами и интерфейсом администратора. Менеджеры используют последний для добавления новостей и другого содержимого сайта, это содержимое отображается на сайте. Django позволяет легко создать универсальный интерфейс для редактирования содержимого сайта.
Интерфейс администратора не предназначен для использования пользователями. Он создан для менеджеров и администраторов сайта.
Создание суперпользователя¶
Первым делом необходимо создать пользователя, который может заходить на интерфейс администратора. Выполните следующую команду:
Читайте также: