Opened 7 years ago

Closed 7 years ago

#23264 closed Bug (fixed)

db_constraint=False not enforced on migrations

Reported by: Jay McEntire Owned by: Andrew Godwin
Component: Migrations Version: 1.7-rc-2
Severity: Release blocker Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

When adding db_constraint=False on a ForeignKey or directly on a Migration still causes the constraint to be created.

Change History (4)

comment:1 Changed 7 years ago by Jay McEntire

Example...

foo/models.py

from django.db import models

class Car(models.Model):
    name = models.CharField(max_length=255)
    color = models.ForeignKey('Color', db_constrain=False)

class Color(models.Model):
    color = models.CharField(max_length=255)

foo/migrations/0001_initial.py

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import models, migrations


class Migration(migrations.Migration):

    dependencies = [
    ]

    operations = [
        migrations.CreateModel(
            name='Car',
            fields=[
                ('id', models.AutoField(verbose_name='ID', serialize=False, auto_created=True, primary_key=True)),
                ('name', models.CharField(max_length=255)),
            ],
            options={
            },
            bases=(models.Model,),
        ),
        migrations.CreateModel(
            name='Color',
            fields=[
                ('id', models.AutoField(verbose_name='ID', serialize=False, auto_created=True, primary_key=True)),
                ('color', models.CharField(max_length=255)),
            ],
            options={
            },
            bases=(models.Model,),
        ),
        migrations.AddField(
            model_name='car',
            name='color',
            field=models.ForeignKey(to='foo.Color', db_constraint=False),
            preserve_default=True,
        ),
    ]

/manage.py sqlmigrate foo 0001

CREATE TABLE "foo_car" ("id" serial NOT NULL PRIMARY KEY, "name" varchar(255) NOT NULL);
CREATE TABLE "foo_color" ("id" serial NOT NULL PRIMARY KEY, "color" varchar(255) NOT NULL);
ALTER TABLE "foo_car" ADD COLUMN "color_id" integer NOT NULL;
ALTER TABLE "foo_car" ALTER COLUMN "color_id" DROP DEFAULT;
CREATE INDEX foo_car_399a0583 ON "foo_car" ("color_id");
ALTER TABLE "foo_car" ADD CONSTRAINT foo_car_color_id_75af12d643db05a2_fk_foo_color_id FOREIGN KEY ("color_id") REFERENCES "foo_color" ("id") DEFERRABLE INITIALLY DEFERRED;

FYI - This is using postgres

comment:2 Changed 7 years ago by Baptiste Mispelon

Severity: NormalRelease blocker
Triage Stage: UnreviewedAccepted

Hi,

Indeed, the constraint seems to be created regardless of the db_constraint=False.
Note that the same bux exists for ManyToManyField.db_constraint.

I'll bump the ticket to the release blocker status too.

Thanks.

comment:3 Changed 7 years ago by Andrew Godwin

Owner: changed from nobody to Andrew Godwin
Status: newassigned

Ah, I didn't even know we had db_constraint! Adding now.

comment:4 Changed 7 years ago by Andrew Godwin <andrew@…>

Resolution: fixed
Status: assignedclosed

In ee74f9fe3bcd8c2648e4623d5929fceac851b97f:

[1.7.x] Fixed #23264: Schema backends honour db_constraint

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