How's this? https://github.com/gregplaysguitar/django/commit/b4d486c80ff6bdfaec8f85e724b44ce5e74a5bb6
On Wednesday, 10 September 2014 09:42:52 UTC+12, Greg Brown wrote: > > 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]> 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]. >>> 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. >>> >> >> -- 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/6e4872f8-3b34-48a3-8721-4d4341299178%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
