आपको custom user model का उपयोग क्यों और कैसे करना चाहिए?

Question

Accepted Answer

एक **custom user model** Django के default `User` को आपकी application की needs के अनुसार बदलता है — fields जोड़ना, login identifier बदलना (जैसे username के बजाय email), या behavior को customize करना। महत्वपूर्ण, अक्सर दोहराई जाने वाली सलाह: एक custom user model को project की **शुरुआत में ही** set up करें, भले ही आपको अभी changes की आवश्यकता न हो, क्योंकि इसे बाद में बदलना बेहद कष्टदायक होता है।

## क्यों: default User सीमित है और बाद में बदलना कठिन

```text
The default User has fixed fields (username, email, first/last name) and uses
USERNAME as the login field. Real apps often need:
  ✓ Email-based login (no username)
  ✓ Extra fields (phone, avatar, role, preferences) on the user itself
  ✓ Custom authentication behavior
```

## इसे पहले करने का महत्वपूर्ण कारण

```text
⚠️ Changing the user model AFTER migrations exist is VERY hard — the User model is
   referenced by auth, admin, sessions, foreign keys throughout the database.
   Swapping it later requires complex, risky data migrations.
→ ALWAYS define a custom user model at project START (before the first migration),
   even an empty one, so you can extend it freely later. Django's docs strongly
   recommend this for EVERY new project.
```

यह मुख्य व्यावहारिक सबक है: पहले दिन एक custom user model set up करने में लगभग कुछ नहीं लगता, लेकिन इसे एक established project पर retrofit करना एक बड़ा, error-prone कार्य है — इसलिए आप इसे insurance के रूप में पहले ही करते हैं।

## कैसे: AbstractUser को extend करना (आसान तरीका)

```python
# models.py — add fields, keep Django's auth behavior
from django.contrib.auth.models import AbstractUser

class User(AbstractUser):
    phone = models.CharField(max_length=20, blank=True)
    avatar = models.ImageField(upload_to="avatars/", blank=True)
    is_premium = models.BooleanField(default=False)
```

```python
# settings.py — tell Django to use it
AUTH_USER_MODEL = "myapp.User"
```

`AbstractUser` Django के सभी default fields और auth machinery को रखता है — आप बस fields जोड़ते हैं। सबसे सरल, सबसे आम approach।

## कैसे: AbstractBaseUser (पूर्ण नियंत्रण, जैसे email login)

```python
from django.contrib.auth.models import AbstractBaseUser, BaseUserManager, PermissionsMixin

class User(AbstractBaseUser, PermissionsMixin):
    email = models.EmailField(unique=True)
    USERNAME_FIELD = "email"          # log in with EMAIL instead of username
    REQUIRED_FIELDS = []
    objects = CustomUserManager()     # a manager defining create_user/create_superuser
```

`AbstractBaseUser` user model पर पूर्ण नियंत्रण देता है (जैसे email-only login के लिए username को पूरी तरह हटाना) — अधिक काम, लेकिन अधिकतम flexibility।

## user model को सही ढंग से reference करना

```python
from django.conf import settings
from django.contrib.auth import get_user_model

# in models — reference via settings.AUTH_USER_MODEL
author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)

# in code — get the active user model dynamically
User = get_user_model()              # NOT a direct import of the default User
```

हमेशा user model को `settings.AUTH_USER_MODEL` (models में) और `get_user_model()` (code में) के माध्यम से reference करें, कभी default `User` को सीधे import करके नहीं — ताकि आपका code custom model के साथ काम करे।

## यह क्यों महत्वपूर्ण है

एक custom user model का उपयोग करना एक महत्वपूर्ण, अक्सर जोर दिए गए व्यावहारिक सबक के साथ महत्वपूर्ण ज्ञान है जिसे हर Django developer को आत्मसात करना चाहिए: **इसे हर project की शुरुआत में ही set up करें**।

इसका इतना महत्वपूर्ण होने का कारण कठिनाई में गंभीर असमानता है — पहले दिन एक custom user model define करने में (यहां तक कि एक empty `AbstractUser` subclass) लगभग कुछ नहीं लगता और अमूल्य flexibility प्रदान करता है, जबकि project के पास migrations और data होने के *बाद* एक custom user model में switch करना बेहद कष्टदायक और जोखिमपूर्ण है, क्योंकि User model Django में गहराई से reference किया जाता है (authentication, admin, sessions) और आपके पूरे database में foreign keys द्वारा, इसे बदलने के लिए complex, error-prone data migrations की आवश्यकता होती है।

यही कारण है कि Django का अपना documentation हर नए project के लिए एक custom user model की दृढ़ता से सिफारिश करता है, तत्काल आवश्यकता की परवाह किए बिना — यह एक भविष्य के migration दुःस्वप्न के विरुद्ध insurance है।

इस महत्वपूर्ण timing सलाह से परे, custom user models को *कैसे* बनाएं यह समझना — Django के auth behavior को रखते हुए केवल fields जोड़ने के लिए **`AbstractUser`** (आम, आसान मामला), और email-based login जैसे पूर्ण नियंत्रण के लिए **`AbstractBaseUser`** (username को पूरी तरह हटाना) — वास्तविक application requirements (अतिरिक्त user fields, वैकल्पिक login identifiers, custom auth) को पूरा करने के लिए मूल्यवान है।

समान रूप से महत्वपूर्ण है **user model को सही ढंग से reference करना** जानना (`settings.AUTH_USER_MODEL` और `get_user_model()` के माध्यम से, कभी एक direct import नहीं) ताकि code जो भी user model configured हो उसके साथ काम करे।

क्योंकि लगभग हर वास्तविक application की Django के defaults से परे user-specific needs होती हैं (और जिनकी नहीं होती वे भी flexibility से लाभान्वित होती हैं), और क्योंकि इसे जल्दी set up न करने की लागत इतनी अधिक है, custom user models को समझना — विशेष रूप से project की शुरुआत में एक स्थापित करने की अनिवार्यता — महत्वपूर्ण, व्यावहारिक रूप से अनिवार्य ज्ञान है जो एक आम और गंभीर project-level गलती को रोकता है, इसे Django best-practice ज्ञान का एक अक्सर उद्धृत टुकड़ा बनाते हुए।