Hi Greg, On 09/09/2014 03:00 PM, Greg Brown wrote: > Moving over to the new migrations, I noticed that whenever I > create a migration involving a custom model field, it imports that field > at the top of the migration. The South docs were always quite firm about > not doing this sort of thing, in case the code changed in the future. Is > this a design decision, i.e. we now expected to make sure imports in our > migration files always work in the future? What are the reasons for > this? I can imagine this causing issues when refactoring old code for > example.
Andrew can correct me if I'm wrong, but I don't believe anything significant has changed in this particular respect from South to Django migrations. South serialized a dotted-path reference to custom field classes in its frozen dict, whereas Django imports them in the migration file, but the effect is identical; when the migration is run, the custom field class is imported and used in the reconstructed model. In both South and Django migrations, changing the import location of a custom field will break past migrations (unless you fix them - and fixing them is more obvious and straightforward in Django migrations) and changing the behavior of a custom field class could change the behavior of a past migration. I don't believe that either South or Django has a feasible alternative, since serializing/freezing arbitrary Python code is not workable. When you say "the South docs were always quite firm about not doing this sort of thing", you may be thinking of importing models directly into your migration file. This is equally discouraged in both. Unlike custom field classes, South and Django migrations do freeze (or actually reconstruct, in the case of Django migrations) the structure of your models (but not arbitrary methods; Python code again) at the time of the migration, so if you import a model directly rather than using the frozen version, it may not match your database tables. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/540F70BA.4020404%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
