Override a field in child class from the parent class in Django

Viewed 238

I am working on a project in Django Rest Framework. The Project is mostly completed, but suddenly new requirement come from the client.

Their requirement is that the Worker should also be able to Signup as a Customer, and the Customer should also be able to signup as a Worker. They are located in different apps.

The problem is that my database scheme is implemented in a different way and I don't have a seperate table for the worker. Now I'm stuck on what should I do, Here is my database structure:

Class User(AbstractUser):
    username
    email         unique=True
    first_name
    last_name 
        ...
    
Class Worker(User):
    weight
    job_category

Suppose that the Worker email is "dudeworker@gmail.com", and they want to signup as a Customer with the same email (dudeworker@gmail.com); they will get an error, as expected, saying Email is Already exist. Now if I seperate the Worker table, then I have to perform lots of changes in the code.

What is the best solution for this situation? By overriding the email field in Worker table, giving the error.

2 Answers

can you use one of the fields in the worker table to point to the customer table? perhaps append values to it.

what I think of a solution is that

  1. make a profile table, keep the user as foreign-key value, not one-to-one value, add a choice field of user_type in the same model as (customer, worker)

  2. now when user signup as a worker with the same email as a customer or vice-versa then first check email is present in user table or not if yes, then just create a new profile with type worker or customer in opposit case

  3. every time they log in as worker or customer in login response send your type(worker or customer) and also profile id and its details by that way you can segregate your data for customer or worker in other tables where the user is mapped and then you can easily check profile type for user

hope this help

other than another way is to modify user table which is I guess a bad idea as you already designed schema

Related