რატომ და როგორ უნდა გამოიყენოთ მომხმარებლის ფორმალიზებული მოდელი?

Question

Accepted Answer

მომხმარებლის **ფორმალიზებული მოდელი** ჩაანაცვლებს Django-ს ნაგულისხმევ `User`-ს თქვენი აპლიკაციის საჭიროებების შესაბამისად — ველების დამატება, ავტორიზაციის იდენტიფიკატორის შეცვლა (მაგ. ელფოსტა მომხმარებლის სახელის ნაცვლად), ან ქცევის ფორმალიზება. კრიტიკული, ხშირად გამეორებული რჩევა: დააყენეთ ფორმალიზებული მომხმარებლის მოდელი **პროექტის ძალიან დასაწყისში**, თუნდაც ჯერ ცვლილებები არ გჭირდეთ, რადგან მისი შემდგომი ცვლილება ძალიან რთულია.

## რატომ: ნაგულისხმევი 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.
```

ეს არის ძირითადი პრაქტიკული გაკვეთილი: ფორმალიზებული მომხმარებლის მოდელის დაყენება პირველ დღეს თითქმის არაფერი ღირს, მაგრამ მისი შექმნა დამყარებულ პროექტზე დიდი, ხარვეზებით ღრმა საქმეა — ამიტომ ამას წინასწარ აკეთებთ დაზღვევად.

## როგორ: 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-ს ყველა ნაგულისხმევ ველს და ავტორიზაციის მექანიზმს — თქვენ უბრალოდ ველებს დამატებთ. უმარტივესი, ყველაზე გავრცელებული მიდგომა.

## როგორ: AbstractBaseUser (სრული კონტროლი, მაგ. ელფოსტა ავტორიზაცია)

```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` იძლევა სრულ კონტროლს მომხმარებლის მოდელზე (მაგ. მომხმარებლის სახელის სრული ამოღება მხოლოდ ელფოსტის ავტორიზაციისთვის) — მეტი სამუშაო, მაგრამ მაქსიმალური მოქნილობა.

## მომხმარებლის მოდელზე სწორი მითითება

```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
```

ყოველთვის მიუთითეთ მომხმარებლის მოდელზე `settings.AUTH_USER_MODEL`-ის საშუალებით (მოდელებში) და `get_user_model()`-ის საშუალებით (კოდში), არასოდეს ნაგულისხმევი `User`-ის პირდაპირი იმპორტით — ასე რომ თქვენი კოდი მუშაობს ფორმალიზებულ მოდელთან.

## რატომ მნიშვნელოვანია ეს

ფორმალიზებული მომხმარებლის მოდელის გამოყენება მნიშვნელოვანი ცოდნაა კრიტიკული, ხშირად მოწოდებული პრაქტიკული გაკვეთილით, რომელიც ყველა Django დეველოპერმა უნდა გააზროს: **დააყენეთ იგი პროექტის დასაწყისში**.

ეს ამ დროს ისე მნიშვნელოვანი რატომ არის დიფიკულტის სიმეტრიის გამო — ფორმალიზებული მომხმარებლის მოდელის განსაზღვრა პირველ დღეს (თუნდაც ცარიელი `AbstractUser` ქვეკლასი) თითქმის არაფერი ღირს და უფასო მოქნილობას იძლევა, ხოლო ფორმალიზებულ მომხმარებლის მოდელზე გადასვლა *პროექტის მიგრაციებისა* და მონაცემების შემდგომ ძალიან ტკივილიანი და რისკიანი, რადგან User მოდელი ღრმად გამოიყენება Django-ს მთელ რეპერტუარში (ავტორიზაცია, ადმინიტრატორი, სესიები) და უცხო გასაღებებით თქვენი მთელი მონაცემთა ბაზაში, რომელიც მოითხოვს რთულ, ხარვეზებით სავსე მონაცემთა მიგრაციებს.

ამიტომ Django-ს საკუთარი დოკუმენტაცია ხაზს უსვამს ფორმალიზებული მომხმარებლის მოდელს ყველა ახალი პროექტისთვის, დაუყოვნებელი საჭიროების მიუხედავად — ეს დაზღვევაა მომავალი მიგრაციის ღამის წინააღმდეგ.

ამ კრიტიკული დროის რჩევის გარკვევით, ფორმალიზებული მომხმარებლის მოდელების შექმნის გაგება — **`AbstractUser`** ველების უბრალოდ დამატებისთვის Django-ს ავტორიზაციის ქცევის შენარჩუნებით (გავრცელებული, ადვილი შემთხვევა) და **`AbstractBaseUser`** სრული კონტროლისთვის, როგორც ელფოსტა-ბაზირებული ავტორიზაცია (მომხმარებლის სახელის სრული ამოღება) — ღირებულია რეალური აპლიკაციის მოთხოვნების დასაკმაყოფილებლად (დამატებითი მომხმარებლის ველები, ალტერნატიული ავტორიზაციის იდენტიფიკატორები, მომხმარებლის ავტორიზაცია).

უთანაბრად მნიშვნელოვანია იცოდეთ მომხმარებლის მოდელზე **სწორი მითითება** (`settings.AUTH_USER_MODEL` და `get_user_model()`-ის საშუალებით, არასოდეს პირდაპირი იმპორტი) ისე, რომ კოდი მუშაობს მითითებული მომხმარებლის მოდელთან დამოუკიდებლად.

რადგან თითქმის ყველა რეალურ აპლიკაციას აქვს მომხმარებელთან დაკავშირებული საჭიროებები Django-ს ნაგულისხმევებთან ზემოთ (და მათაც, რომლებიც ასე არ არის, სჯობს სარგებელი მოქნილობიდან), და რადგან ამის დიდ დროს დაუთავსებელი ღირდება ისე მაღალი, ფორმალიზებული მომხმარებლის მოდელების გაგება — განსაკუთრებით პროექტის დასაწყისში მისი დამყარების აუცილებლობა — მნიშვნელოვანი, პრაქტიკულად კრიტიკული ცოდნაა, რომელიც თავს აკეთებს საერთო და სერიოზული პროექტის დონის შეცდომა, რაც აქვს ხშირად-ციტირებული Django საუკეთესო პრაქტიკის ცოდნის ბაზაში.