Opened 8 months ago

Closed 7 months ago

Last modified 7 months ago

#23073 closed Cleanup/optimization (wontfix)

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

Reported by: shai Owned by: shai
Component: Migrations Version: 1.7-rc-1
Severity: Normal Keywords: oracle
Cc: timo, andrewgodwin 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 Changed 8 months ago by timo

  • Triage Stage changed from Unreviewed to Accepted
  • Type changed from Uncategorized to Cleanup/optimization
  • Version changed from master to 1.7-rc-1

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

comment:2 Changed 8 months ago by timo

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

comment:3 Changed 7 months ago by shaib

  • Resolution set to wontfix
  • Status changed from new to closed

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 Changed 7 months ago by Shai Berger <shai@…>

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 Changed 7 months ago by Shai Berger <shai@…>

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