I second this; I would have moved to having auth.User be abstract, and force projects to create their own _always_, except (a) it breaks a lot of history, and (b) it breaks the "ready to go out of the box" nature.
It's a small cost at the start of your project, that avoids problems for a sizable portion of all projects which end up customising User. It also makes it more obvious that you _can_ customise user; that it's just like any other model. -- C On Fri, 29 Jan 2021, at 02:00, Ken Whitesell wrote: > I can see where you might think that, but I actually believe it should go in > the other direction - that the User model should be the absolute _minimum_ of > an entity. > > 1. The User model is retrieved with every authenticated request. The more > fields in the model, the more data is being handled unnecessarily. (Do you > really need the User phone number with every request?) > > 2. If you go in that direction, there's no way you're going to reach a > consensus as to what fields should be included, or to make a valid argument > against field "X" once field "Y" has been added - ending up with an extremely > over-bloated object. > > 3. It's too easy to extend or replace the user model. The process is > well-documented. Saying "some developers don't want to" do something doesn't > constitute a reason. > > (I'm an extremist in the other direction. I believe that the User model > should only consist of the PK, and an "active" flag. All other information > can be stored in ancillary tables - but I acknowledge that that's very much a > minority position as well.) > > > On 1/28/2021 8:25 AM, Muhammad Shehzad wrote: >> Hey Developers! Some fields should be inside *models.**User* e.g. image, >> phone_number. Some developers don't want to extend the auth model. Yes i >> know there are some ways to extends the auth model. But i think these fields >> should come with *models.**User* >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/da95c74b-413c-41f0-85b5-9bef2320eecfn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/da95c74b-413c-41f0-85b5-9bef2320eecfn%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/d0f5e304-f1f1-19d0-4300-37f3961b270b%40comcast.net > > <https://groups.google.com/d/msgid/django-developers/d0f5e304-f1f1-19d0-4300-37f3961b270b%40comcast.net?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a709adc2-1656-4e6c-b8af-9f01805552fa%40www.fastmail.com.
