Django 1.7 migrations and third-party imports

[Greg Brown]

Hi all,

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.

Thanks,
Greg

[Daniele Procida]

On Tue, Sep 9, 2014, Greg Brown <gregpla...@gmail.com> 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?

Hi Greg,

You'll get answers to your questions on the django-users email list, <django-d...@googlegroups.com> - the web interface is <https://groups.google.com/forum/#!forum/django-users>.

The list you've posted to is django-developers, an email list is for the discussion of the development of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net.

Daniele

[Tim Graham]

Questions related to design decisions are a valid topic for django-developers.

In this case, please see this documentation: https://docs.djangoproject.com/en/dev/topics/migrations/#historical-models

Perhaps Andrew may want to explain the design decision further.

[Carl Meyer]

Hi Greg,

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

[Andrew Godwin]

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

--
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.
To post to this group, send email to django-d...@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/540F70BA.4020404%40oddbird.net.

For more options, visit https://groups.google.com/d/optout.

[Greg Brown]

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

[Greg Brown]

How's this?

https://github.com/gregplaysguitar/django/commit/b4d486c80ff6bdfaec8f85e724b44ce5e74a5bb6

[Andrew Godwin]

Looks good - make a pull request and I'll hit merge.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6e4872f8-3b34-48a3-8721-4d4341299178%40googlegroups.com.

[Greg Brown]

Done.

>> <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 a topic in the

> Google Groups "Django developers" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/x7YSPAakX0Y/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> django-develop...@googlegroups.com.
> To post to this group, send email to
> django-d...@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/CAFwN1uqSFMKP4R%2B6%2Bm1Z82xz9YaPN2V3bFzN-mibWyKYUQxOew%40mail.gmail.com.