Django-celery-beat: Makemigrations is creating django-celery-beat migration file.

[aroraprince]

Summary:

After adding django-celery-beat to my installed apps, if you run python manage.py makemigrations, it is creating a migration file in django-celery-beat installation directory.

• Celery Version: celery==5.0.5
• Celery-Beat Version: django-celery-beat==2.2.0

Exact steps to reproduce the issue:

1. Added django-celery-beat to installed apps
2. ran python manage.py makemigrations

Detailed information

OS: macOS Big Sur
Python version: 3.9.0, installed via pyenv.

Screenshot link: https://www.dropbox.com/s/d119blepz3nin1i/Screenshot%202021-05-06%20at%209.33.36%20PM.png?dl=0

Ideally no migrations file should be created locally.

[auvipy]

if it is an auto migration without any changes then it was somehow missed from git commit and should be in the package distribution!

[aroraprince]

Yes, it was an auto migration, withou any sort of code change in source.
I can pick this up if needed, seems a pretty small change.

[auvipy]

please send a PR!

[aroraprince]

Okay, will do by 10th May, most probably sooner, I see the contribution guidelines are mentioned in the celery repo.

[aroraprince]

I cloned the repo and tried running python manage.py makemigrations, it is not creating any migration file in that case.
I was using Django==3.2.1, tried with that still the same.

Seems I am missing something here.

[auvipy]

what does python manage.py migrate do?

[aroraprince]

It ran the migration successfully till the 15th migration, without any warning that app is missing a migration to be created.
Since it is a different virtualenv, there is no way the previously created migration file, (no 16 as mentioned in screenshot) will cause any conflict.

I see Django has something new in settings now:
DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'

This could be causing that migration to be created.

[aroraprince]

Django comes with this as default now:

https://docs.djangoproject.com/en/3.2/releases/3.2/#customizing-type-of-auto-created-primary-keys

So this can cause confusion in a lot of projects, this may need some graceful way to handle.
If we explicitly set the datatype of id fields, it should solve the pupose.

[auvipy]

so it is a project-specific issue not to this package. we are not going to change the default value now.

[aroraprince]

I understand why it may be called a project-specific issue.
I am pretty sure since by default settings has this DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField' in the new versions of Django.
This will happen in most of the cases when Django > 3.2 is used, if it is not updated again in future releases.

This can wait till more people report this.

[auvipy]

When defining a model, if no field in a model is defined with primary_key=True an implicit primary key is added. The type of this implicit primary key can now be controlled via the DEFAULT_AUTO_FIELD setting and AppConfig.default_auto_field attribute. No more needing to override primary keys in all models.

Maintaining the historical behavior, the default value for DEFAULT_AUTO_FIELD is AutoField. Starting with 3.2 new projects are generated with DEFAULT_AUTO_FIELD set to BigAutoField. Also, new apps are generated with AppConfig.default_auto_field set to BigAutoField. In a future Django release the default value of DEFAULT_AUTO_FIELD will be changed to BigAutoField.

To avoid unwanted migrations in the future, either explicitly set DEFAULT_AUTO_FIELD to AutoField:

[aroraprince]

Hi was the above comment to add more context?
Do you see this as a valid bug?

[aotella]

Hi
I am facing similar issues. Migrations are being created locally and dependency is being added in the migrations file. When I switch to a different environment I get
django.db.migrations.exceptions.NodeNotFoundError: Migration Project.0006_auto_20210524_1048 dependencies reference nonexistent parent node ('django_celery_beat', '0016_auto_20210510_2155')

Did you by any chance find a fix for it ?

[auvipy]

Hi was the above comment to add more context?
Do you see this as a valid bug?

https://github.com/celery/django-celery-beat/blob/master/django_celery_beat/apps.py#L14 is already in the master just need a new release