Missing migrations

[laynel-lk]

django-q version 1.3.8:

$ poetry show django-q
name         : django-q
version      : 1.3.8
description  : A multiprocessing distributed task queue for Django

dependencies
 - arrow >=1.1.0,<2.0.0
 - blessed >=1.17.6,<2.0.0
 - django >=2.2
 - django-picklefield >=3.0.1,<4.0.0
 - redis >=3.5.3,<4.0.0

Run ./manage.py makemigrations:

$ poetry run python manage.py makemigrations
Migrations for 'django_q':
  /home/<user>/.cache/pypoetry/virtualenvs/scraper-l9iOEXUD-py3.8/lib/python3.8/site-packages/django_q/migrations/0015_auto_20210624_2029.py
    - Alter field id on ormq
    - Alter field id on schedule
...

This is a problem because I have a model in my project with a ForeignKey(django_q.Schedule) field. My migrations now have a dependency to the migration file I generated with makemigrations. This will cause problems when someone finally adds migrations to this project and we have conflicting files.

I confirmed that this migration file is also missing from 1.3.9.

[Koed00]

We added id defaults in 1.3.8 which is a requirement for Django 3.2. I am guessing you have a custom default type set?

[laynel-lk]

I don't know what you mean by "custom default type set". What I'm saying is that it appears that you didn't commit a migration file.

On Sat, Jun 26, 2021, 06:05 Ilan Steemers @.***> wrote:

We added id defaults in 1.3.8 which is a requirement for Django 3.2. I am guessing you have a custom default type set?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Koed00/django-q/issues/584#issuecomment-868991786, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUMKXRZ33XBXEYAV3O7K6RTTUW7B7ANCNFSM47ITC6JQ .

[laynel-lk]

@Koed00 I will come up with a more complete MRE (or potentially a PR) when I have some time later this week.

[Koed00]

Can you check 1.3.9? I didn't realize it hadn't been released on Pypi yet.

[laynel-lk]

@Koed00 Yes, I did before posting:

I confirmed that this migration file is also missing from 1.3.9.

Specifically, I see 0014_schedule_cluster.py in https://github.com/Koed00/django-q/tree/master/django_q/migrations, but when I run makemigrations as shown in my OP, it generates a 0015 migration.

[laynel-lk]

@Koed00 Here's a more direct error message that shows the problem:

$ ./manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, django_q, my_app, sessions
Running migrations:
  No migrations to apply.
  Your models in app(s): 'django_q' have changes that are not yet reflected in a migration, and so won't be applied.
  Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.

As my OP shows, when I run ./manage.py makemigrations, the migrations are generated.

I am on Django Q 1.3.9

[laynel-lk]

We added id defaults in 1.3.8 which is a requirement for Django 3.2.

I suspect this is most likely the problem. You added DEFAULT_AUTO_FIELD to your settings.py but did not run ./manage.py makemigrations nor committed the generated migrations file.

[codeguru42]

Here's a more precise reproduction recipe:

1. Create a new Django project. I did this in pycharm, but you can do it with the command line, too:

   pip install django
   django-admin startproject mysite
   

2. Install Django-Q

   pip install django-q==1.3.8
   

3. Add 'django_q' to INSTALLED_APPS.
4. Run ./manage.py migrate.

   Operations to perform:
     Apply all migrations: admin, auth, contenttypes, django_q, sessions
   Running migrations:
     Applying contenttypes.0001_initial... OK
     Applying auth.0001_initial... OK
     Applying admin.0001_initial... OK
     Applying admin.0002_logentry_remove_auto_add... OK
     Applying admin.0003_logentry_add_action_flag_choices... OK
     Applying contenttypes.0002_remove_content_type_name... OK
     Applying auth.0002_alter_permission_name_max_length... OK
     Applying auth.0003_alter_user_email_max_length... OK
     Applying auth.0004_alter_user_username_opts... OK
     Applying auth.0005_alter_user_last_login_null... OK
     Applying auth.0006_require_contenttypes_0002... OK
     Applying auth.0007_alter_validators_add_error_messages... OK
     Applying auth.0008_alter_user_username_max_length... OK
     Applying auth.0009_alter_user_last_name_max_length... OK
     Applying auth.0010_alter_group_name_max_length... OK
     Applying auth.0011_update_proxy_permissions... OK
     Applying auth.0012_alter_user_first_name_max_length... OK
     Applying django_q.0001_initial... OK
     Applying django_q.0002_auto_20150630_1624... OK
     Applying django_q.0003_auto_20150708_1326... OK
     Applying django_q.0004_auto_20150710_1043... OK
     Applying django_q.0005_auto_20150718_1506... OK
     Applying django_q.0006_auto_20150805_1817... OK
     Applying django_q.0007_ormq... OK
     Applying django_q.0008_auto_20160224_1026... OK
     Applying django_q.0009_auto_20171009_0915... OK
     Applying django_q.0010_auto_20200610_0856... OK
     Applying django_q.0011_auto_20200628_1055... OK
     Applying django_q.0012_auto_20200702_1608... OK
     Applying django_q.0013_task_attempt_count... OK
     Applying django_q.0014_schedule_cluster... OK
     Applying sessions.0001_initial... OK
   

5. Run ./manage.py migrate again:

   Operations to perform:
     Apply all migrations: admin, auth, contenttypes, django_q, sessions
   Running migrations:
     No migrations to apply.
     Your models in app(s): 'django_q' have changes that are not yet reflected in a migration, and so won't be applied.
     Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.
   

Step 5 might happen if for instance, you make changes to your project's models and have to apply new migrations to a production installation.

[codeguru42]

When I run pip install --upgrade django-q then ./manage.py migrate, I no longer see the message that model changes are not reflected in a migration.

@Koed00 This issue can be closed.