SQL0601N Имя создаваемого объекта идентично существующему имени "DJANGO_MIGRATIONS" типа "TABLE"

Я хочу, чтобы django подключался к db2 под другим пользователем (DBADM) вместо db2inst1, схема - XXX. Но после запуска python manage.py migrate произошел сбой после создания таблиц DJANGO_MIGRATIONS и DJANGO_CONTENT_TYPE. Они обе пусты. Возвращаемая ошибка [IBM][CLI Driver][DB2/AIX64] SQL0601N The name of the object to be created is identical to the existing name "XXX.DJANGO_MIGRATIONS" of type "TABLE". SQLSTATE=42710. Я попытался удалить таблицы и запустить команду снова, но безуспешно. Похоже, что команда не может найти таблицу DJANGO_MIGRATIONS при попытке вставить новую запись, поэтому она пытается создать ее снова. Однако команда успешно выполняется при использовании db2inst1.

Итак, я хочу знать, вызвана ли проблема недостаточными привилегиями пользователя? Какие привилегии/роли должен иметь пользователь подключения? Существуют ли какие-либо ограничения для пользователя подключения? Я пытался найти документ, но не смог найти ни одного.

Версии: Django 3.2, ibm-db-django 1.5.0.0, ibm-db 3.1.0, DB2 10.5

Непосредственная ошибка (SQL0601N) вызвана тем, что предыдущий запуск python manage.py начался (и, возможно, завершился неудачей) для того же USER, упомянутого в строке DATABASES в settings.py.

Если вы включите протоколирование SQL в settings.py, вы увидите все создаваемые таблицы, которые сохраняются после неудачного запуска manage.py migrate, по умолчанию.

Вы можете доказать это, создав пустую пустую базу данных (db2 create database blank) и настроив settings.py на ее использование, а затем запустив python manage.py migrate. После этого программа не сообщит о дублировании объекта (SQL0601N), хотя она сообщит о других ошибках только на Db2-LUW v10.5.

Вы также можете устранить специфическую ошибку (SQL0601N), сбросив все связанные с django таблицы метаданных в специфической схеме перед запуском python manage.py migrate. Вы можете увидеть имена этих таблиц с помощью команды db2 list tables for schema XXX, где XXX - это userid, который вы указали в качестве USER в строке DATABASES в settings.py. Вы можете вручную удалить все эти таблицы перед повторной попыткой python manage.py migrate. Типичные примеры имен таблиц включают следующие (возможны и другие):

DJANGO_MIGRATIONS
DJANGO_CONTENT_TYPE
AUTH_PERMISSION
AUTH_GROUP
AUTH_PERMISSIONS 
AUTH_GROUP_PERMISSIONS 
AUTH_USER

Если ваш Db2-LUW-сервер имеет версию 10.5, а ваш Django - 3.2, вы не добьетесь прогресса, вам необходимо иметь минимальную версию Db2-LUW 11.1 с вашим сочетанием версий компонентов. Если вам необходимо обновить версию Db2-сервера, то разумнее всего начать с версии 11.5 и последнего доступного на данный момент фикспака к ней. Если вы не можете обновить версию Db2-LUW-сервера, то вам придется понижать уровни других компонентов и, возможно, в итоге вы получите не поддерживаемое сочетание версий

Причина в том, что компонентный микс ожидает, что тип данных BOOLEAN в SQL является типом данных первого класса, но в Db2-LUW v10.5 это не так. Вам необходимо иметь как минимум Db2-LUW v11.1, чтобы получить полную поддержку типа данных BOOLEAN и безошибочно выполнить python manage.py migrate. Если вы попробуете с Db2-LUW v10.5, вы можете увидеть ошибки типа

"SQL0401N Типы данных операндов для операции "IN" являются несовместимы или несопоставимы"

при запуске python manage.py migrate с вашей коллекцией версий компонентов. Вы не получите этих ошибок с Db2-LUW v11.1 или выше.

Помните, что IBM прекратила поддержку дефектов Db2 для версии 10.5 30 апреля/2020 года (никаких дальнейших исправлений или улучшений), поэтому если ваша компания уже не приобрела расширенную поддержку, то вам в любом случае следует обновить ваш сервер Db2-LUW.

Ошибка возвращается из-за различий в CURRENTSCHEMA и USER: https://github.com/ibmdb/python-ibmdb-django/issues/68

Вернуться на верх