custom user model का वापर का आणि कसा करावा?

Question

Accepted Answer

एक **custom user model** Django च्या डिफॉल्ट `User` ला बदलून आपल्या अ‍ॅप्लिकेशनच्या गरजा पूर्ण करते — फील्ड जोडून, लॉगिन identifier बदलून (उदा. username ऐवजी email), किंवा वर्तन कस्टमाइজ करून. महत्वाचा, वारंवार दिला जाणारा सल्ला: custom user model प्रोजेक्टच्या **सुरुवातीच** सेट अप करा, जरी तुम्हाला अजून बदल हवेत नसले तरी, कारण नंतर हे बदलणे अत्यंत कठीण आहे.

## डिफॉल्ट 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 सेट अप करणे लक्षणीय खर्च नाही, पण स्थापित प्रोजेक्टवर एक जोडणे हा मोठा, त्रुटी-प्रवण काम आहे — म्हणून तुम्ही हे वीमे म्हणून आधीच करता.

## कसे: AbstractUser विस्तारित करणे (सोपा मार्ग)

```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 च्या सर्व डिफॉल्ट फील्ड आणि auth यंत्रणा राखते — तुम्ही फक्त फील्ड जोडता. सर्वात सोपा, सर्वात सामान्य दृष्टिकोन.

## 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-फक्त login साठी username पूर्णपणे काढून टाकणे) — अधिक काम, पण अधिकतम लचक.

## user model योग्यरित्या संदर्भित करणे

```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 मध्ये) द्वारे संदर्भित करा, कधीही डिफॉल्ट `User` थेट import करून नाही — जेणेकरून आपला code custom model सह काम करेल.

## हे महत्वाचे का आहे

Custom user model वापरणे हे महत्वाचे ज्ञान आहे एक महत्वाचे, वारंवार जोर दिलेले व्यावहारिक धड सह जे प्रत्येक Django विकासकाने आंतर्भूत करावे: **प्रत्येक प्रोजेक्टच्या सुरुवातीच हे सेट अप करा**.

हे इतके महत्वाचे का आहे याचे कारण कठीणतेमध्ये गंभीर असमरूपता आहे — पहिल्या दिवसी custom user model परिभाषित करणे (अगदी एक रिक्त `AbstractUser` subclass) लक्षणीय खर्च नाही आणि अमूल्य लचक प्रदान करते, तर प्रोजेक्ट migrations आणि data असल्यानंतर custom user model मध्ये स्विच करणे अत्यंत कठीण आणि जोखमीचे आहे, कारण User model Django (authentication, admin, sessions) मध्ये गहनरित्या संदर्भित आहे आणि संपूर्ण डेटाबेसमध्ये foreign keys द्वारे, बदलणे साठी जटिल, त्रुटी-प्रवण data migrations आवश्यक आहेत.

हीच कारण आहे की Django च्या स्वतःच्या documentation सर्व नवीन प्रोजेक्ट साठी कठोरपणे custom user model शिफारस करते, तात्कालिक गरजा कितीही असली तरी — हे भविष्य migration nightmare विरुद्ध वीमे आहे.

या महत्वाचे timing सल्ल्याच्या पलीकडे, custom user models कसे तयार करावे हे समजणे — **`AbstractUser`** Django च्या auth वर्तन राखून फील्ड जोडण्याचा सोपा, सामान्य प्रकरण, आणि **`AbstractBaseUser`** email-आधारित login सारख्या पूर्ण नियंत्रणासाठी (username पूर्णपणे काढून टाकणे) — वास्तविक अ‍ॅप्लिकेशन आवश्यकता पूर्ण करण्यासाठी मूल्यवान आहे (अतिरिक्त user फील्ड, वैकल्पिक login identifiers, custom auth).

समान महत्वाचे म्हणजे user model योग्यरित्या संदर्भित करायचे हे जाणणे (`settings.AUTH_USER_MODEL` आणि `get_user_model()` द्वारे, कधीही थेट import नाही) जेणेकरून कोड कोणतेही user model कॉन्फिगर केलेले असले तरी काम करेल.

कारण जवळजवळ प्रत्येक वास्तविक अ‍ॅप्लिकेशनमध्ये Django च्या डिफॉल्ट्सच्या पलीकडे user-विशिष्ट गरजा आहेत (आणि ज्यांना नाहीत त्यांनाही लचकतेचा लाभ आहे), आणि कारण हे सुरुवातीच सेट अप न करण्याचा खर्च इतका मोठा आहे, custom user models समजणे — विशेषत: प्रोजेक्ट सुरुवातीच एक स्थापन करण्याची अनिवार्यता — महत्वाचे, व्यावहारिक-गंभीर ज्ञान आहे जे सामान्य आणि गंभीर प्रोजेक्ट-स्तरीय चूक रोखते, हे Django best-practice शेताचे वारंवार-उद्धृत ज्ञान बनवते.