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.

On Friday, February 1, 2019 at 8:44:47 AM UTC-5, Carsten Fuchs wrote:
>
> 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 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/30dc533c-cee9-4ee8-9886-5cd7c81fff12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to