2012-03-12 26 views
5

Attualmente ho creato un'altra classe/tabella denominata MyAppUser con le mie colonne personalizzate (come indirizzo e numero di telefono) che dispongono di una chiave esterna per l'autenticazione di Django User.Aggiunta di campi personalizzati alla tabella auth_user in Django

Qualcosa di simile

from django.db import models 
from django.contrib.auth.models import User 

class MyAppUser(models.Model) : 
    def __unicode__(self) : 
     return self.user.username 

    user = models.ForeignKey(User) 
    comment = models.TextField(blank = True) 
    phone = models.CharField(max_length = 135, blank = True) 

Il metodo una buona pratica di cui sopra? O dovrei provare a modificare direttamente lo auth_user? E se sì, come lo farei?

Domanda bonus: esiste un modo per chiamare sia la tabella personalizzata User? Ho pensato di provare from django.contrib.auth import models, quindi chiamare models.User, ma penso che sarebbe in conflitto con django.db.models pure. Forse ho bisogno di provare from django.contrib.auth.models import User as AuthUser? E 'questa una buona idea?

risposta

8

Django fornisce supporto integrato per estendere l'utente con le proprie proprietà, chiamate User Profiles. Una buona panoramica su come configurarla è delineata here.

+0

Il documento django è stato aggiornato. Quindi il link a "Profili utente" è https://docs.djangoproject.com/en/1.4/topics/auth/#storing-additional-information-about-users – crossin

+0

Il link restituisce 502 :( –

1

Questo è generalmente il metodo che preferisco, non mi piace toccare l'utente Django solo per sicurezza. In questo modo sai che non entrerai in conflitto con nulla nel modello utente, e renderà chiaro quale codice è il codice quadro e qual è il tuo codice.

Normalmente non lo chiamo MyAppUser ma più spesso, qualcosa come UserSettings. Non desidero che le mie classi correlate all'utente vengano confuse come sostitutive dell'oggetto User, ma forniscono semplicemente ulteriori informazioni.

Generalmente nelle app si hanno chiavi estranee su User dappertutto, quindi utilizzo ancora la classe Django User per tutte quelle. Lo trovo a mantenere le cose pulite.

Ho provato a sottoclasse User e ho trovato che non mi dava molto, e ho finito per confondere le cose, più di quanto dovessero essere.

Problemi correlati