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 <and...@aeracode.org> 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 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/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 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/CAMwjO1H4%3DUOBjwNtmmvBOLR%2BWhWwJkisrMnkSDVJsvYdqOAEng%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
