On Tue, Aug 29, 2017 at 1:43 PM, Matt S <dopelogik@gmail.com> wrote:
-JamesStandard 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.
I would copy any instance method logic in to separate functions that live within the individual migration file. Yes, you'll be copy/pasting code that could live in models, but you need to capture the exact logic used for that migration step, which should never change moving forward. This isn't code that you'll be actively maintaining or referring to and shouldn't change once the migration has been applied.
You do have access to a skeleton version of the models via a RunPython callback in each migration state by calling apps.get_model(), however, it only includes the model fields to be used for querying, not any of the instance methods.
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/CA%2Be%2BciX3ie%3DM3Y8chOmexnUnCCp4RzgxbDVZ-%2BX4YFY2_zOR7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment