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

Опубликовал: Friday, February 17, 2024 в категории Django | Пока нет комментариев

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

Интеграция с унаследованной базой данных

Уровень доступа к базам данных в Django генерируют SQL-схемы, опираясь на программный код Python, но при работе с унаследованной базой данных схема уже существует. В подобных случаях приходится создавать модели на основе уже существующих таблиц. Для этого в составе Django имеется инструмент, умеющий генерировать программный код модели по результатам анализа структуры таблиц в базе данных. Он называется inspectdb и вызывается командой manage, ру inspectdb.

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

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

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

1.     Создайте проект Django командой django-admin.py startproject mysite (где mysite - имя проекта).

2.     Откройте в редакторе файл параметров mysite/settings.py и определите параметры соединения с базой данных, в том числе ее имя. Точнее, требуется определить параметры DATABASE_NAME, DATABASE_ENGINE, DATABASE_USER, DATABASE_PASSWORD, DATABASE_HOST и DATABASE_PORT. (Некоторые из них необязательны, подробности см. в главе 5.)

3.     Создайте в проекте приложение Django, выполнив команду python mysite/manage.py startapp myapp (где myapp - имя приложения).

4.     Выполните команду python mysite/manage.py inspectdb. Она проанализирует таблицы в базе данных DATABASE_NAME и для каждой из них выведет сгенерированный класс модели. Изучите этот класс, чтобы понять, что умеет inspectdb.

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

python mysite/manage.py inspectdb > mysite/myapp/models.ру

6.     Отредактируйте файл mysite/myapp/models.ру, внеся в модель необходимые на ваш взгляд изменения. Некоторые идеи по этому поводу приведены в следующем разделе.

Правка сгенерированных моделей

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

вносить мелкие изменения. Приведем несколько советов, как это лучше сделать.

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

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

id = models.IntegerField(primary_key=True)

Эти строки не просто лишние, но приведут к ошибке при добавлении новых записей в таблицы.

•      Тип поля (например, CharField, DateField) определяется по типу столбца таблицы (например, VARCHAR, DATE). Если inspectdb не знает, как отобразить тип столбца на тип поля модели, то выбирает тип TextField и оставляет в коде комментарий ‘This field type is a guess’ (Тип поля предположительный) рядом с сомнительным полем. Найдите все такие комментарии и при необходимости исправьте тип поля.

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

•      Если имя столбца базы данных является зарезервированным словом в языке Python (например, pass, class или for), то inspectdb добавит к имени соответствующего атрибута суффикс _field, а в атрибут db_column запишет истинное имя столбца.

Например, если в таблице имеется столбец типа INT с именем for, то в сгенерированной модели это поле будет определено так:

for_field = models.IntegerField(db_column=’for’)

Рядом с таким полем inspectdb оставит комментарий ‘Field renamed because it was a Python reserved word’ (Поле переименовано, так как это зарезервированное слово Python).

•      Если в базе данных имеются таблицы, ссылающиеся на другие таблицы (как чаще всего и бывает), то, возможно, придется изменить порядок следования сгенерированных моделей. Например, если в модели Book имеется поле типа ForeignKey, ссылающееся на модель Author, то модель Author должна предшествовать модели Book. Если необходимо создать связь с моделью, которая еще не была определена, то вместо самого объекта модели можно указать строку, содержащую ее имя.

•      Команда inspectdb благополучно распознает первичные ключи в таблицах баз данных PostgreSQL, MySQL и SQLite, то есть при необходимости она добавляет в определения полей атрибут primary_key=True. Для других СУБД вы сами должны добавить этот атрибут хотя бы для одного поля, поскольку Django требует, чтобы в любой модели присутствовало поле с атрибутом primary_key=True.

•      Команда inspectdb благополучно распознает внешние ключи в таблицах базы данных PostgreSQL и в некоторых типах таблиц MySQL. В остальных случаях поля внешнего ключа будут иметь в модели тип IntegerField в предположении, что столбец внешнего ключа имеет тип INT.

Источник: Головатый А., Каплан-Мосс Дж. Django. Подробное руководство, 2-е издание. - Пер. с англ. - СПб.: Символ- Плюс, 2010. - 560 е., ил.

Похожие посты:

Комментировать

Your email address will not be published. Required fields are marked *