Djangorestframework-simplejwt: Makemigrations create new migrations for models in token_blacklist app

[Alig1493]

Hello,

Everytime I try to run the migrations for my apps in django, new migrations are created for the token_blacklist applications. Is this how it's supposed to be?
Currently found on versions 4.5.0 and 4.6.0.

Your models in app(s): 'token_blacklist' 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.
root@6d2b2b13006d:/app# python manage.py makemigrations
Migrations for 'token_blacklist':
  /usr/local/lib/python3.9/site-packages/rest_framework_simplejwt/token_blacklist/migrations/0008_auto_20210424_0948.py
    - Alter field id on blacklistedtoken
    - Alter field id on outstandingtoken

[Andrew-Chen-Wang]

I'm not sure where that's coming from. This may be due to new features in Django. What Django version are you using? Do you mind posting that new migration file? Thanks!

[Alig1493]

Sincere apologies for the tardiness I got caught up in personal errands.
Django version: 3.2
Migration file:

# Generated by Django 3.2 on 2021-05-02 18:44

from django.db import migrations, models


class Migration(migrations.Migration):

    dependencies = [
        ('token_blacklist', '0007_auto_20171017_2214'),
    ]

    operations = [
        migrations.AlterField(
            model_name='blacklistedtoken',
            name='id',
            field=models.BigAutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID'),
        ),
        migrations.AlterField(
            model_name='outstandingtoken',
            name='id',
            field=models.BigAutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID'),
        ),
    ]

Might have something to do with this latest Django 3.2 changelog I believe.

Appreciate your response! Thanks.

[Andrew-Chen-Wang]

np about tardiness. It seems like that change definitely makes sense. Is there any database that doesn't support 8 bytes to store integers? Not sure if we want to define the AutoField, but then again it's technically already been defined as AutoField for a long time.

Do you mind telling me which database you're using? I have doubts about proper migration from AutoField to BigAutoField (especially after seeing this ticket: https://code.djangoproject.com/ticket/30266)

[Alig1493]

I'm using postgres 12. Running it as a docker image at the moment.
Here

[Andrew-Chen-Wang]

Note: this happened due to Django 3.2 having a setting that can identify what the primary key field will be (i.e. either AutoField or BigAutoField). I think it's safe to say we can safely migrate to BigAutoField since Django used to have AutoField on by default but not it's BigAutoField as the default.

[Alig1493]

Okay. I can handle the migrations with some commands on application initializations for now. Willi you be adding the new migrations in your next release? I think I can work on it if you open this up as an issue and implement any other ideas if you might have regarding this Django settings change.

[Andrew-Chen-Wang]

I have no issue with you creating a PR for this (considering I can't merge anything I create myself)! Can't guarantee if it'll be in the next release, but I think it can make it.

Just make sure you update the CHANGELOG under Version 4.7 alongside the migration file! In our settings.py file, it'd be great if you could add that setting that defaults id field to BigAutoField so in our tests we can avoid a CI warning.

[Alig1493]

Noted. I'll start working and I'll have a MR for you to review.

[Alig1493]

@Andrew-Chen-Wang I've set up the project and seems to be running fine. Could you direct me as to how I might be able to run the django commands to generate the migrations and run other related django commands? Maybe I've missed some instructions that are there so would appreciate the assistance. Thank you.

[Andrew-Chen-Wang]

Can you clarify what django commands you're talking about? Typically any command is done through python manage.py blah.

[Alig1493]

Can you clarify what django commands you're talking about? Typically any command is done through python manage.py blah.

Yes, as in I can do that when using the library in an application but there's no manage.py file here within the library itself so I was wondering if there's another way to do it when working on updates for the library itself.

Regardless I did generate and post a migrations file that addresses the changes regarding the primary keys in django 3.2. If you could review it and give me some feedback that would be helpful.

Thank You.