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
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:
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: