Done.
On 10 Sep 2014, at 10:45, Andrew Godwin wrote:
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 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
[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.
--
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/66F3050C-4EF4-4F49-A9B3-EC46793BACCC%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
