使用django.contrib.auth.models导入用户时，是否需要在models.py中创建单独的类？

Question

The import statement import the needed parts. but is the "user" class already made when you put that into your installed apps? or do you still need to clarify in models.py in order to make the table in the db? or can someone expand on how to use django users and sessions? I'm looking over the django docs right now and they all just go over how to use the thing once. they never put the code in a syntax where users are going to be the ones using the code through a browser and not you through a python shell.

Answer 1

All installed apps can contribute to the database schema. django.contrib.auth.models contributes, among others, the auth_user table behind the django.contrib.auth.models.User model, therefore you do not have to worry about recreating it unless you have a specific reason to do so.

Answer 2

There's a number of things going on here. As you're aware, Django comes with a number of "contrib" packages that can be used in your app. You "activate" these by putting them into your INSTALLED_APPS .

When you run python manage.py syncdb , Django parse the models.py files of every app in INSTALLED_APPS and creates the associated tables in your database. So, once you have added django.contrib.auth to your INSTALLED_APPS and ran syncdb , the tables for User and Group are there and ready to be used.

Now, if you want to use these models in your other apps, you can import them, as you mention, with something like from django.contrib.auth.models import User . You can then do something like create a ForeignKey , OneToOneField or ManyToManyField on one of your models to the User model. When you do this, no tables are created (with the exception of ManyToManyField ; more on that in a bit). The same table is always used for User , just as for any of your own models that you might create relationships between.

ManyToManyField s are slightly different in that an intermediary table is created (often called a "join table") that links both sides of the relationship together. However, this is purely for the purposes of that one particular relationship -- nothing about the actual User table is different or changed in any way.

The point is that one table is created for User and this same table is used to store all User s no matter what context they were created in. You can import User into any and all of your apps, create as many and as varied relationships as you like and nothing really changes as far as User is concerned.

Answer 3

If the table name or something else does not fit in your needs you can always just extend the User model.

from django.contrib.auth.models import User

class Employee(User):
    ...

Answer 4

Any class extending Model class in models.py contributes to database schema. That means, django search your (and also django core) model.py files and looks for any class that extends Model like:

some models.py

class SomeModel(Model):
    ...
    ...

class Otherthing(Model):
    ...

that is also applies for django core code files. Since all Database tables named using application label and model name, database ables created by django also have that...

For example,

from django.contrib.auth.models import User

If you track file hierarchy django -> contrib -> auth and open models.py file, you will see related model. Ther are also other Model classes in here, like Permission and Group models.

Since these models are under auth application, database tables are auth_user , auth_perission and auth_group

When you run manage.py syncdb command for the first time, django will create these tables...