Opened 8 years ago
Closed 4 years ago
#27417 closed Bug (fixed)
Migration to change model field case crashes on Oracle
Reported by: | Vackar Afzal | Owned by: | Mariusz Felisiak |
---|---|---|---|
Component: | Migrations | Version: | 1.9 |
Severity: | Normal | Keywords: | Migrations, Oracle, DB, Rename |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
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 (7)
comment:1 by , 8 years ago
Type: | Uncategorized → Bug |
---|
comment:2 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 8 years ago
Description: | modified (diff) |
---|---|
Easy pickings: | unset |
Severity: | Release blocker → Normal |
Summary: | Change case on field causes invalid rename on Oracle backend migration → Migration to change model field case crashes on Oracle |
Triage Stage: | Unreviewed → Accepted |
comment:4 by , 8 years ago
Cc: | added |
---|
Zach, are you going to work on this issue? If not assign it to me.
comment:5 by , 8 years ago
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.
Reproduced on master at 373c6c409c310cb61e1e9c9aff4adba379ffd0b4. The error when running the migration is "ORA-00957: duplicate column name".