Как называется встроенная база данных в django

Как называется встроенная база данных в django

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

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

Так, изменим файл models.py следующим образом:

from django.db import models class Person(models.Model): name = models.CharField(max_length=20) age = models.IntegerField()

Здесь определена простейшая модель, которая называется Person и которая представляет человека. В модели определены два поля. Поле name представляет тип CharField — текстовое поле, которое хранит последовательность символов. Оно будет хранить имя человека. Для CharField обязательно надо указать параметр max_length , который задает максимальную длину хранящейся строки. И поле age представляет тип IntegerField — числовое поле, которое хранит целые числа. Оно предназначено для хранения возраста человека.

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

Вначале необходимо создать миграцию с помощью команды

python manage.py makemigrations

После этого в приложении в папке migrations мы обнаружим новый файл, который будет иметь примерно следующее содержимое:

from django.db import migrations, models class Migration(migrations.Migration): initial = True dependencies = [ ] operations = [ migrations.CreateModel( name='Person', fields=[ ('id', models.BigAutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')), ('name', models.CharField(max_length=20)), ('age', models.IntegerField()), ], ), ]

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

Теперь надо выполнить данную миграцию. Для этого выполняется команда

python manage.py migrate

После этого, если мы откроем базу данных db.sqlite3 , которая есть в проекте, то мы увидим, что в нее добавлена таблица для хранения данных модели Person:

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

Модели

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

Настройки подключения к базе данных

По умолчанию Django в качестве базы данных использует SQLite. Она очень проста в использовании и не требует запущенного сервера. Все файлы базы данных могут легко переноситься с одного компьютера на другой. Однако при необходимости мы можем использовать в Django большинство распространенных СУБД.

Для работы с базами данных в проекте Django в файле settings.py определен параметр DATABASES , который по умолчанию выглядит следующим образом:

DATABASES = < 'default': < 'ENGINE': 'django.db.backends.sqlite3', 'NAME': BASE_DIR / 'db.sqlite3', >>

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

Конфигурация каждого подключения может состоять из ряда параметров. По умолчанию указываются только два параметра. Параметр ENGINE указывает на используемый движок для доступа к БД. В данном случае это встроенный пакет django.db.backends.sqlite3 .

Второй параметр — NAME указывает на путь к базе данных. По умолчанию база данных называется db.sqlite3 . Для установки пути используется каталог из переменной BASE_DIR, которая задана в начале файла:

BASE_DIR = Path(__file__).resolve().parent.parent

По умолчанию BASE_DIR указывает на каталог, в котором находится папка проекта. И после первого запуска проекта в указанном каталоге по умолчанию будет создан файл db.sqlite3 , который собственно и будет использоваться в качестве базы данных.

Поддерживаемые субд

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

Django ORM — Python: Разработка на фреймворке Django

Практически любое веб-приложение так или иначе работает с базой данных. При этом с системой управления базами данных (СУБД) приложение общается универсальным способом, например, посредством языка SQL.

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

ORM

ORM (Object-Relational Mapping) — отображение сущностей предметной области и их взаимосвязей в объекты, удобные для использования программистом.

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

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

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

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

Модель

Любая сущность, которая создается внутри приложения, называется моделью. Модели в Django лежат в директориях приложений в файлах models.py. Конкретный набор моделей зависит от приложения и может измениться со временем. На Хекслете таких моделей сотни, вот лишь некоторые, с которыми наши пользователи сталкиваются каждый день:

• Пользователь
• Курс
• Урок
• Профессия
• Упражнение
• Подписка
• Участник курса
• Статья в блоге
• Топик
• Комментарий к топику
• Проект

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

Слово «модель» часто используется в качестве замены словосочетания «Django ORM», поэтому в рамках курсов будет использоваться этот термин. Модель в единственном числе говорит нам о том, что наша предметная область смоделирована с помощью средств фреймворка. Это собирательный образ слоя хранения. При этом отдельные сущности тоже называются моделями — модели поменьше собираются в большую модель всей предметной области.

Связь между моделями и таблицами в базе данных: одна таблица — одна модель. В этом плане Django ORM не отходит далеко от схемы базы данных. Всегда можно представить, как фактически представлены данные с точки зрения СУБД. Что очень полезно, когда нужно что-то оптимизировать.

Database Engines

К фактической базе данных Django подключается с помощью Database Engines. Одно приложение может подключаться к нескольким базам данных. Это можно сделать и с помощью разных движков. Но такое случается нечасто. Обычно одна база приходится на одно веб-приложение.

Описываются базы данных в словаре settings.DATABASES :

DATABASES =  'default':  'ENGINE': 'django.db.backends.sqlite3', 'NAME': os.path.join(BASE_DIR, 'db.sqlite3'), > > 

• ENGINE указывает на конкретный движок
• NAME в случае SQLite хранит имя файла. Для других СУБД это будет имя базы данных в удобном для них формате
• default — имя базы данных уже для самого Django

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

Описание моделей

Модели описываются в модулях models.py. Каждое приложение имеет свой собственный модуль models.py, в котором содержатся описание моделей конкретного приложения.

Добавим в hexlet_django_blog.article.models следующий код:

from django.db import models class Article(models.Model): name = models.CharField(max_length=200) # название статьи body = models.TextField() # тело статьи timestamp = models.DateTimeField(auto_now_add=True) 

Article — это и есть наша первая модель. У нее три поля:

• timestamp — для хранения даты и времени создания записи
• name — для хранения названия статьи
• body — для хранения текста статьи

В этом случае мы не описываем поле id , которое обычно является первичным ключом. В models.Model оно уже описано, и нам не нужно это делать дополнительно. Но мы его можем переопределить.

Со стороны Python всё готово. Но еще нужно сделать так, чтобы соответствующая таблица появилась в базе данных. Для этого необходимо сгенерировать миграцию.

Миграция

Миграции меняют схему базы данных сообразно тому, как мы меняем модель. В Django работа с миграциями сделана на очень высоком уровне. В том числе — на высоком уровне автоматизации.

Чтобы получить миграцию, выполняем команду:

for 'article': hexlet_django_blog/article/migrations/0001_initial.py - Create model Article 

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

Миграции — это описания изменений в наших моделях, и в дальнейшем в схеме базы данных. Мы можем просмотреть эти файлы миграций. Они располагаются в директориях migrations внутри приложений. Например, в нашем случае файл миграции располагается в hexlet_django_blog/article/migrations/0001_initial.py.

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

Теперь посмотрим, какой SQL-запрос будет выполняться при запуске миграции. Для этого воспользуемся командой sqlmigrate :

; -- -- Create model Article -- CREATE TABLE "article_article" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "name" varchar(200) NOT NULL, "body" text NOT NULL, "timestamp" datetime NOT NULL); COMMIT; 

• Имена таблиц автоматически генерируются с помощью объединения имени приложения (article) и имени модели в нижнем регистре — article
• Поле id , которое является первичным ключом, добавляется автоматически

Применяем все остальные миграции. Эта операция идемпотентна:

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

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

Миграции можно не только накатывать, но и откатывать. Для этого нужно указать версию миграции, к которой мы хотим вернуться.

Например, в директории migrations приложения article у нас есть два файла миграции 0005_second_last_migration и 0006_last_migration. 0006 — это последняя примененная миграция.

Если нам нужно вернуться к миграции 0005 из миграции 0006, мы выполним следующую команду:

Если нам нужно отменить все миграции этого приложения, нужно указать zero в качестве версии миграции:

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

• 130 курсов, 2000+ часов теории
• 1000 практических заданий в браузере
• 360 000 студентов

Наши выпускники работают в компаниях:

Django, начало работы с базой данных

На Хабре существует много тем о django, с описанием различных вкусностей. Но мне не встречался пост, про начало пути, так сказать для новичка. Так что хочется написать короткое руководство начинающего бойца, по собственным шагам.
Cпасибо www.djbook.ru, русский перевод онлайн книги о django, именно отсюда я черпал данные для написания поста.

1. python 2.6
2. django 1.1.1
3. postgreSQL 8.4.2
4. python-psycopg2 2.0.8-0

здесь ссылка на то как установить django
Поскольку это описание собственного опыта, буду описывать всё по шагам, как делал я.

Первым шаг. Создание проекта

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

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

Второй шаг, Настройка БД

Django может работать с множеством БД, но в данном примере я использую postgresql.

• ‘postgresql_psycopg2’ — драйвер через который приложение будет выполнять запросы к БД и получать данные;
• myDBName — название БД;
• myUserDB — основной пользователь БД;
• myUserDBPasswor — пароль основного пользователя.

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

python manage.py shell

Данная команда запустит интерпретатор python с настройками проекта. В интерпретаторе проверим подключение к БД.
>>> from django.db import connection
>>> cursor = connection.cursor()

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

Третий шаг, Создание приложения.

Приложение в django — набор модели БД и представления хранящиеся в одном пакете python. Для того что бы, создать приложение, необходимо находясь в каталоге проекта выполнить команду:

python manage.py startapp MyName

Эта команда создаст директорию MyName, в каталоге проекта hellowDjango, а так же создаст файлы «заготовки» приложения в каталоге MyName.

Четвёртый шаг, Описание модели.

Модель БД в django — описание таблиц на языке python. Для создания модели приложения необходимо отредактировать файл MyName/models.py. В модели описывается много классов, каждый из которых будет описывать одну таблицу БД, а свойство класса — это один столбец таблицы. Класс должен быть унаследован от models.Model описанного в пакете django.db.models. Свойства класса должны иметь типы описанные в пакете django.db.models. Все типы данных и их применение описаны здесь.

1. models.DateTimeField() — поле содержащее в себе Дату и Время
2. models.CharField(max_length= xx) — Текстовое поле ограниченной длины. Длина строки = xx символов
3. models.BooleanField() — Поле содержащие в себе булево значение
4. models.ForeignKey() — ссылка на внешнюю таблицу
5. models.PositiveIntegerField() — положительное целое значение
6. models.URLField(max_length=хх) — ссылка на web страницу длина ссылки ограничена xx символами
7. models.DateField() — поле содержащие Дату

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

Для проверки корректности созданной модели необходимо выполнить команду:
python manage.py validate
После того как модель прошла проверку, можно посмотреть как django предложит сгенерировать таблицы. Для этого выполним ещё одну команду:
python manage.py sqlall MyName
Для создания модели в БД, выполним следующую команду:
python manage.py syncdb

Пятый шаг. Работа с БД в интерпретаторе.

Ниже представлены варианты вставки данных в БД

Запускаем интерпретатор
python manage.py shell
>>> import MyName.models as mo # импортируем все модели проекта

>>> type = mo.ProductClass() # создаём экземпляр класса Типы Продуктов
>>> type.class_name = ‘сырьё’ # название типа
>>> type.save() # записываем экземпляр в БД
>>> type
&lt ProductClass: ProductClass object&gt

# так же можно воспользоваться вставкой данных другого вида
>>> mo.Dealer(organization_name = «ООО Рога И Копыта»).save() # создаст запись в таблице Dealer
>>> mo.Dealer.objects.all() # выполняем выборку данных из таблицы Dealer
[&lt Dealer: ООО Рога И Копыта&gt] # поскольку запись в таблице только 1 то и коллекция содержит всего 1 элемент, обратиться к нему можно через индексы.

# если для создания записи будет не хватать каких либо данных вы уведите протокол ошибки. Например такой:
>>> mo.Product(name = ‘овёс’, price = 50, product_class = type).save()
Traceback (most recent call last):
.
IntegrityError: null value in column «diler_id» violates not-null constraint
>>> mo.Product(name = ‘овёс’, price = 50, product_class = type, diler = mo.Dealer.objects.all()[0]).save() # вторая запись в таблице Product

Теперь нужно поговорить о выборе данных из таблиц.

# полная выборка из таблицы
>>> mo.Product.objects.all()
[&lt Product: мука&gt, &lt Product: овёс&gt, &lt Product: рожь&gt]

# выборка по полю name
>>> mo.Product.objects.filter(name = ‘овёс’)
[&lt Product: овёс&gt]

# выборка по частичному совпадению
>>> mo.Product.objects.filter(name__contains = ‘о’)
[&lt Product: овёс&gt, &lt Product: рожь&gt]

Мы рассмотрели вставку и выборку данных.

Давайте рассмотрим варианты обновления записей.

# для того что бы провести обновление записи необходимо выполнить следующие действия
>>> item2 = mo.Product.objects.get(name = ‘овёс’)
>>> item2.name = «овёс золотистый»
>>> item2.save()

Данный пример прост но имеет свой недостаток, он выполняет обновление всех полей записи, а не только тех которые изменились. Данный факт может привести к «гонке» пользователей, когда происходит массовое изменение данных в Таблице. Для решения такой проблемы правильно будет использовать метод update. Данный метод изменяет только указанные поля.
>>> mo.Product.objects.filter(id=3).update(name=’oves’)
1
>>> cole[2]
&lt Product: oves&gt

Последнее, что хочется описать, это удаление записей из БД.

Существует два способа удаления записей:

Первый удаление всех данных из таблицы
>>> cm.Dealer.objects.all()
[&lt Dealer: ООО Рога И Копыта&gt]
>>> cm.Dealer.objects.all().delete()
>>> cm.Dealer.objects.all()
[]

Второй удаление отобранных записей
>>> cm.ProductClass.objects.all()[0].id
1
>>> cm.ProductClass.objects.filter(id=1).delete()
>>> cm.ProductClass.objects.all()
[]

Более подробно о всех командах api работы с БД и можно почитать здесь.

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