Answering to myself obviously sqlmigrate can't really do anything with code in RunPython. So I suspect the biggest problem would be something like this:
- early data migration that uses an initial schema a certain model - a later schema migration that changes that so trying to generate the SQL after would not apply because the schema changed in the meanwhile.. On Tuesday, October 4, 2016 at 10:41:25 AM UTC+1, andrea crotti wrote: > > Related to this other thread: > > > https://groups.google.com/forum/#!msg/django-users/V8Ei2qZJ8VI/bFUeY2wTAQAJ;context-place=forum/django-users > > I'm working on trying to find a workaround for migrations killing our > local/CI servers, until there is a better fix in Django stable.. > > So started this project to do some analysis: > https://github.com/AndreaCrotti/django-migrations-analysis > > > One interesting thing is that it looks like using sqlmigrate (taking some > code from it) to generate the raw SQL and composing ti basically generates > exactly the same final schema for the database. > > > https://github.com/AndreaCrotti/django-migrations-analysis/blob/master/commands/sqlmigrate_all.py > > In general the question is, assuming all the settings are the same, can > they differ under some conditions? > I guess for example that using RunPython would cause issues in this case > right? > -- 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+unsubscr...@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/a805f787-0cb3-4166-ac01-b00b8dd718ad%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
