Hi all, Thanks for the rapid responses! I wasn't aware that South imported the custom fields, and I can definitely see why the 1.7 approach is better now. I guess the fact that this never bit me in numerous past projects using South shows it's not really a problem.
I agree that it'd be good to explicitly document this - I'll have a look at that now. Greg On Wednesday, 10 September 2014 09:30:47 UTC+12, Andrew Godwin wrote: > > Carl is correct, South serialized a dotted path to the field while Django > writes an import in, but it's the same thing in the end - the field must > keep existing. The advantage of the Django approach is that it's much more > obviously an import error now and happens immediately. > > I'm happy to firm up the Django docs to reinforce that custom fields must > exist for the lifetime of their usage and beyond, if someone wants to > suggest the changes to make. > > Also worth noting is that Django has the squashmigrations feature and > "replaces" stanza in migration files, meaning it's a lot easier to throw > away old migrations (ones with custom fields that are no longer used) and > start afresh now. > > Andrew > > On Tue, Sep 9, 2014 at 2:27 PM, Carl Meyer <[email protected] > <javascript:>> wrote: > >> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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. >> > > -- 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/76e7f5e9-3a79-48fe-af5f-83db2029b84e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
