[Django] #27417: Change case on field causes invalid rename on Oracle backend migration
Django
-------------------------------------+-------------------------------------
Reporter: Vackar | Owner: nobody
Afzal |
Type: | Status: new
Uncategorized |
Component: | Version: 1.9
Migrations |
Severity: Release | Keywords: Migrations, Oracle,
blocker | DB, Rename
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 1
UI/UX: 0 |
-------------------------------------+-------------------------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27417>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: Migrations | Version: 1.9
Severity: Release blocker | Resolution:
Keywords: Migrations, Oracle, | Triage Stage:
DB, Rename | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
* type: Uncategorized => Bug
--
Ticket URL: <https://code.djangoproject.com/ticket/27417#comment:1>
Django
-------------------------------------+-------------------------------------
| Zundel
Type: Bug | Status: assigned
Component: Migrations | Version: 1.9
Severity: Release blocker | Resolution:
Keywords: Migrations, Oracle, | Triage Stage:
DB, Rename | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: nobody => Zach Zundel
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/27417#comment:2>
Django
-------------------------------------+-------------------------------------
Reporter: Vackar Afzal | Owner: Zach
| Zundel
Type: Bug | Status: assigned
Component: Migrations | Version: 1.9
Keywords: Migrations, Oracle, | Triage Stage: Accepted
DB, Rename |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
Changes (by Tim Graham):
* severity: Release blocker => Normal
* easy: 1 => 0
* stage: Unreviewed => Accepted
Old description:
> 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.
New description:
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.
--
Comment:
Reproduced on master at 373c6c409c310cb61e1e9c9aff4adba379ffd0b4. The
error when running the migration is "ORA-00957: duplicate column name".
--
Ticket URL: <https://code.djangoproject.com/ticket/27417#comment:3>
Django
-------------------------------------+-------------------------------------
Reporter: Vackar Afzal | Owner: Zach
| Zundel
Type: Bug | Status: assigned
Component: Migrations | Version: 1.9
Severity: Normal | Resolution:
Keywords: Migrations, Oracle, | Triage Stage: Accepted
DB, Rename |
Needs tests: 0 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
* cc: felisiak.mariusz@… (added)
Comment:
Zach, are you going to work on this issue? If not assign it to me.
--
Ticket URL: <https://code.djangoproject.com/ticket/27417#comment:4>
Django
-------------------------------------+-------------------------------------
Reporter: Vackar Afzal | Owner: Zach
| Zundel
Type: Bug | Status: assigned
Component: Migrations | Version: 1.9
Severity: Normal | Resolution:
Keywords: Migrations, Oracle, | Triage Stage: Accepted
DB, Rename |
Needs tests: 0 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27417#comment:5>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: assigned
Component: Migrations | Version: 1.9
Severity: Normal | Resolution:
Keywords: Migrations, Oracle, | Triage Stage: Accepted
DB, Rename |
Needs tests: 0 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
Changes (by felixxm):
* cc: felisiak.mariusz@… (removed)
* owner: Zach Zundel => felixxm
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/13385 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/27417#comment:6>
Django
-------------------------------------+-------------------------------------
Reporter: Vackar Afzal | Owner: felixxm
Component: Migrations | Version: 1.9
Severity: Normal | Resolution: fixed
Keywords: Migrations, Oracle, | Triage Stage: Accepted
DB, Rename |
Needs tests: 0 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"e6b5108acc79dcff5bc90bc97500569c74a807bc" e6b5108]:
{{{
#!CommitTicketReference repository=""
revision="e6b5108acc79dcff5bc90bc97500569c74a807bc"
Fixed #27417 -- Made RenameField operation a noop for field name case
changes on Oracle.
Field names are always uppercased in the Oracle backend. Changing case
should be a noop to avoid database errors: "ORA-00957: duplicate column
name".
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/27417#comment:7>