Looks good - make a pull request and I'll hit merge. On Tue, Sep 9, 2014 at 3:05 PM, Greg Brown <[email protected]> wrote:
> 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 > <https://groups.google.com/d/msgid/django-developers/6e4872f8-3b34-48a3-8721-4d4341299178%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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/CAFwN1uqSFMKP4R%2B6%2Bm1Z82xz9YaPN2V3bFzN-mibWyKYUQxOew%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
