Opened 11 months ago

Last modified 8 months ago

#27417 assigned Bug

Migration to change model field case crashes on Oracle

Reported by: Vackar Afzal Owned by: Zach Zundel
Component: Migrations Version: 1.9
Severity: Normal Keywords: Migrations, Oracle, DB, Rename
Cc: felisiak.mariusz@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Tim Graham)

Given the following class

class MyModel(models.Model):
    somefield = models.CharField(max_length=100)

if I rename 'somefield' to 'someField' and run make migrations, it will generate a migrations that will rename 'somefield' to 'someField'

On case insensitive backends like oracle, this will result in the following invalid SQL being generated.

alter table mymodel rename somefield to someField;

In cases like this, it should simply generate no SQL.

The other option is when prompted for 'did you rename field x to y' , you can say no, which will result in a drop column followed by an add column, but this will result in all of the existing data in the column being lost, less than ideal.

Change History (5)

comment:1 Changed 11 months ago by Vackar Afzal

Type: UncategorizedBug

comment:2 Changed 11 months ago by Zach Zundel

Owner: changed from nobody to Zach Zundel
Status: newassigned

comment:3 Changed 11 months ago by Tim Graham

Description: modified (diff)
Easy pickings: unset
Severity: Release blockerNormal
Summary: Change case on field causes invalid rename on Oracle backend migrationMigration to change model field case crashes on Oracle
Triage Stage: UnreviewedAccepted

Reproduced on master at 373c6c409c310cb61e1e9c9aff4adba379ffd0b4. The error when running the migration is "ORA-00957: duplicate column name".

comment:4 Changed 8 months ago by felixxm

Cc: felisiak.mariusz@… added

Zach, are you going to work on this issue? If not assign it to me.

comment:5 Changed 8 months ago by Shai Berger

I'd consider marking this a duplicate, just one more manifestation of the case issues (e.g. #20487, #20226).

There's a fine point here: The case insensitivity is actually not a feature of the Oracle database engine, but rather of the Django Oracle backend. The intention was good -- when you write object (table, column, even user) names without quotes, Oracle understands them as upper case, and so Oracle DBAs have grown used to seeing all these names uppercased; the Django backend developers, I assume, wanted to be friendly to them. The result, however, is problematic (I have referred to it in the past as "case insanity"), and although I tried, I see no way to fix it in a reasonably backwards-compatible way.

It may be possible and may be helpful to solve this specific instance of the problem without solving the more general issue, so maybe we should leave it be. However, I would vote against adding case-sensitivity feature-flags are any such device to the generic database backends. As far as I know, none of the database products Django support (in core or through 3rd party modules) is actually case-insensitive.

Note: See TracTickets for help on using tickets.
Back to Top