Implementing multiple user types with Django 1.5

Question

What is the recommended way to implement multiple user types using Django 1.5's new configurable user model functionality?

I would like to have two user types: private users and trade users, each with their own set of required fields.

There are two ways I can think to implement this:

1) Multi-table inheritance

class BaseUser(AbstractBaseUser):
  email = models.EmailField(max_length=254, unique=True)
  # ...


class PrivateUser(BaseUser):
  first_name = models.CharField(max_length=30)
  last_name = models.CharField(max_length=30)
  # ...


class TradeUser(BaseUser):
  company_name = models.CharField(max_length=100)
  # ...

Are there any problems with using multi-table inheritance in conjunction with the configurable user model?

2) Using a single model with a "type" attribute

class User(AbstractBaseUser):
  email = models.EmailField(max_length=254, unique=True)
  user_type = models.CharField(max_length=30, choices={
    'P': 'Private',
    'T': 'Trade',
  })
  first_name = models.CharField(max_length=30, blank=True)
  last_name = models.CharField(max_length=30, blank=True)
  company_name = models.CharField(max_length=100, blank=True)
  # ...

This method would require some conditional validation dependent upon user_type.

Which of these methods best suits my use case? Or perhaps there is a better way of achieving this?

Also, In case number 1, how can I filter my users?

Thanks.

Daddylonglegs

Answer 1

Warning: Django 1.5 is very new and the people are still investigating its new features. So my answer is nothing more than my opinion, based on recent research to answer this question.

Both ways are valid ways to achieve the result, with its advantages and disadvantages.

Let's start with the:

Second option

• Without nested models and not modular. AbstractBaseUser, as the name says, is an abstract model and does not have a specific table
• Has unused fields

• You need to check the user_type for any iteration with the model that uses the extra fields:

  def foo():
      if user.user_type == 'Private':
          # ...
      else:
          # ...
  

The resulting SQL would be approximately as follows:

CREATE TABLE "myapp_user" (
    "id" integer NOT NULL PRIMARY KEY,
    "password" varchar(128) NOT NULL,
    "last_login" datetime NOT NULL,
    "email" varchar(254) NOT NULL UNIQUE,
    "user_type" varchar(30) NOT NULL,
    "first_name" varchar(30) NOT NULL,
    "last_name" varchar(30) NOT NULL,
    "company_name" varchar(100) NOT NULL
);

First option

• Nested models with logical separation of entities
• Very lean
• You must implement BaseUserManager for each child if you want to use create_user-like functions
• You cannot access the subclasses with a simple BaseUser.objects.all()*

The resulting SQL would be approximately as follows:

CREATE TABLE "myapp_baseuser" (
    "id" integer NOT NULL PRIMARY KEY,
    "password" varchar(128) NOT NULL,
    "last_login" datetime NOT NULL,
    "email" varchar(254) NOT NULL UNIQUE
);

CREATE TABLE "myapp_privateuser" (
    "baseuser_ptr_id" integer NOT NULL PRIMARY KEY REFERENCES "myapp_baseuser" ("id"),
    "first_name" varchar(30) NOT NULL,
    "last_name" varchar(30) NOT NULL
);

CREATE TABLE "myapp_tradeuser" (
    "baseuser_ptr_id" integer NOT NULL PRIMARY KEY REFERENCES "myapp_baseuser" ("id"),
    "company_name" varchar(100) NOT NULL
);

* Imagine the following situation:

>>> BaseUser.objects.create_user('[email protected]', password='baseuser')
>>> PrivateUser.objects.create_user('[email protected]', password='privateuser', first_name='His', last_name='Name')
>>> TradeUser.objects.create_user('[email protected]', password='tradeuser', company_name='Tech Inc.')
>>> BaseUser.objects.all()
[<BaseUser: [email protected]>, <BaseUser: [email protected]>, <BaseUser: [email protected]>]
>>> PrivateUser.objects.all()
[<PrivateUser: [email protected]>]
>>> TradeUser.objects.all()
[<TradeUser: [email protected]>]

So, you cannot directly retrieve the subclasses instances by using BaseUser.objects.all(). There is an excellent blog post by Jeff explaining better how to accomplish "automatic downcast" from BaseUser to its childs.

That said, you should consider the advantages and disadvantages of each approach and their impact on your project. When the involved logic is small (as in the example described), both approaches are valid. But in a more complex scenario, an approach can be better than the other one. I would choose the multi model option because it is more extensible.

Unasked

Excellent answer. The automatic down casting is exactly what I was missing. I'm going to go with option 1 and implement this. Many thanks. – Daddylonglegs

django-models-utils can helps with inheritance. See @ThibaultJ answer: https://mcmap.net/q/426807/-coding-an-inventory-system-with-polymorphic-items-and-manageable-item-types , Automatic downcasting of models from querysets – Cuprite

Instead of if user.user_type == 'Private': you could define @property with the name is_private_user and use if user.is_private_user:. With nested models for the same purposes you should use isinstance() to check the type of user, but again, the same functionality could be achieved by implementing @property – Condiment

Answer 2

Maybe you should consider AbstractUser?

Cotenant

Answer 3

The new custom user model you can assign only one model to AUTH_USER_MODEL. With multi-table inheritance you have two models. So that is a problem.

In the case of a single user model that covers both user types you could abstract the conditional logic in the model methods. You can also use different managers for different user types based on how much they are different. This could also help you in being explicit when working with a specific user type.

Other option could be to store only most common attributes in a single user model and then attach specifics of two user types into their own tables which are linked to your main user table.

If both users have most of the things in common (in terms of data at least), I would keep them in one place. In the end, I would think about what is simpler and easier to maintain.

Forty

Thanks for your answer. In my example above, BaseUser contains all of the fields necessary for authentication, so would be assigned to AUTH_USER_MODEL. I am all for keeping things as simple as possible, but am also trying to avoid denormalising the database. – Daddylonglegs

If two user types have only 1 or 2 fields different, I don't see much advantage of normalization. But you are right, you can use BaseUser for AUTH_USER_MODEL. I was not aware of down casting, with that your first case makes more sense. – Forty

Answer 4

I'd use a single model with a "type" attribute. Here is why:

• Only one table, only one model
• If you want to convert from one type to another you just change attribute
• Implement getters and setters for the fields that exists for one type and doesn't exists for other = much more simple to use.

Condiment