Opened 9 years ago

Closed 9 years ago

#25293 closed Bug (needsinfo)

Multi-table inheritance with only related fields results in invalid migration on MySQL

Reported by: Hubert Bielenia Owned by: nobody
Component: Migrations Version: 1.8
Severity: Normal 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 (last modified by Tim Graham)

This report may be a duplicate of #24424 , but since the scope is somewhat different and proposed fix would not solve the issue, I decided to report it separately.

On Django 1.8.2, I have following model:

class Client(User):
    mailing_list = models.OneToOneField(SubscriberList, null=True, default=None)

Using manage.py makemigrations generates following operations:

 operations = [
        migrations.CreateModel(
            name='Client',
            fields=[
                ('id', models.AutoField(verbose_name='ID', serialize=False, auto_created=True, primary_key=True)),
                ('user', models.OneToOneField(to=settings.AUTH_USER_MODEL)),
            ],
        ),
        migrations.RemoveField(
            model_name='client',
            name='id',
        ),
        migrations.RemoveField(
            model_name='client',
            name='user',
        ),
        migrations.AddField(
            model_name='client',
            name='mailing_list',
            field=models.OneToOneField(null=True, default=None, to='campaign.SubscriberList'),
        ),
        migrations.AddField(
            model_name='client',
            name='user_ptr',
            field=models.OneToOneField(parent_link=True, auto_created=True, primary_key=True, default=0, serialize=False, to=settings.AUTH_USER_MODEL),
            preserve_default=False,
        ),
]

As you can see, the migration starts by removing implicit id and user fields, to later substitute them with implicit user_ptr field that serves both as foreign and primary key. Unfortunately, migrations.RemoveField uses ALTER TABLE statements, and this code attempts to delete all columns on the table, resulting in OperationalError with MySQL 5.8:
django.db.utils.OperationalError: (1090, "You can't delete all columns with ALTER TABLE; use DROP TABLE instead").

It looks to me like an unwanted behaviour.

Change History (4)

comment:1 by Hubert Bielenia, 9 years ago

Description: modified (diff)

comment:2 by Tim Graham, 9 years ago

Description: modified (diff)
Triage Stage: UnreviewedAccepted

comment:3 by Abhaya Agarwal, 9 years ago

I'm trying to reproduce it but for me, the following correct Migration is being generated:

    operations = [ 
        migrations.CreateModel(
            name='client',
            fields=[
                ('user_ptr', models.OneToOneField(parent_link=True, auto_created=True, primary_key=True, serialize=False, to=settings.AUTH_USER_MODEL)),
                ('mailing_list', models.OneToOneField(null=True, default=None, to='bug.SubscriberList')),
            ],  
            options={
                'abstract': False,
                'verbose_name': 'user',
                'verbose_name_plural': 'users',
            },  
            bases=('auth.user',),
            managers=[
                ('objects', django.contrib.auth.models.UserManager()),
            ],  
        ),  
    ] 

Can you provide a complete set of model definitions that will reproduce the issue?

comment:4 by Tim Graham, 9 years ago

Resolution: needsinfo
Status: newclosed

We might be missing the state of the models before what is reported in the description.

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