Altering table not working as expected on Oracle

[Dario]

Hi,

I have added the following field to a model class:

is_filter_script_used = models.BooleanField(default=False)

Executing the migration on Oracle generates several ALTER TABLE statements, the first of which does what it is supposed to do, while the other statements just cancel some of the options set through the first statement:

 - Migrating forwards to 0002_auto__add_field_connectoroperation_is_filter_script_used.

 > operations:0002_auto__add_field_connectoroperation_is_filter_script_used

   = ALTER TABLE "CONNECTOR_OPERATION" ADD "IS_FILTER_SCRIPT_USED" NUMBER(1) DEFAULT 0 CHECK ("IS_FILTER_SCRIPT_USED" IN (0,1)) NOT NULL ; []

   - no dry run output for alter_column() due to dynamic DDL, sorry

   = ALTER TABLE "CONNECTOR_OPERATION" ADD "IS_FILTER_SCRIPT_USED" NUMBER(1) DEFAULT 0 CHECK ("IS_FILTER_SCRIPT_USED" IN (0,1)) NOT NULL ; []

   = ALTER TABLE "CONNECTOR_OPERATION" MODIFY "IS_FILTER_SCRIPT_USED" NUMBER(1) CHECK ("IS_FILTER_SCRIPT_USED" IN (0,1)) NOT NULL; []

   = ALTER TABLE "CONNECTOR_OPERATION" MODIFY "IS_FILTER_SCRIPT_USED" NUMBER(1) CHECK ("IS_FILTER_SCRIPT_USED" IN (0,1)) ; []

   = ALTER TABLE "CONNECTOR_OPERATION" MODIFY "IS_FILTER_SCRIPT_USED" DEFAULT NULL; []

 - Loading initial data for operations.

Loading 'initial_data' fixtures...

As you can see, the last 3 statements cancel the default value and the NOT NULL constraint.

Any ideas why?

[Shai Berger]

On Thursday 13 March 2014 08:43:36 Dario wrote:
> Hi,
>
> I have added the following field to a model class:
>

> *is_filter_script_used = models.BooleanField(default=False)*

>
>
> Executing the migration on Oracle generates several ALTER TABLE statements,
> the first of which does what it is supposed to do, while the other
> statements just cancel some of the options set through the first statement:
>

> * - Migrating forwards to
> 0002_auto__add_field_connectoroperation_is_filter_script_used.*
> * >
> operations:0002_auto__add_field_connectoroperation_is_filter_script_used*
> * = ALTER TABLE "CONNECTOR_OPERATION" ADD "IS_FILTER_SCRIPT_USED"
> NUMBER(1) DEFAULT 0 CHECK ("IS_FILTER_SCRIPT_USED" IN (0,1)) NOT NULL ; []*
> * - no dry run output for alter_column() due to dynamic DDL, sorry*
> * = ALTER TABLE "CONNECTOR_OPERATION" ADD "IS_FILTER_SCRIPT_USED"
> NUMBER(1) DEFAULT 0 CHECK ("IS_FILTER_SCRIPT_USED" IN (0,1)) NOT NULL ; []*
> * = ALTER TABLE "CONNECTOR_OPERATION" MODIFY "IS_FILTER_SCRIPT_USED"
> NUMBER(1) CHECK ("IS_FILTER_SCRIPT_USED" IN (0,1)) NOT NULL; []*
> * = ALTER TABLE "CONNECTOR_OPERATION" MODIFY "IS_FILTER_SCRIPT_USED"
> NUMBER(1) CHECK ("IS_FILTER_SCRIPT_USED" IN (0,1)) ; []*
> * = ALTER TABLE "CONNECTOR_OPERATION" MODIFY "IS_FILTER_SCRIPT_USED"
> DEFAULT NULL; []*
> * - Loading initial data for operations.*
> *Loading 'initial_data' fixtures...*

>
>
> As you can see, the last 3 statements cancel the default value and the NOT
> NULL constraint.
>
> Any ideas why?

South follows Django in not keeping default values in the database; that is
why the default values are removed. I believe the null constraint isn't really
removed -- one would have to specify NULL as a keyword (as opposed to an
argument to DEFAULT) for that to happen; and IIRC there are tests in South
that validate that the columns created are in fact not-null.

If you can insert a null into such a column, that's a bug in South.

HTH,
Shai.