Opened 8 weeks ago

Closed 8 weeks ago

Last modified 7 weeks ago

#28640 closed Bug (duplicate)

migrations.AlterField changing from default=False to True drops default

Reported by: Axel Rau Owned by: nobody
Component: Migrations Version: 1.11
Severity: Normal Keywords: migrations, alter field, default, drop default
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

This migration:

class Migration(migrations.Migration):

    dependencies = [
        ('erdb', '0004_auto_20170806_1346'),
    ]

    operations = [
        migrations.AlterField(
            model_name='account',
            name='is_active',
            field=models.BooleanField(default=True, editable=('AE',), verbose_name='Is active'),
        ),
    ]

produces this SQL:

BEGIN;
--
-- Alter field is_active on account
--
ALTER TABLE "account" ALTER COLUMN "is_active" SET DEFAULT true;
ALTER TABLE "account" ALTER COLUMN "is_active" DROP DEFAULT;
COMMIT;

This is Django 1.11.5 and PostgreSQL 9.4.6.

Change History (6)

comment:1 Changed 8 weeks ago by Simon Charette

Triage Stage: UnreviewedAccepted

No queries should be executed in this case.

comment:2 Changed 8 weeks ago by Tim Graham

Did you verify that master is affected? It looks like a duplicate of #27928 at first glance, which is fixed for Django 2.0.

comment:3 in reply to:  1 Changed 8 weeks ago by Axel Rau

Replying to Simon Charette:

No queries should be executed in this case.

Shouldn't the 1st ALTER TABLE be executed?

comment:4 in reply to:  2 Changed 8 weeks ago by Axel Rau

Replying to Tim Graham:

Did you verify that master is affected?

No. No chance yet to set up a master installation/test environment here.

It looks like a duplicate of #27928 at first glance, which is fixed for Django 2.0.

Different case: #27928 deals with null/blank. Maybe same code path. Where is the patch?

comment:5 Changed 8 weeks ago by Simon Charette

Resolution: duplicate
Status: newclosed

Shouldn't the 1st ALTER TABLE be executed?

No, Django only uses database level defaults when adding a column to an existing table (as it could have rows already) or when altering a NULL column to NOT NULL but immediately drops it afterwards.

I confirmed that it's fixed on 2.0 and master by 35c0025151ad411e691a2fa62a0dd3507ebafd82.

(By the way, something is odd with your editable kwarg. It should be a boolean, not a tuple)

comment:6 in reply to:  5 Changed 7 weeks ago by Axel Rau

Replying to Simon Charette:

Shouldn't the 1st ALTER TABLE be executed?

I confirmed that it's fixed on 2.0 and master by 35c0025151ad411e691a2fa62a0dd3507ebafd82.

Thanks

(By the way, something is odd with your editable kwarg. It should be a boolean, not a tuple)

This is intentionally. It was the only attribute, where I can store my hints for creating flex forms.
AFAIK there is no supported API for creating new meta attributes. Until now Django tolerated it. (-;

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