[Django] #23073: Oracle 11.2.0.1: Number columns (incl. Booleans) defined with default break introspection
Django
introspection
-----------------------------------------+------------------------
Reporter: shai | Owner: shai
Type: Uncategorized | Status: new
Component: Migrations | Version: master
Severity: Normal | Keywords: oracle
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
It seems that on this specific version of Oracle server, if you define a
number column with a default, it gets precision 0. This, in turn, means it
will be introspected as an `IntegerField`, even if it was a `BooleanField`
or a `BigIntegerField` to begin with.
I am not quite sure yet about this description, but that seems to be what
I get from tests.
I suspect this can be worked-around by changing the alter-column command
which removes the default to also redefine the type. I am not sure
supporting one specific, superseded, Oracle version, is worth the hassle.
The point going for it is that this is the (Oracle 11) version one can
download from Oracle for free, and so this is the version we are trying to
use for our CI (and others may want to do the same).
--
Ticket URL: <https://code.djangoproject.com/ticket/23073>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: shai | Owner: shai
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: 1.7-rc-1
Severity: Normal | Resolution:
Keywords: oracle | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timo):
* version: master => 1.7-rc-1
* type: Uncategorized => Cleanup/optimization
* stage: Unreviewed => Accepted
Comment:
The "Developer Days VM" described in OracleTestSetup includes 11.2.0.2.0
which doesn't have the problem.
--
Ticket URL: <https://code.djangoproject.com/ticket/23073#comment:1>
Django
Reporter: shai | Owner: shai
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: 1.7-rc-1
Severity: Normal | Resolution:
Keywords: oracle | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timo):
#22738 notes the value returned for some other backends also vary. Perhaps
the fix could be generalized to address that as well.
--
Ticket URL: <https://code.djangoproject.com/ticket/23073#comment:2>
Django
Reporter: shai | Owner: shai
Type: Cleanup/optimization | Status: closed
Component: Migrations | Version: 1.7-rc-1
Severity: Normal | Resolution: wontfix
Keywords: oracle | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by shaib):
* status: new => closed
* resolution: => wontfix
Comment:
I tried.
By my understanding now, and also by
[http://stackoverflow.com/questions/8481532/how-do-i-remove-the-default-
value-from-a-column-in-oracle this] !StackOverflow question (second
answer), the only way to really fix this is to use a Sqlite-backend-style
table-recreation for adding columns. With all due respect to Continuous
Integration, we are not going to do '''that''' to work around an Oracle
bug that has already been fixed.
I'm going to just disable the failing test on the specific Oracle server
version.
--
Ticket URL: <https://code.djangoproject.com/ticket/23073#comment:3>
Django
Reporter: shai | Owner: shai
Type: Cleanup/optimization | Status: closed
Component: Migrations | Version: 1.7-rc-1
Severity: Normal | Resolution: wontfix
Keywords: oracle | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Shai Berger <shai@…>):
In [changeset:"56252e7f46afce36fd112971c28188a3fd509a43"]:
{{{
#!CommitTicketReference repository=""
revision="56252e7f46afce36fd112971c28188a3fd509a43"
Fixed schema test for Oracle 11.2.0.1 which is used in Django Project's
CI.
Refs #23073 Workaround.
Refs #22738 Repeats the mysql "offense". When the issue is solved, the
Oracle special case should be made to play with the solution (that is,
Oracle should be fixed the same way that mysql and the 3rd-party backneds
are).
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23073#comment:4>
Django
Reporter: shai | Owner: shai
Type: Cleanup/optimization | Status: closed
Component: Migrations | Version: 1.7-rc-1
Severity: Normal | Resolution: wontfix
Keywords: oracle | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Shai Berger <shai@…>):
In [changeset:"588f66d18235762f8e0f96200c88bc4ba6c1c579"]:
{{{
#!CommitTicketReference repository=""
revision="588f66d18235762f8e0f96200c88bc4ba6c1c579"
[1.7.x] Fixed schema test for Oracle 11.2.0.1 which is used in Django
Project's CI.
Refs #23073 Workaround.
Refs #22738 Repeats the mysql "offense". When the issue is solved, the
Oracle special case should be made to play with the solution (that is,
Oracle should be fixed the same way that mysql and the 3rd-party backneds
are).
Backport of 56252e7 from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23073#comment:5>