L'extension de l'Utilisateur de l'objet dans Django: modèle d'utilisation de l'héritage ou de l'utilisation de l'Utilisateur?

À étendre l'objet de l'Utilisateur avec des champs personnalisés, les Django docs vous recommandons d'utiliser Userprofile. Toutefois, selon cette réponse à une question à ce sujet à partir d'un an en arrière:

l'extension de django.contrib.auth.modèles.L'utilisateur fonctionne mieux maintenant-depuis le refactoring de Django héritage du code dans les modèles de l'API.

Et des articles tels que des cette définir comment étendre le modèle de l'Utilisateur avec des champs personnalisés, avec les avantages de la récupération des propriétés directement auprès de l'utilisateur de l'objet, plutôt que par le biais de la .get_profile()).

Donc je me demandais si il n'y a aucun consensus sur cette question, ou de raisons d'utiliser l'un ou l'autre. Ou même ce que le Django de l'équipe actuellement en pensez?

Double Possible de Étendre le modèle de l'Utilisateur avec des champs personnalisés dans Django

OriginalL'auteur Chris | 2010-05-03

  1. 8

    Je vote pour à l'aide de Userprofile.

    - Je utiliser plusieurs apps tierce partie. Et une clé étrangère pour un Utilisateur aura toujours le Point d'auth.modèles.De l'utilisateur.

    Exemple:

    class Article(models.Model):
    user = models.ForeignKey('auth.User') # instead of your CustomUser
    text = ....

    Et personnalisé de l'Utilisateur modèle:

    class CustomUser(User):
    timezone = models.CharField(max_length=50, default='Europe/London')

    # Use UserManager to get the create_user method, etc.
    objects = UserManager()

    Ce qui va se produire si vous avez accès de l'utilisateur sur le terrain à travers un Article de l'instance?
    Cela va déclencher une exception:

    u = a_article.user
u.timezone

AttributeError: 'User' object has no attribute 'timezone'

    Peut-être que ce n'est pas un problème pour vous et que vous voulez pas à éviter la DB supplémentaires de la requête.
    Mais je voudrais utiliser le get_profile.

    Mise à JOUR Mai 2013

    Depuis Django 1.5 vous pouvez étendre l'Utilisateur par défaut du modèle, ou remplacer avec un modèle personnalisé.

    Mise à JOUR Novembre, 2016

    La solution ci-dessus est obsolète, voir le commentaire de la part de wim

    Cela permettra de créer des dépendances question dans django 1.7 migrations
    Ces jours-ci, un tiers des applications doit ont settings.AUTH_USER_MODEL que le rapport, si elles sont codées en dur 'auth.User' alors que c'est la faute de tiers ..

    OriginalL'auteur maersu

  2. 2

    Voici ce que James Bennett dit dans ce l'entrée de blog à propos du modèle de l'héritage:

    J'avais parier que probablement 90% ou plus de choses que les gens disent qu'ils veulent faire avec les sous-classes pourrait être mieux accomplie par la place de la définition d'un modèle et d'établir un lien de retour avec une unique clé étrangère.

    Donc, je crois que la meilleure façon est encore d'utiliser une application externe, comme certains composants de Pinax, ou le django-profils application (à l'origine de la même James Bennett).

    OriginalL'auteur Olivier Verdier