2012-03-12 19 views
5

Actualmente creé otra clase/tabla llamada MyAppUser con mis columnas personalizadas (como dirección y número de teléfono) que tienen una clave externa para la autenticación de Django User.Agregar campos personalizados a la tabla auth_user en Django

Algo como esto

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) 

Es el método por encima de una buena práctica? ¿O debería tratar de modificar el auth_user directamente? Y si es así, ¿cómo lo haría?

Pregunta de bonificación: ¿Hay alguna forma de que se llame también a mi tabla personalizada User? Pensé en probar from django.contrib.auth import models, y luego llamar al models.User, pero creo que eso también entraría en conflicto con django.db.models. Tal vez deba probar from django.contrib.auth.models import User as AuthUser? ¿Es esta una buena idea?

Respuesta

8

Django proporciona soporte integrado para extender al usuario sus propias propiedades, llamadas User Profiles. Se describe una buena descripción rápida de cómo configurarlo here.

+0

El django doc se ha actualizado. El enlace a 'Perfiles de usuario' es https://docs.djangoproject.com/en/1.4/topics/auth/#storing-additional-information-about-users – crossin

+0

El enlace devuelve 502 :( –

1

Ese es generalmente el método que prefiero, no me gusta tocar al usuario de Django solo para estar seguro. De esta forma sabrá que no va a entrar en conflicto con nada en el modelo de usuario, y deja en claro qué código es el código de infraestructura y cuál es su código.

Normalmente no lo llamo MyAppUser pero más generalmente, algo así como UserSettings. No quiero que mis clases relacionadas con el usuario se confundan como reemplazos para el objeto User, sino que simplemente proporcione más información.

Generalmente, en las aplicaciones, tendrá claves foráneas en User en todas partes, así que sigo utilizando la clase Django User para todas las demás. Lo encuentro para mantener las cosas más limpias.

He intentado subclase User y encontré que no me dio mucho, y terminé confundiendo las cosas, más de lo que necesitaban.

Cuestiones relacionadas