Extend user model: class inheritance or OneToOneField?

[sdonk]

Hi,
I'm starting a new project and for the first time I need to extend the User model.
I read the documentation and I googled a lot to try to figure out what is the best approach but I got confused.

What's the the best approach?

Class inheritance:

from django.contrib.gis.db import models
from django.contrib.auth.models import User, UserManager

class myUser(User):
    birthday = models.DateField(null=True, blank=True)
    address = models.CharField(max_length=255, null=True, blank=True)
   
    objects = UserManager()

Or OneToOneField (as doc suggests)


from django.contrib.gis.db import models
from django.contrib.auth.models import User
from django.db.models.signals import post_save

class myUser(User):
    user = models.OneToOneField(User)
    birthday = models.DateField(null=True, blank=True)
    address = models.CharField(max_length=255, null=True, blank=True)

    def __unicode__(self):
          return u'%s' % self.user

def create_user_profile(sender, instance, created, **kwargs):
    if created:
        myUser.objects.create(user=instance)

post_save.connect(create_user_profile, sender=User)

Thanks,

Alex

[Ernesto Guevara]

Hi!

I prefer using OnetoOne with a pre_delete signal to remove user from a pirncipal object instance:

from django.contrib.auth.models import User
from django.db.models.signals import pre_delete
from django.dispatch import receiver

class Customer(User):
    user = models.OneToOneField(User)

@receiver(pre_delete, sender=Customer)
def delete_user_customer(sender, instance, **kwargs):
    user = User.objects.filter(pk=instance.user.id)
    if user:
        user.delete()

class Seller(User):
    user = models.OneToOneField(User)

@receiver(pre_delete, sender=Seller)
def delete_user_seller(sender, instance, **kwargs):
    user = User.objects.filter(pk=instance.user.id)
    if user:
        user.delete()

2012/7/13 sdonk <alessand...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/KtEPwiHoWbUJ.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

[Melvyn Sopacua]

On 14-7-2012 0:18, sdonk wrote:

> I'm starting a new project and for the first time I need to extend the User
> model.

Important question: Why?

> I read the documentation and I googled a lot to try to figure out what is
> the best approach but I got confused.
>
> What's the the best approach?

Depends on the why. A site (as in a project) only allows one user
profile, so applications calling user.get_user_profile() cannot rely on
their version of the profile being returned. That's one important reason
not to follow the documentation recommendation.
Also, when subclassing you shall not set objects to UserManager. This
will make several queries fail in unexpected ways. Instead, set objects
to the default manager and provide a separate property for the user manager.
When you additionally need to add more information to Group and thus
subclass it, then things get complex real fast.
Having tried this exercise I've now decided to write my own auth package
all together.
--
Melvyn Sopacua

[Alessandro De Noia]

Hi


2012/7/14 Melvyn Sopacua <m.r.s...@gmail.com>

Important question: Why?

I need to store more information about the user, like birthday, language preference etc
Moreover I need to have two different  users and store different information for each user type.
In a near future I will need to integrate auth and facebook login as well (using django-oauth-plus)

Depends on the why. A site (as in a project) only allows one user
profile, so applications calling user.get_user_profile() cannot rely on
their version of the profile being returned. That's one important reason
not to follow the documentation recommendation.
Also, when subclassing you shall not set objects to UserManager. This
will make several queries fail in unexpected ways. Instead, set objects
to the default manager and provide a separate property for the user manager.

Can you please explain better the last part?
 

When you additionally need to add more information to Group and thus
subclass it, then things get complex real fast.
Having tried this exercise I've now decided to write my own auth package
all together.

There are any resources (links, books, etc..) where I can have a look?

Thanks (and thanks Ernesto as well for his answer)

Alex

--
Alessandro De Noia