Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent makemigrations results #222

Open
xi opened this issue Jun 19, 2018 · 2 comments
Open

Inconsistent makemigrations results #222

xi opened this issue Jun 19, 2018 · 2 comments

Comments

@xi
Copy link
Collaborator

xi commented Jun 19, 2018

When running manage.py makemigrations on different setups, I get different results.

@xi xi self-assigned this Jun 19, 2018
@xi xi mentioned this issue Jun 19, 2018
@xi
Copy link
Collaborator Author

xi commented Jun 20, 2018

In django/db/migrations/autodetector.py line 912 (in generate_altered_fields() directly after if old_field_dec != new_field_dec:) I added the following code for debugging:

print(app_label, model_name, field_name)
print(old_field_dec)
print(new_field_dec)
print()

Then I ran ./manage.py makemigrations --dry-run with different setups. This is what I found so far:

  • I did not find differences between py35 and py36.
  • In both py2 and py3 default=None is removed from devices.models.Device.used_in
  • There are some changes connected to unicode, even in Add Linters #223. For example the choices for users.models.Lageruser.timezone are from pytz.common_timezones. Depending on the python version these are either unicode or byte strings.
  • Sometimes choices are derived from dictionaries. As the ordering of dictionaries is not guaranteed in python, there can be unintended changes.

@xi
Copy link
Collaborator Author

xi commented Apr 19, 2021

We can still have this issue because some model choices depend on settings (e.g. Lageruser.theme) or external libraries (e.g. Lageruser.timezone). I am not sure what to do about that. There was some talk in django about that a while ago (see https://code.djangoproject.com/ticket/22837) but nothing came of it.

I see some options:

  1. live with it
  2. ignore choices in migrations as they have no real impact on the database (e.g. with django-migrations-ignore-attrs (does not look like a mature project on first glance))
  3. Move the choices to the form (I tried this and failed)

xi added a commit that referenced this issue Apr 20, 2021
xi added a commit that referenced this issue Apr 20, 2021
phillipthelen pushed a commit that referenced this issue May 19, 2021
* port CI tests to github actions

* fix lint errors

* pin pytz

See #222
@xi xi mentioned this issue Oct 20, 2021
xi added a commit that referenced this issue Oct 20, 2021
to make CI happy

see #222
xi added a commit that referenced this issue Oct 20, 2021
to make CI happy

see #222
phillipthelen pushed a commit that referenced this issue Feb 22, 2022
* rm defunct tests

* fix Building/Room imports

* add missing requirement

* fix invalid syntax

* fix misc lint issues

* add missing migration

* fix invalid HTML

* avoid inline JavaScript

* alter_lageruser_timezone

to make CI happy

see #222
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant