Personally, I like approach 2. It means that if we (or another 3rd party app) were to make a model swappable, then migrations which don't know about this change would continue to work.
On 8 January 2014 18:00, Andrew Godwin <[email protected]> wrote: > >> Instinctively, I'm almost -1 on 2); I'm not too happy about 1) either. If >> a >> model says it has a FK to auth.User, that shouldn't mean anything other >> than >> auth.User. I don't see that as cleanliness -- it's effectively >> monkeypatching. >> >> 1b seems to me like the most reasonable option. >> > > It's also the least user-friendly option. I don't see the same problem > with 2) - sure, the model says it has an FK to auth.user, and your settings > say that auth.user is swapped out in favour of another model. I think it > would actually be worse if we kept it like it is - since auth.user is > swapped out, it shouldn't have a table made for it, so how are you even > going to make an FK to it? (this is how migrations currently fails - > there's no auth.user left for it to refer to). > > >> >> However, I've had a different thought about this: >> >> > As long as you're not using any third-party apps, then everything works >> > fine >> >> No, it doesn't really. You can't change the user model as part of the >> project >> evolution. Supporting this raises a whole set of additional problems -- >> even >> with 1b, not to mention the scenarios where we try to guess swappables >> from >> concrete models that happen to be their sources or targets. >> >> This is a problem that bugs me personally -- I'm involved in a big project >> that evolved since Django 1.2. As 1.4 (no swappable user model) is LTS, >> I'm >> certain it's not just me. >> > > Changing the user model during the project's lifespan is a different task. > Migrations will nominally support it - in that it'll change all your FK > constraints to immediately point to the new table - but you still have to > manage moving the data into that table yourself, and I'm not sure we can do > it any other way. Migrations sees you changing the user model as an > actionable change, since as far as it's concerned you changed a load of > "to" arguments of foreignkeys when you changed the setting, and so it can > make migrations for that. > > 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. > > 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/CAFwN1uoR0h%3D%2BjOH-12%2BCrMnUH9kqYLpYyt-80SSBEA1T0aB5Nw%40mail.gmail.com > . > > 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 [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/CAMwjO1H4%3DUOBjwNtmmvBOLR%2BWhWwJkisrMnkSDVJsvYdqOAEng%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
