Opened 4 years ago
Last modified 4 years ago
#32689 closed Bug
Infinite AlterField Migrations due to default callable object missmatch — at Version 1
Reported by: | Samuel Bishop | Owned by: | nobody |
---|---|---|---|
Component: | Migrations | Version: | 3.2 |
Severity: | Normal | Keywords: | infinite, makemigrations, migrations, callable, default, field |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
makemigration
will generate infinite migrations if the callable path is miss-matched such that you end up with two discreet callable objects (I'm still trying to identify where exactly the migration framework is generating this missmatch, I can see the difference stepping through MigrationAutodetector.generate_altered_fields
in the debugger but I'm not sure if the root cause is inside generate_altered_fields
, another method on MigrationAutodetector
or somewhere else entirely...) then the same migration is generated every time you run the command which results in no actual change to the database.
In my case it's from a custom field library being used as a primary key.
I was importing from ulid.api import new as new_ulid
and setting default=new_ulid
, but unless I swap to import ulid.api.api
and set default=ulid.api.api.Api.new
I just get a new identical migration altering the field's default value to ulid.api.api.Api.new
every time i run makemigrations
I would have expected either a clear warning detailing why my choice of callable object for the default=
will cause issues, or I would have expected makemigrations
to not mutate my callable like this.