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 )
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 , 9 years ago
Description: | modified (diff) |
---|
comment:2 by , 9 years ago
Description: | modified (diff) |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:3 by , 9 years ago
comment:4 by , 9 years ago
Resolution: | → needsinfo |
---|---|
Status: | new → closed |
We might be missing the state of the models before what is reported in the description.
I'm trying to reproduce it but for me, the following correct Migration is being generated:
Can you provide a complete set of model definitions that will reproduce the issue?