You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, thank you again for this library, and thank you for your recent changes to support MySQL. A follow up on my earlier issue is that I ended up creating a version of this where I alter Django's default dependency graph so that pre-deploy migrations can always be run on their own, even if out of sequence. I am not planning to submit a pull request for this, although please let me know if you are interested in this concept and I can explain more (it relies on the concept that a pre-deploy migration need never actually rely on a post-deploy migration).
Anyhow, this issue is a bug report
First bug
This is a bug that causes migrations containing RenameField and (I suspect) RenameModel operations to fail completely.
Steps to reproduce:
Rename a field
Run makemigrations
Confirm field renaming in questioning flow
Select one of the two latter options
Now try to plan/run the newly generated migration using python manage.py migrate. You get an error trace like this:
File "/Users/admin/ClipsalRepos/helios/clippy/migrations/0156_rename_nem3_state_tariffrate_nem4_state.py", line 7, in <module>
class Migration(migrations.Migration):
File "/Users/admin/ClipsalRepos/helios/clippy/migrations/0156_rename_nem3_state_tariffrate_nem4_state.py", line 14, in Migration
syzygy.operations.RenameField(),
File "/Users/admin/Library/Caches/pypoetry/virtualenvs/helios-EL_XmWmL-py3.10/lib/python3.10/site-packages/syzygy/operations.py", line 309, in __init__
self.stage = kwargs.pop("stage")
KeyError: 'stage'
Commentary
Line 120 in autodetector.py is meant to prevent this: operation = RenameField.for_stage(operation, stage) by re-initialising the operation class with the appropriate stage
But the generated migration uses a new instance of this class, so this line does nothing.
Second Bug
The questioner flow uses 0-based indexing for the choices but it should be 1-based indexing because they're displayed as 1, 2, 3, 4.
Apologies if I somehow misunderstood something with regard to either of these two bugs
The text was updated successfully, but these errors were encountered:
ThomasAitken
changed the title
Two Bugs: RenameField and RenameModel operations don't work
Bug Report: RenameField and RenameModel operations don't work
Jan 24, 2025
First of all, thank you again for this library, and thank you for your recent changes to support MySQL. A follow up on my earlier issue is that I ended up creating a version of this where I alter Django's default dependency graph so that pre-deploy migrations can always be run on their own, even if out of sequence. I am not planning to submit a pull request for this, although please let me know if you are interested in this concept and I can explain more (it relies on the concept that a pre-deploy migration need never actually rely on a post-deploy migration).
Anyhow, this issue is a bug report
First bug
This is a bug that causes migrations containing RenameField and (I suspect) RenameModel operations to fail completely.
Steps to reproduce:
makemigrations
Now try to plan/run the newly generated migration using
python manage.py migrate
. You get an error trace like this:Commentary
Line 120 in
autodetector.py
is meant to prevent this:operation = RenameField.for_stage(operation, stage)
by re-initialising the operation class with the appropriate stageBut the generated migration uses a new instance of this class, so this line does nothing.
Second Bug
The questioner flow uses 0-based indexing for the choices but it should be 1-based indexing because they're displayed as
1, 2, 3, 4
.Apologies if I somehow misunderstood something with regard to either of these two bugs
The text was updated successfully, but these errors were encountered: