Good points. Regarding 1), I can't specially control reconstruction of
fields from migrations and raise errors only in that case - it's just
calling the normal __init__. Since I'm going to have to write out a call to
settings.AUTH_USER_MODEL anyway - the whole point of swappable=True is so
the migration serialiser knows to do that - having swappable be True or
False makes no difference (the only behaviour it affects is the migration
serialiser, for now, and that's never run on re-serialised models).
Nevertheless, I'll make sure it's forced to True just in case.
On 2), that's an issue I hadn't thought of. There's special syntax for
depending on the first migration of an app which I could inject, but it'd
have to be chosen at migration creation time, so not terribly useful. The
only concrete way to make sure this works is to have a dependency that's
defined based on the setting, e.g.
class Migration(migrations.Migration):
dependencies = [
("comments", "0001_initial"),
migrations.swappable_dependency(settings.AUTH_USER_MODEL),
]
That function would just be lambda value: (value.split(".", 1)[0],
"__first__") - we already have the __first__ special migration name which
resolves to the start of any app (it's used for depending on apps with no
migrations at the moment, in case they gain them in future)
Andrew
On Sat, Jan 11, 2014 at 9:43 PM, Shai Berger <s...@platonix.com> wrote:
> On Saturday 11 January 2014 11:45:55 Andrew Godwin wrote:
> > OK, I like that approach Russ - an inverted 1b. It'll be a bit harder to
> > explain in the docs, but it won't catch anyone out unawares, which is the
> > key thing.
> >
> I like it too.
>
> And foot-in-mouth re referencing swappables notwithstanding, there's two
> points I want to raise:
>
> 1) This approach is good for the models files; I think a more explicit
> approach
> should be taken for the migration files, where we don't currently have to
> worry
> about backwards compatibility. I'd like to see swappable=None in the model
> transformed to swappable=True in the migration, and swappable=None in the
> migration treated as an error.
>
> In particular, I don't like Marc's idea about migrations continuing to work
> when a target model, which used to be non-swappable, is being swapped out.
> The
> app's "main" code won't continue to work in this scenario, for reasons Russ
> has noted; I don't see why migrations should not be treated as part of the
> app's code.
>
> 2) Swappability of foreign-key targets in migrations may induce dynamic
> migration dependencies (if my migration creates a foreign key to the user
> model, and that model happens to be in a migrated app, my migration now
> depends on some -- not even necessarily the initial -- migration in that
> app;
> we'll only know at migrate time, not at makemigration time). I'd like to
> make
> this more explicit too -- e.g. add some placeholder, or a function call to
> calculate the dependency, in the generated list of dependencies. Although
> in
> principle it can be induced from the operations, I think it would make
> possible migration dependency issues much easier to troubleshoot.
>
> An alternative would to decree that swappable-replacement models cannot
> live
> in migrated apps; I think that is a very bad option.
>
> Shai.
>
> --
> 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/138953391.ZAfFGT0eZV%40deblack
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
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/CAFwN1upCnbp4%2B0fN0qsENAunKLWaUXZE-hSdW49icmfxBpeL%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
