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 <ca...@oddbird.net > <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 django-develop...@googlegroups.com <javascript:>. >> To post to this group, send email to django-d...@googlegroups.com >> <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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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.
