Migration question: why causes this change a non-empty migration?

34 views
Skip to first unread message

Carsten Fuchs

unread,
Feb 1, 2019, 8:44:47 AM2/1/19
to django...@googlegroups.com
Dear Django group,

using a model like this:

```
class Kostenstelle(models.Model):
id = models.AutoField(primary_key=True)
name = models.CharField(max_length=60, blank=True)
# ... omitted fields

class Meta:
db_table = 'kostenstelle'
```

I replaced the `id` line with

```
id = models.IntegerField(primary_key=True, help_text="...")
```

(This was a while ago, using Django 1.11.1.)
Running `manage.py makemigrations` created two migration files, numbers 0022 and 0023:

```
# Migration 0022.
class Migration(migrations.Migration):

dependencies = [
('Lori', '0021_alter_Vortraege_jahr'),
]

operations = [
migrations.AlterField(
model_name='kostenstelle',
name='id',
field=models.IntegerField(primary_key=True, serialize=False),
),
]

# Migration 0023.
class Migration(migrations.Migration):

dependencies = [
('Lori', '0022_alter_Kostenstelle_id'),
]

operations = [
migrations.AlterField(
model_name='kostenstelle',
name='id',
field=models.IntegerField(help_text='...', primary_key=True, serialize=False),
),
]
```

This used to work properly with the Oracle DB backend, but today, using Django 1.11.18 with MySQL backend, there are problems:
Running `./manage.py sqlmigrate Lori 0023` shows, as expected, an empty commit. With comments and newlines stripped: `BEGIN; COMMIT;`

I had expected `./manage.py sqlmigrate Lori 0022` to show an empty commit as well, as ttbomk, it doesn't imply any changes to the table schema. However, a lot of SQL statements were generated. Here the complete output, which also covers Foreign Keys that I omitted above:

```
(Zeiterfassung) carsten@black-steel-ubuntu:~/Zeiterfassung$ ./manage.py sqlmigrate Lori 0022_alter_Kostenstelle_id
BEGIN;
--
-- Alter field id on kostenstelle
--
ALTER TABLE `kostenstelle` DROP FOREIGN KEY `kostenstelle_parent_id_d0c73a18_fk`;
ALTER TABLE `Lori_oeffnungszeiten` DROP FOREIGN KEY `Lori_oeffnungszeiten_kst_id_54e15381_fk`;
ALTER TABLE `Lori_vertragsverlauf` DROP FOREIGN KEY `Lori_vertragsverlauf_kostenstelle_id_59f33815_fk`;
ALTER TABLE `Lori_userkstzuordnung` DROP FOREIGN KEY `Lori_userkstzuordnung_kostenstelle_id_ac2cc3c0_fk`;
ALTER TABLE `Lori_pekosollstd` DROP FOREIGN KEY `Lori_pekosollstd_kst_id_6b0156f7_fk`;
ALTER TABLE `kostenstelle` MODIFY `id` integer NOT NULL;
ALTER TABLE `kostenstelle` MODIFY `parent_id` integer NULL;
ALTER TABLE `Lori_oeffnungszeiten` MODIFY `kst_id` integer NOT NULL;
ALTER TABLE `Lori_vertragsverlauf` MODIFY `kostenstelle_id` integer NULL;
ALTER TABLE `Lori_userkstzuordnung` MODIFY `kostenstelle_id` integer NOT NULL;
ALTER TABLE `Lori_pekosollstd` MODIFY `kst_id` integer NOT NULL;
ALTER TABLE `kostenstelle` ADD CONSTRAINT `kostenstelle_parent_id_d0c73a18_fk` FOREIGN KEY (`parent_id`) REFERENCES `kostenstelle` (`id`);
ALTER TABLE `Lori_oeffnungszeiten` ADD CONSTRAINT `Lori_oeffnungszeiten_kst_id_54e15381_fk` FOREIGN KEY (`kst_id`) REFERENCES `kostenstelle` (`id`);
ALTER TABLE `Lori_vertragsverlauf` ADD CONSTRAINT `Lori_vertragsverlauf_kostenstelle_id_59f33815_fk` FOREIGN KEY (`kostenstelle_id`) REFERENCES `kostenstelle` (`id`);
ALTER TABLE `Lori_userkstzuordnung` ADD CONSTRAINT `Lori_userkstzuordnung_kostenstelle_id_ac2cc3c0_fk` FOREIGN KEY (`kostenstelle_id`) REFERENCES `kostenstelle` (`id`);
ALTER TABLE `Lori_pekosollstd` ADD CONSTRAINT `Lori_pekosollstd_kst_id_6b0156f7_fk` FOREIGN KEY (`kst_id`) REFERENCES `kostenstelle` (`id`);
COMMIT;
```

My main question is:
Why is this migration not empty, and is it safe to leave it out?


I'm asking this because I have trouble with applying this migration. Apparently, not all of the previously established foreign keys are dropped with the upper statements and recreated with the lower statements. Error message of `manage.py migrate`:
_mysql_exceptions.OperationalError: (1833, "Cannot change column 'id': used in a foreign key constraint 'Lori_kalendereintrag_kostenstelle_id_edc2995b_fk_kostenste' of table 'LoriDB.Lori_kalendereintrag_kstellen'")
but this constraint is not mentioned above.

Can anyone help me please?

Best regards,
Carsten

Tim Graham

unread,
Feb 1, 2019, 11:39:37 AM2/1/19
to Django users
AutoField has AUTO_INCREMENT while IntegerField does not so if the migration is working correctly, I think its purpose is to drop the AUTO_INCREMENT.

I'm reluctant to continue investigation as you're using an old version of Django and many bugs have been fixed since then. If you can reproduce a problem with Django 2.2 alpha and a fresh database, feel free to create a ticket if you can't find an existing ticket.

Carsten Fuchs

unread,
Feb 1, 2019, 4:27:05 PM2/1/19
to django...@googlegroups.com
Am 01.02.19 um 17:39 schrieb Tim Graham:
> I'm reluctant to continue investigation as you're using an old version of Django and many bugs have been fixed since then. If you can reproduce a problem with Django 2.2 alpha and a fresh database, feel free to create a ticket if you can't find an existing ticket.

Ok, using Django 2.2a1 and a fresh database doesn't make a difference:
https://code.djangoproject.com/ticket/30152

Best regards,
Carsten
Reply all
Reply to author
Forward
0 new messages