Oracle Syncdb breaks trying to set NULL to column that already is NULL

[JorisBenschop]

hi

I'm not sure if this is a dev question. Probably I did something dumb, so I hope you can help me discover what that is:

I'm trying to syncdb to an empty Oracle DB. Many tables, triggers and sequences are made but then this:

...
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
  Installing custom SQL...
Running migrations:
  Rendering model states... DONE
  Applying contenttypes.0002_remove_content_type_name...DEBUG ALTER TABLE "DJANGO_CONTENT_TYPE" MODIFY "NAME" NULL; (params [])
DEBUG (0.055) QUERY = u'ALTER TABLE "DJANGO_CONTENT_TYPE" MODIFY "NAME" NULL' - PARAMS = (); args=[]
Traceback (most recent call last):
...
...
django.db.utils.DatabaseError: ORA-01451: column to be modified to NULL cannot be modified to NULL

Indeed if I run this in oracle directly:

ALTER TABLE "DJANGO_CONTENT_TYPE" MODIFY "NAME" NULL;

I get the same error: you cannot change a NULL column into NULL

I don't understand why django wants to alter a column name of a table it just made a few seconds before, but still. What seems to happen is that it changes a column to NULL, but because it already is NULL, the statement fails.
Workaround is to manually set:

ALTER TABLE "DJANGO_CONTENT_TYPE" MODIFY ("NAME" NOT NULL);

Then run syncdb again and the error is gone.

I can see this is sillyness of oracle, but there's not much I can do about that. Is this a bug?

[Tim Graham]

Not sure offhand, what version of Oracle (in case it matters)? I'll try to make sure someone investigates this issue before 1.8 beta.

[JorisBenschop]

Its Oracle 11g afaik. I'm not close enough to the DBA to find out easily, but if this is a requirement I can send in an internal request.

[Shai Berger]

It's a bug, I can easily reproduce it by just trying to migrate the default project (created by start_project, with no changes except for defining an Oracle database).

It happens, as the reporter said, because of Oracle silliness: On Oracle, all CharFields are defined (in the database) null, because Oracle can't tell the difference between null and an empty string. For Django 1.8, a migration explicitly makes the name field null (it wasn't null before at the Python level, nor on any other backend), and hence the failure.

[Shai Berger]

​https://github.com/django/django/pull/4162

[Shai Berger]

The patch fixes the problem reported in the ticket, but it As noted by Tim on IRC, though, to detect such problems ourselves, we should make sure the migrations for contrib apps are all run in the test-suite. Also probably should test for the more specific problem explicitly.

[Shai Berger <shai@…>]

In ceadc94f09f0615e95146f9a42b711acfc14f40f:

Fixed #24307: Avoided redundant column nullability modifications on Oracle

Thanks Joris Benschop for the report, and Tim Graham for the tests.

[Shai Berger <shai@…>]

In 66d37e593c8fa22be226b34b4fc1f60f85dcdc26:

[1.8.x] Fixed #24307: Avoided redundant column nullability modifications on Oracle

Thanks Joris Benschop for the report, and Tim Graham for the tests.

Backport of ceadc94f09 from master