Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#23073 closed Cleanup/optimization (wontfix)

Oracle 11.2.0.1: Number columns (incl. Booleans) defined with default break introspection

Reported by: Shai Berger Owned by: Shai Berger
Component: Migrations Version: 1.7-rc-1
Severity: Normal Keywords: oracle
Cc: Tim Graham, Andrew Godwin Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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).

Change History (5)

comment:1 by Tim Graham, 10 years ago

Triage Stage: UnreviewedAccepted
Type: UncategorizedCleanup/optimization
Version: master1.7-rc-1

The "Developer Days VM" described in OracleTestSetup includes 11.2.0.2.0 which doesn't have the problem.

comment:2 by Tim Graham, 10 years ago

#22738 notes the value returned for some other backends also vary. Perhaps the fix could be generalized to address that as well.

comment:3 by Shai Berger, 10 years ago

Resolution: wontfix
Status: newclosed

I tried.

By my understanding now, and also by 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.

comment:4 by Shai Berger <shai@…>, 10 years ago

In 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).

comment:5 by Shai Berger <shai@…>, 10 years ago

In 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

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