search

stephenmcd / mezzanine

CMS framework for Django
http://mezzanine.jupo.org
BSD 2-Clause "Simplified" License
4.75k stars 1.64k forks source link

[REQUEST] support Django 4.0 and/or DEFAULT_AUTO_FIELD set to django.db.models.BigAutoField #2039

Open go8ose opened 2 years ago

go8ose commented 2 years ago

Is there an existing request for this?

Current problem or need

I'm trying to bring back to life a personal mezzanine site that was running a few years ago, and while I'm doing it I'm updating it's dependencies to the current versions.

While trying to get this site running locally on a development system I've found the "python manage.py migrate" was warning about missing migrations:

Your models in app(s): 'blog', 'conf', 'core', 'forms', 'galleries', 'generic', 'pages' 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.

If I ran python manage.py makemigrations blog then a 0004_auto_20220626_0447.py file was created in the virtualenv site-packages for mezzanine/blog/migrations. Now I'm not an experienced django developer, but that doesn't seem correct.

I found this to occur with django 4.0.6. I found this to occur if I had django 3.2.13 and if I also had DEFAULT_AUTO_FIELD = "django.db.models.BigAutoField".

I've been able to avoid this happening if I use django 3.2.13 and set DEFAULT_AUTO_FIELD = "django.db.models.AutoField"

Desired solution

I guess my desired solution is django 4.0 support, but I can see #2009 was done 6 months ago, so I'm not sure why I'm seeing this, but other people seem to have had success with django 4.0?

I wonder if a solution would be to have someone create migrations within mezzanine with DEFAULT_AUTO_FIELD set to django.db.models.BigAutoField, so that the next release of mezzanine includes these migrations. But I have no idea what that does to backwards compatibility.

Alternatives you have considered

No response

Anything else?

I considered this might actually be my fault, so I used mezzanine-project to create a new project. That project was showing the same behaviour. Here is the output of that:

cooke:~ geoffc$ mezzanine-project test_mezzanine_project
cooke:~ geoffc$ cd test_mezzanine_project/
cooke:test_mezzanine_project geoffc$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, blog, conf, contenttypes, core, django_comments, forms, galleries, generic, pages, redirects, sessions, sites
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 sites.0001_initial... OK
  Applying blog.0001_initial... OK
  Applying blog.0002_auto_20150527_1555... OK
  Applying blog.0003_auto_20170411_0504... OK
  Applying conf.0001_initial... OK
  Applying core.0001_initial... OK
  Applying core.0002_auto_20150414_2140... OK
  Applying django_comments.0001_initial... OK
  Applying django_comments.0002_update_user_email_field_length... OK
  Applying django_comments.0003_add_submit_date_index... OK
  Applying django_comments.0004_add_object_pk_is_removed_index... OK
  Applying pages.0001_initial... OK
  Applying forms.0001_initial... OK
  Applying forms.0002_auto_20141227_0224... OK
  Applying forms.0003_emailfield... OK
  Applying forms.0004_auto_20150517_0510... OK
  Applying forms.0005_auto_20151026_1600... OK
  Applying forms.0006_auto_20170425_2225... OK
  Applying galleries.0001_initial... OK
  Applying galleries.0002_auto_20141227_0224... OK
  Applying generic.0001_initial... OK
  Applying generic.0002_auto_20141227_0224... OK
  Applying generic.0003_auto_20170411_0504... OK
  Applying pages.0002_auto_20141227_0224... OK
  Applying pages.0003_auto_20150527_1555... OK
  Applying pages.0004_auto_20170411_0504... OK
  Applying redirects.0001_initial... OK
  Applying redirects.0002_alter_redirect_new_path_help_text... OK
  Applying sessions.0001_initial... OK
  Applying sites.0002_alter_domain_unique... OK
cooke:test_mezzanine_project geoffc$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, blog, conf, contenttypes, core, django_comments, forms, galleries, generic, pages, redirects, sessions, sites
Running migrations:
  No migrations to apply.
  Your models in app(s): 'blog', 'conf', 'core', 'forms', 'galleries', 'generic', 'pages' 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.
cooke:test_mezzanine_project geoffc$ python manage.py makemigrations blog
Migrations for 'blog':
  /Users/geoffc/.pyenv/versions/3.10.4/envs/geoff-blog/lib/python3.10/site-packages/mezzanine/blog/migrations/0004_auto_20220626_0509.py
    - Alter field id on blogcategory
    - Alter field id on blogpost
hodunov commented 1 year ago

hi, any news?