Почему в Django миграция на Oracle приводит к попыткам сохранить экземпляры с нулевым идентификатором? - PullRequest
3 голосов
/ 30 декабря 2010

Я переношу проект Django из SQLite в Oracle и получаю сообщение об ошибке в строке disn_requisition.save (), утверждая, что у него нулевой идентификатор. Я не пытался вручную задавать или изменять поля идентификатора на любой модели, хотя я их и читаю.

Любое понимание того, что мне нужно сделать, чтобы решить эту проблему?

IntegrityError at /upload/storage

ORA-01400: cannot insert NULL into ("INVDB"."INVDB_DISK_REQUISITION"."ID")
Request Method: POST
Request URL: [url here]
Django Version: 1.2.3
Exception Type: IntegrityError
Exception Value: 
ORA-01400: cannot insert NULL into ("INVDB"."INVDB_DISK_REQUISITION"."ID")
Exception Location: /tools/python/2.7/Linux_x86_64/lib/python2.7/site-packages/django/db/backends/oracle/base.py in execute, line 507
Python Executable: /tools/python/2.7/Linux_x86_64/bin/python
Python Version: 2.7.0
Python Path: ['/home/jhayward/invdb', '/tools/python/2.7/Linux_x86_64/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg', '/tools/python/2.7/Linux_x86_64/lib/python2.7/site-packages/django_filter-0.5.3-py2.7.egg', '/tools/python/2.7/Linux_x86_64/lib/python2.7/site-packages/ez_setup-0.9-py2.7.egg', '/tools/python/2.7/Linux_x86_64/lib/python2.7/site-packages/distribute-0.6.14-py2.7.egg', '/tools/python/2.7/Linux_x86_64/lib/python2.7/site-packages/hgsvn-0.1.8-py2.7.egg', '/tools/python/2.7/Linux_x86_64/lib/python2.7/site-packages/paramiko-1.7.6-py2.7.egg', '/tools/python/2.7/Linux_x86_64/lib/python2.7/site-packages/pycrypto-2.3-py2.7-linux-x86_64.egg', '/tools/python/cx_Oracle/10g/2.6/Linux_x86_64/lib/python2.6/site-packages', '/home/jhayward', '/home/jhayward/invdb/HOME_DIRECTORY', '/home/jhayward/invdb/HOME_DIRECTORY/invdb', '/tools/python/2.7/Linux_x86_64/lib/python27.zip', '/tools/python/2.7/Linux_x86_64/lib/python2.7', '/tools/python/2.7/Linux_x86_64/lib/python2.7/plat-linux2', '/tools/python/2.7/Linux_x86_64/lib/python2.7/lib-tk', '/tools/python/2.7/Linux_x86_64/lib/python2.7/lib-old', '/tools/python/2.7/Linux_x86_64/lib/python2.7/lib-dynload', '/tools/python/2.7/Linux_x86_64/lib/python2.7/site-packages', '/tools/python/2.7/Linux_x86_64/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg-info']
Server time: Thu, 30 Dec 2010 10:04:24 -0600

1 Ответ

3 голосов
/ 07 февраля 2011

Я разместил этот вопрос на django-users@googlegroups.com и получил следующий ответ:

"Проблема заключается в разнице в SQLite и Oracle. В отличие от MySQL, PostgresQL и SQLIte, Oracle не имеет автоматически генерируемых первичных ключей. Чтобы восполнить это, Django в Oracle использует триггер для каждого Django- управляемая таблица, которая распознает первичный ключ NULL при вставке и генерирует ключ, используя выделенную последовательность для этой таблицы. Обычно, если вы создаете таблицы с нуля, инструменты управления Django (syncdb, sqlall и т. д.) создают последовательность и запуск для вас. Не зная больше о том, как вы заполнили вашу схему, трудно сказать, что пошло не так, но если вы запустите 'python manage.py sqlall invdb', он должен распечатать DDL, чтобы создать триггер и последовательность, и вы могу добавить их вручную. "

В моем случае - и ошибка может быть вторичным повреждением, связанным с этим - "python manage.py syncdb" аварийно завершился с первого раза, и в качестве стандартного обходного пути я запустил его во второй раз, когда он работал без сообщения ошибка. Я передал это другому человеку, так что я не уверен, как это было решено, но я полагаю, что пропущенный триггер может быть вторичным ущербом, связанным с падением, и я думаю, что это было решено с помощью кода типа базы данных, помещающего код на место так, у модели-нарушителя был триггер.

...