neon-jungle / wagtail-birdsong

Create, send, preview, edit and test email campaigns from within Wagtail
BSD 3-Clause "New" or "Revised" License
103 stars 27 forks source link

Missing birdsong migration? Only an issue for Django 4.0? #18

Closed hanktopia closed 1 year ago

hanktopia commented 2 years ago

Hi, I'm working on integrating birdsong into a containerized Django 4.0 environment and ran into an issue with migrations. After adding birdsong to my container, running migrate successfully runs the 4 files currently included with birdsong:

Running migrations:
  Applying birdsong.0001_initial... OK
  Applying birdsong.0002_auto_20200603_0206... OK
  Applying birdsong.0003_drop_unique_constraint... OK
  Applying birdsong.0004_campaign_status... OK

At this point makemigrations indicates that there are no changes detected.

After that, I then add a newsletter django project with a Newsletter(Campaign) model. When I run makemigrations, it creates a migration file for the newsletter project as expected. But... it also creates a new migration for birdsong:

Migrations for 'birdsong':
  /src/wagtail-birdsong/birdsong/migrations/0005_alter_campaign_id_alter_contacttag_id_and_more.py
    - Alter field id on campaign
    - Alter field id on contacttag
    - Alter field tag on contacttag
    - Alter field id on receipt
    - Alter field success on receipt
Migrations for 'newsletter':
  newsletter/migrations/0001_initial.py
    - Create model Newsletter

The contents of the new birdsong migration are:

# Generated by Django 4.0.3 on 2022-04-11 17:57

from django.db import migrations, models
import django.db.models.deletion

class Migration(migrations.Migration):

    dependencies = [
        ('taggit', '0004_alter_taggeditem_content_type_alter_taggeditem_tag'),
        ('birdsong', '0004_campaign_status'),
    ]

    operations = [
        migrations.AlterField(
            model_name='campaign',
            name='id',
            field=models.BigAutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID'),
        ),
        migrations.AlterField(
            model_name='contacttag',
            name='id',
            field=models.BigAutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID'),
        ),
        migrations.AlterField(
            model_name='contacttag',
            name='tag',
            field=models.ForeignKey(on_delete=django.db.models.deletion.CASCADE, related_name='%(app_label)s_%(class)s_items', to='taggit.tag'),
        ),
        migrations.AlterField(
            model_name='receipt',
            name='id',
            field=models.BigAutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID'),
        ),
        migrations.AlterField(
            model_name='receipt',
            name='success',
            field=models.BooleanField(default=True),
        ),
    ]

It's possible to migrate successfully after running makemigrations, but the additional birdsong migration file is lost once the container is stopped. This then causes issues with any attempts to run makemigrations again:

django.db.migrations.exceptions.NodeNotFoundError: Migration newsletter.0001_initial dependencies reference nonexistent parent node ('birdsong', '0005_alter_campaign_id_alter_contacttag_id_and_more')

My workaround is to add the additional migration file to a fork with a couple of changed needed to use birdsong with Django 4.0. Is this also an issue with earlier versions of Django or something specific to 4.0? Should the additional migration file be committed to birdsong?

Thanks, Mike