Hi Tobias & Daniel, On 11/18/2014 09:10 AM, Daniel Roseman wrote: > On Tuesday, 18 November 2014 15:04:19 UTC, Tobias Dacoir wrote: > > I'm trying to figure out how to create my Custom User Model. > > In the official docs I basically found two different strategies: > Extending User Model or Custom User Model: > > https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#extending-the-existing-user-model > > <https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#extending-the-existing-user-model> > > Extending means I have a OnetoOne Relationship to the User Table in > my own UserProfile Model, whereas the other method inherits from > AbstractBaseUser and looks quite complicated with a lot of warnings > that I can't not change this easily after I created my database. > > I want to design a web app where users can log in and once log in > take some kind of surveys. For this I want to make use of Django's > Authentication methods, so only registered and logged in Users can > take part in the survey. However I want to save additional data for > each User in the database, like Age, Country, Score and so on. In > the Admin interface it would be great if I could just select a User > Entry and see all fields, the default from the User Model plus my > added fields. > > It might be a good idea to use OAuth later on as well, to be able to > have users authenticate through Facebook and so on, however that is > not required right now (I did create quick test project for the > social auth plugin and it worked). Still I don't really understand > the differences between those two methods and google didn't help me > because most tutorials show either route but never say why one is > better than the other. > > So which should I use in my case? > > > In the case you describe, there's not really a lot to choose between the > two approaches. Either you extend the user model with a related profile, > in which case you configure the admin to show the profile as an inline > underneath the main fields, or you substitute your own model (which > probably inherits from AbstractUser), in which case the admin shows all > the fields in one section. Personally I prefer the tidiness of custom > models, especially as you save a db query every time.
I agree with this advice. Especially because you can't (without great pain) change the value of AUTH_USER_MODEL after you start the project -- but if you have a custom user model, you can easily generate migrations to change it (add fields, remove fields, alter fields, etc). So if you start with the built-in User model, you're stuck with it as-is forever (unless you use ugly monkeypatch hacks), but if you start out with a custom User model (even if initially it's no different from the default) you have more flexibility going forward. Carl -- You received this message because you are subscribed to the Google Groups "Django users" 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-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/546B7185.5010200%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
