24👍
Somehow, your database has recorded migrations 0002 and 0003 which it can’t find in your migrations folder.
Migration 0002 in your filesystem is 0002_auto__chg_field_asset_username__chg_field_asset_title__chg_field_asset.py while the in in the history table it’s 0002_auto__add_field_asset_is_reserved__add_field_asset_is_created__add_fie.py
South must have been migrated when your migrations folder had different contents (perhaps in development?).
Based on what you’re saying, it looks to me like your database reflects the state at migration 0004, so I’d run a python manage.py migrate myapp 0004 --fake --delete-ghost-migrations which will set the migration table at the point you added the is_assigned field, and you can happily apply migrations 0005+.
You’d know best which migration the current DB table should match though!
7👍
They are considered ghost migrations because the names in the database:
0002_auto__add_field_asset_is_reserved__add_field_asset_is_created__add_fie
0003_auto__del_field_asset_is_reserved__add_field_asset_is_assigned
don’t match the filenames you list:
0003_auto__add_field_asset_is_reserved__add_field_asset_is_created__add_fie.py
0004_auto__del_field_asset_is_reserved__add_field_asset_is_assigned.py
The numbers are part of the filename and must match perfectly. I’m not sure how you reached this state, but if you are absolutely sure that your DB matches what is in your 0004 file, you could add 0002_auto__chg_field_asset_username__chg_field_asset_title__chg_field_asset to the south DB table, then update the two rows so the numbers match your filenames.
Needless to say you should back everything up before doing this.
- [Django]-Django accessing ManyToMany fields from post_save signal
- [Django]-Alternative to the deprecated setup_environ() for one-off django scripts?
- [Django]-Querying full name in Django