Как правильно интегрировать Django с унаследованной базой данных?

Question

[nurzhannogerbek]

Здравствуйте! Помогите пожалуйста разобраться.

Есть база данных на Oracle c таблицей. В таблице хранятся множества данных. Необходимо создать модель данных на основе ранее упомянутой таблицы. Проблемы в следующем:

1. В данной таблице есть столбец tab c типом NUMBER. При этом precision и scale пустые.

Команда inspectdb возвращает почему-то tab = models.FloatField(), хотя вроде как FloatField не создаст тип данных NUMBER в БД. Поэтому я остановился на следующем коде:

tab = models.IntegerField(
    verbose_name='Вкладка',
    choices=TAB_CHOICES,
    default=0,
    blank=True,
    null=True
)

Данный код создает обычно тип данных NUMBER, но при этом с precision=11, scale=0. Вопрос: не возникнет ли проблемы при миграции к существующей БД (таблицей) с текущим кодом или как установить пустые значения для precision и scale?

2. В таблице есть столбец title у которой тип данных CLOB. Я планирую использовать следующий код:

title = models.TextField(
    verbose_name='Заголовок',
    blank=True,
    null=True
)

Обычно данный код создает в БД тип NCLOB. Хотя inspectdb для столбца title возвращает TextField тоже. Вопрос: Возможно ли явно указать тип в Джанго? Не возникнет ли проблемы при интеграции?

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

django.db.utils.DatabaseError: ORA-00955: name is already used by an existing object

Возможно ошибка из-за того, что в db_table, который в Meta классе, стоит название таблицы.

Answer 1

[Артем Советников]

Ошибка сообщает о том, что таблицу с указанным названием создать нельзя - она уже есть в базе.
Если коротко, то вам надо сделать manage.py migrate --fake [appname] (appname - название вашего модуля), Django пометит в БД начальную миграцию как выполненную и саму базу трогать не будет.

Но, т.к. django использует служебные таблицы, то сначала сделайте manage.py migrate django.

По п.1 и 2 - попробуйте на практике. Я так понимаю модифицировать схему через Django вы не собираетесь? Тогда просто попробуйте, что Django умеет читать и писать в вашу БД. Нагенерируйте данных https://github.com/vandersonmota/model_mommy и прочитайте их.

Ещё раз - учтите, что Django создаёт кучку служебных таблиц.

Comments

[nurzhannogerbek]

Здравствуйте! С ошибкой разобрался, тоже применил команду: manage.py migrate --fake [appname].

Проблема теперь в том, что к примеру я создал поле author = models.ForeignKey(***) в своей модели данных, а в этой старой унаследованной таблице нету ссылочной целостности, то есть стоит просто тип данных Number, где хранится id пользователя, это вроде не хорошо так хранить. Из-за этого мне кажется не проходит миграция. Здесь либо нужно менять таблицу, либо модель данных. Что вы думаете по этому поводу?

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

[Артем Советников]

"модифицировать схему через Django" - это сделать manage.py makemigration и затем migrate
Какая миграция не проходит из-за author? Покажите конкретнее, фейковая миграяиц не проходит? Приложение работает (читает, пишет)?

[nurzhannogerbek]

1. manage.py migrate --fake [appname] - прошла успешно.
2. makemigrations сделал и она создала 0001_initail.py файл.
3. После этого попытался сделать команду migrate, но она не прошла. В данный момент не могу показать полной ошибки, так как сижу с другого компьютера. Но мне кажется проблема из-за того что модель данных и таблица не совпадают. Такое может быть? То есть в модели данных стоит author = models.ForeignKey(***), а в таблице нет внешнего ключа. Так как я уже упоманал стоит тип данных Number без ссылочной целостности. Я может чего-то не понимаю, возможно после команды migrate в идеале уже существующая таблица должна была поменяться?

[Артем Советников]

Надо сначала сделать makemigrations [appname], а уже затем migrate --fake [appname]
Пока вы makemigrations не сделали мигрировать то и нечего ... задача это как раз эмулировать применение inital миграции.
А без migrate не работает приложение? По идее должно работать ... Django не требует чтобы миграции были помечены как примененные (хоть с --fake хоть без него), Django просто выполняет SQL запросы по имеющейся модели и ошибки могут возникнуть уже только на уровне SQL запросов (ну могут быть конечно и в самом Django в случае неверного преобразования типов в случае их несовпадения).
Я ведь правильно понимаю, что вы пока просто пытаетесь повторить таблицу в БД в модели Django?

[nurzhannogerbek]

Артем Советников, да вы правы. Я пытаетесь повторить таблицу в БД в модели Django. В целом смысл понятен теперь. Кажется у меня как раз случай который вы описали: не совпадения типов. К примеру в модели данных указал author = models.ForeignKey(***), но в самой таблице нет внешнего ключа. Спасибо вам за разъяснения!

[Артем Советников]

Так данные читаются с таким FK?