Re: Encapsulating Complex Business Logic in a Migraiton

Hello,

Another option that might or might not work would be to violate the rule and do refer to "current" models during the migration to version X, but thereafter reset your migrations and only support migration to X+1 from X, not from earlier versions. This would need detailed release notes about the migration procedure, so whether it's a decent solution depends on your release management practices.

Regards,

Antonis

Antonis Christofides  http://djangodeployment.com

On 2017-08-29 23:43, Matt S wrote:

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.