#28438: Initial migration creates fields not listed in the migration if mixin
class
changes
-------------------------------------+-------------------------------------
Reporter: Michal Dabski | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.11
Severity: Normal | Resolution:
Keywords: | Triage Stage:
migration,models,mixin,sql | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Michal Dabski:
Old description:
> Consider the sample model with a mixin class:
> {{{
> from django.db import models
>
> class TestMixin(object):
> pass
>
> class TestModel(TestMixin, models.Model):
> sample_field = models.CharField(max_length=20)
> }}}
>
> When running makemigrations, django creates a perfectly good and valid
> migration:
> {{{
> # -*- coding: utf-8 -*-
> # Generated by Django 1.11.3 on 2017-07-26 17:03
> from __future__ import unicode_literals
>
> from django.db import migrations, models
> import migration_test.models
>
> class Migration(migrations.Migration):
>
> initial = True
>
> dependencies = [
> ]
>
> operations = [
> migrations.CreateModel(
> name='TestModel',
> fields=[
> ('id', models.AutoField(auto_created=True,
> primary_key=True, serialize=False, verbose_name='ID')),
> ('sample_field', models.CharField(max_length=20)),
> ],
> bases=(migration_test.models.TestMixin, models.Model),
> ),
> ]
>
> }}}
> SQL:
>
> {{{
> BEGIN;
> --
> -- Create model TestModel
> --
> CREATE TABLE "migration_test_testmodel" ("id" serial NOT NULL PRIMARY
> KEY, "sample_field" varchar(20) NOT NULL);
> COMMIT;
> }}}
>
>
> Next, refactor mixin class to add a field to it - need to change mixin's
> base class to {{{models.Model}}}, otherwise field will not be correctly
> inherited by models:
> {{{
> class TestMixin(models.Model):
> mixin_field = models.CharField(max_length=20, default='test')
>
> class Meta:
> abstract = True
> }}}
>
> This creates a new migration which adds {{{mixin_field}}} to it - nothing
> special. However, when applying both migrations after the model changes,
> second migration fails with the following error
> {{{django.db.utils.ProgrammingError: column "mixin_field" of relation
> "migration_test_testmodel" already exists}}}. as it turns out, the first
> migration's SQL has now changed to include {{{mixin_field}}}:
> {{{
> BEGIN;
> --
> -- Create model TestModel
> --
> CREATE TABLE "migration_test_testmodel" ("id" serial NOT NULL PRIMARY
> KEY, "mixin_field" varchar(20) NOT NULL, "sample_field" varchar(20) NOT
> NULL);
> COMMIT;
> }}}
> The python code of the migration obviously has not changed, but the
> resulting SQL did, and it includes a field not explicitly listed in the
> migration's {{{fields}}}.
>
> Note:
> - this does not happen if the mixin class extends {{{models.Model}}} to
> begin with.
> - if model extends a mixin that extends {{{object}}}, it ends up in
> model's {{{bases}}}, however if mixin extends {{{model.Model}}} it does
> not.
>
> Tested with Django 1.11.3, Python 2.7
New description:
Consider the sample model with a mixin class:
{{{
from django.db import models
class TestMixin(object):
pass
class TestModel(TestMixin, models.Model):
sample_field = models.CharField(max_length=20)
}}}
When running makemigrations, django creates a perfectly good and valid
migration:
{{{
# -*- coding: utf-8 -*-
# Generated by Django 1.11.3 on 2017-07-26 17:03
from __future__ import unicode_literals
from django.db import migrations, models
import migration_test.models
class Migration(migrations.Migration):
initial = True
dependencies = [
]
operations = [
migrations.CreateModel(
name='TestModel',
fields=[
('id', models.AutoField(auto_created=True,
primary_key=True, serialize=False, verbose_name='ID')),
('sample_field', models.CharField(max_length=20)),
],
bases=(migration_test.models.TestMixin, models.Model),
),
]
}}}
SQL:
{{{
BEGIN;
--
-- Create model TestModel
--
CREATE TABLE "migration_test_testmodel" ("id" serial NOT NULL PRIMARY KEY,
"sample_field" varchar(20) NOT NULL);
COMMIT;
}}}
Next, refactor mixin class to add a field to it - need to change mixin's
base class to {{{models.Model}}}, otherwise field will not be correctly
inherited by models:
{{{
class TestMixin(models.Model):
mixin_field = models.CharField(max_length=20, default='test')
class Meta:
abstract = True
}}}
This creates a new migration which adds {{{mixin_field}}} to it - nothing
special. However, when applying both migrations after the model changes,
second migration fails with the following error
{{{django.db.utils.ProgrammingError: column "mixin_field" of relation
"migration_test_testmodel" already exists}}}. as it turns out, the first
migration's SQL has now changed to include {{{mixin_field}}}:
{{{
BEGIN;
--
-- Create model TestModel
--
CREATE TABLE "migration_test_testmodel" ("id" serial NOT NULL PRIMARY KEY,
"mixin_field" varchar(20) NOT NULL, "sample_field" varchar(20) NOT NULL);
COMMIT;
}}}
The python code of the migration obviously has not changed, but the
resulting SQL did, and it includes a field not explicitly listed in the
migration's {{{fields}}}.
Note:
- this does not happen if the mixin class extends {{{models.Model}}} to
begin with.
- if model extends a mixin that extends {{{object}}}, it ends up in
model's {{{bases}}}, however if mixin extends {{{model.Model}}} it does
not.
- when mixin's base class changes, schema migration does not reflect this
change in model's {{{bases}}}
Tested with Django 1.11.3, Python 2.7
Proposed solution:
migration should not create database fields for model fields not
explicitly listed in {{{fields}}}
--
--
Ticket URL: <https://code.djangoproject.com/ticket/28438#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.0129d722709a9b980e238475beb72763%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
