> 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 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/CAFwN1urJpcV%2B%2BTU0tGHaRFiR0nfJWzngsChtpnuk%3Dj_YAmXd6A%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
