7

I have landed into quite a unique problem. I created the model 1.'message', used it for a while, then i changed it to 2. 'messages' and after that again changed it back to 3. 'message' but this time with many changes in the model fields.

As i got to know afterwards, django migrations gets into some problems while renaming models. In my migrations, some problems have arose. Although I had run all migrations in the right way, while running the 3rd migration for message, i faced few problems that i fixed manually. Now when i ran migration for changes in other models, i found that this migration is still dependent on the 2nd migration of the messages. However, the fields for which it was dependent on the 2nd migration were actually created in third migration.

The traceback i am getting:

ValueError: Lookup failed for model referenced by field activities.Enquiry.message_fk: chat.Message

and:

  Applying contacts.0002_mailsend...Traceback (most recent call last):
  File "/home/sp/webapps/myenv/lib/python3.4/site-packages/django/apps/config.py", line 163, in get_model
    return self.models[model_name.lower()]
KeyError: 'message'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/sp/webapps/myenv/lib/python3.4/site-packages/django/db/migrations/state.py", line 84, in render
    model = self.apps.get_model(lookup_model[0], lookup_model[1])
  File "/home/sp/webapps/myenv/lib/python3.4/site-packages/django/apps/registry.py", line 202, in get_model
    return self.get_app_config(app_label).get_model(model_name.lower())
  File "/home/sp/webapps/myenv/lib/python3.4/site-packages/django/apps/config.py", line 166, in get_model
    "App '%s' doesn't have a '%s' model." % (self.label, model_name))
LookupError: App 'chat' doesn't have a 'message' model.

What i want to ask is whether I should manually edit the dependencies in the migration file to change it from migration 2 to migration 3 in messages.

PS: using django 1.7.2

sprksh
  • 2,204
  • 2
  • 26
  • 43

3 Answers3

7

Normally, You should not edit them manually.

Once you start editing them, you will land into cyclic dependency problems and if you do not remember what changes you made, your entire migrations will be messed up.

What you can do is revert back migrations if you do not have any data to lose. If you are deleting migrations, you should take extra precaution just to ensure that in the migration table no entry remains which points towards unexisting migrations. (I would suggest not to delete migrations manually as it might get complicated.)

If only you have analyzed the migration files and have clear idea as at what position problem has occurred, then only you should think of editing the migration file but don't do it until you can handle it.

In your case, yes the problem might have generated due to renaming and as you say while running a migration you landed into some problem which you fixed manually, it might have happened that the process would have been stuck in between and it created some problem. You can change the dependency and run makemigrations. If there is a circular dependency, it will come directly, then you should revert back the change. Or otherwise, just do a little more analysis and remove the cyclic dependency issue by editing a few more files. (keep backup) If you are lucky or you understand migrations deeply, you might end up with success.

Bip Lob
  • 485
  • 2
  • 6
  • 15
Rohit
  • 475
  • 1
  • 7
  • 16
3

No, I don't think so, you are better off deleting the migration files after the last successful migrations and running it again.

Bernard 'Beta Berlin' Parah
  • 2,129
  • 2
  • 24
  • 42
2

Having gone through the migration management process in different companies, I think it's fine to edit migrations if you know what you are doing. Actually, in many cases you will have to edit existing migrations file or even create new file just to implement a particular change. Few points to be taken care here:

  1. Understand and Maintain the sequence of operations being done.
  2. Be aware of dependencies
  3. Test it before pushing to staging and production
sprksh
  • 2,204
  • 2
  • 26
  • 43