Project converts installed App's db tables to BigAutoField, breaking migrations

Using Django
1

Thanks in advance for any advice you have.

I have a simple App on pypi which uses models.AutoField.

I install this App in a local Project that has in settings.py:
DEFAULT_AUTO_FIELD = "django.db.models.BigAutoField"

Running ./manage.py makemigrations in the Project creates a new migrations file 0002_alter_cloudavailabilityzone_id_... in the installed App’s migrations dir to convert the AutoField to BigAutoField

Migrations for 'django_cloud_provider_zones':
  <venv>/lib/python3.12/site-packages/django_cloud_provider_zones/migrations/0002_alter_cloudavailabilityzone_id_alter_cloudregion_id.py
    ~ Alter field id on cloudavailabilityzone
    ~ Alter field id on cloudregion
...

The issue is that running ./manage.py migrate for the Project fails when run in a Dockerfile or a clean venv that did not first run makemigrations as the App’s additional migration file is obviously not present when fetched from pypi.

django.db.migrations.exceptions.NodeNotFoundError: Migration catweb.0001_initial dependencies reference nonexistent parent node ('django_cloud_provider_zones', '0002_alter_cloudavailabilityzone_id_alter_cloudregion_id')

This seems potentially like a common issue. I know I can resolve this by aligning the Auto fields in the Project and App, since I control them both. However, I want to know if there other suggestions or best practices I should use to avoid this.

Thanks!

2

I found the answer in the (excellent) Django docs - I should add to the App config AppConfig.default_auto_field in the App published to pypi.

The implicit primary key type to add to models within this app. You can use this to keep AutoField as the primary key type for third party applications.

1 Like