Encapsulating Complex Business Logic in a Migraiton

Standard practice is that you do not refer to "current" models (i.e. from app.models import MyModel) in a migration as the migration will break when that models changes. This means copying any model-specific code into the migration. This becomes impractical when the code needed for the migration spans multiple files and models.

How can I encapsulate a complex chain of business logic involving multiple models in a migration? For example, if I have instance methods on ModelA which calls methods on ModelB, ModelB queries for ModelC and calls methods on it. If I use those methods as they exist on the models, the migration will eventually break when any of the involved Models' schema changes.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/a60b8ed4-a5a6-40c8-b959-17e2a3ec3363%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.