Django benutzerdefinierte Benutzermodell Unterklasse (von Zinnia)

Question

Ich habe zu einem benutzerdefinierten Django-Benutzermodell (CustomUser) migriert, in dem mehrere andere Modelle Fremdschlüssel und M2M-Beziehungen haben. CustomUser wird auch von Zinnias Autorenmodell (Autor) unterklassifiziert - Zinnia ist eine ausgezeichnete Third Party Blogging App.

Mein Problem ist, dass wenn ich auf CustomUser über eine Beziehung z. B. OtherModel.customuser zugreifen, es eine Instanz von CustomUser zurückgibt, aber in meinen Ansichten, wenn ich auf request.User zugreifen, ist es eine Instanz von Author. Da die Attribute von Author und CustomUser identisch sind, macht dies im Allgemeinen keinen großen Unterschied, aber wenn ich die Äquivalenz von Benutzerobjekten in meinen Views testen möchte, muss ich user.user.id statt request.user verwenden und ich instinktiv nicht. t wie die Zweideutigkeit, mit welchem ​​Modell ich es zu tun habe.

Möglicherweise bin ich besser darüber hinwegkommen und die Dinge so lassen wie sie sind, da alles nach ein paar kleinen Codeänderungen in meinen Ansichten funktioniert. In einer perfekten Welt würde ich jedoch konsequent auf das gleiche Nutzermodell verweisen, bin aber unsicher, wie ich am besten voran komme. Irgendwelche Ideen?

settings.py

AUTH_USER_MODEL = 'profiles.CustomUser' 

models.py (in Profilen app)

class CustomUser(AbstractUser): 

    visits = models.PositiveIntegerField(
     _('visits'), 
     default=0, 
     blank=True 
    ) 

    def __unicode__(self): 
     return self.username 

class OtherModel(models.Model): 

    author = models.ForeignKey(CustomUser) 

weiß, dass ich die Empfehlung in den documentation ist die Beziehung mit settings.AUTH_USER_MODEL anstatt direkt mit dem machen benutzerdefiniertes Benutzermodell Ich plane, das zu ändern, will aber verstehen, was ich tue, bevor sie wieder in den Schmerz einer Migration starten

author.py (in Zinnie app)

from django.contrib.auth import get_user_model 


@python_2_unicode_compatible 
class Author(get_user_model()): 
    """ 
    Proxy model around :class:`django.contrib.auth.models.get_user_model`. 
    """ 

    objects = get_user_model()._default_manager 
    published = EntryRelatedPublishedManager() 

in den Konsolen get_user_model() gibt die Profile .models.CustomUser class

Answer 1

Ich denke, ich bekomme dein Problem.

Standardmäßig unterdrückt Django keine Modellinstanzen. Für exemple, nehmen Sie das folgende Beispiel:

from django.db import models 

class Parent(models.Model): 
    name = models.CharField() 

class Child(Parent): 
    pass 

Parent(name="parent").save() 
Child(name="child").save() 

Parent.objects.all() # will return Parent instances 
Child.objects.all() # will return Child instances 

In Ihrer Situation, na ja, haben Sie Zinnia mit Author Instanzen arbeiten, und der Rest des Projektes mit CustomUser Instanz. Also im Grunde könnten Sie alle CustomUser Instanz niederwerfen. Sie können dies mit einer vorhandenen Django-Anwendung erreichen, z. B. django-polymorphic (was meiner Meinung nach ein Muss ist, wenn Sie mit konkreter Vererbung arbeiten). Wenn jedoch alle Benutzer nicht Autoren sind, sind Sie

geschraubt

Sie können auch Kompromisse eingehen, und eine manuelle upcast wie folgt implementieren:

from django.contrib.auth import get_user_model 

class CustomUser(AbstractUser): 

    # your logic... 

    def as_custom_user(self): 
     return super(get_user_model(), self) 

Verbrauch:

assert request.user.as_custom_user() == article.author.as_custom_user()