> I don't see how "you need to remember that auth.User really means some > model > defined in settings" is more user friendly than "you need to remember that > __swappable__.X means that X is swappable". More so, as people already use > auth.get_user_model() -- so, you can monkeypatch *that* when generating > migrations, and let them just keep doing what they do today. >
That's not what people use, they use settings.AUTH_USER_MODEL. See Raphaël's email about that. No, not with any of the three suggestions. The migrations machinery doesn't > introspect the database to find the FK targets -- it re-rolls the > migrations in > memory; and if any of the suggestions is taken, then when you run the > migrations with the setting pointing at some model, it will seem like it > has > always been that way. > No, as the setting only exists in the models file - by the time it gets into a migration (the things which are re-run) it's been baked into a real model reference (of whatever the setting was at the time). Option 1b would preserve this behaviour by default; the other two eradicate it and make history changing of AUTH_USER_MODEL invisible in two different ways. > > > The problem is when the migrations are pre-made - i.e. from third-party > > apps - and that's the issue I'm trying to solve. > > > > The two problems are in conflict -- for evolving the user model, history > must > matter; for pre-made migrations, the choice of user model needs to look > like > it has always been the way it is "now" (at the time the migrations are > run). Yes, and I personally think the pre-made migrations problem is more important. I don't think people should change user model mid-project on a whim - there's a lot of manual work they'd always have to do to port all their user data over losslessly ignoring just this foreign key problem - and if they do, I think we recommend they start again with their migrations. The only solution that I can see which somehow gives something to both sides - 1b - makes it really, really easy for third-party apps to ship broken migrations and not know about it, and I don't like that. I think we have to sacrifice being able to tell that the user model was changed in favour of having the app ecosystem actually work. 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 [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/CAFwN1urJpcV%2B%2BTU0tGHaRFiR0nfJWzngsChtpnuk%3Dj_YAmXd6A%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
