Kodėl ir kaip turėtumėte naudoti pasirinktinį naudotojo modelį?

Question

Accepted Answer

**Pasirinktinis naudotojo modelis** pakeičia Django numatytąjį `User` modelį, kad atitiktų jūsų programos poreikius — pridedant laukus, keičiant prisijungimo identifikatorių (pvz., el. paštu vietoj naudotojo vardo) arba pritaikant elgesį. Kritinis, dažnai kartojamas patarimas: pasirinktinį naudotojo modelį nustatykite **jei darbo pradžioje**, net jei jums dar nereikia pakeitimų, nes vėliau jį keisti yra itin skausminga.

## Kodėl: numatytasis User modelis yra ribojamas ir sunkiai keičiamas vėliau

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

## Kritinė priežastis tai daryti PIRMA

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

Tai yra pagrindinė praktinė pamoka: beveik nieko nekainuoja pasirinktinį naudotojo modelį nustatyti pirmą dieną, bet jo įvedimas į jau sukurtą projektą yra didelė, klaidoms priežengus mažiau atlaikymo sritis — todėl tai darite iš anksto kaip draudimą.

## Kaip: AbstractUser išplėtimas (lengvasis būdas)

```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` išlaiko visus Django numatytuosius laukus ir autentifikacijos mechanizmą — jūs tiesiog pridedате laukus. Paprasčiausias ir dažniausiai naudojamas metodas.

## Kaip: AbstractBaseUser (pilna kontrolė, pvz. el. pašto prisijungimas)

```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` suteikia pilną kontrolę virš naudotojo modelio (pvz., naudotojo vardo pašalinimas tik el. paštui) — daugiau darbo, tačiau maksimali lankstumo.

## Teisingai naudotojo modeliui nukreipimas

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

Visada naudotojo modeliui nukreipkite per `settings.AUTH_USER_MODEL` (modeliuose) ir `get_user_model()` (kode), niekada neimportuodami numatytojo `User` tiesiogiai — kad jūsų kodas veiktų su pasirinktinu modeliu.

## Kodėl tai svarbu

Pasirinktinio naudotojo modelio naudojimas yra svarbi žinija su kritiniu, dažnai pabrėžiamu praktiniu pamoku, kurią kiekvienas Django kūrėjas turėtų interializuoti: **nustatykite jį kiekvieno projekto pradžioje**.

Priežastis, kodėl tai tokia svarbu, yra smarki sudėtingumo asimetrija — pasirinktinio naudotojo modelio apibrėžimas pirmą dieną (net tuščia `AbstractUser` subklase) beveik nieko nekainuoja ir suteikia neįkainojamą lanksumą, o persijungimas į pasirinktinį naudotojo modelį *po to*, kai projektas jau turi migracijas ir duomenis, yra itin skausminga ir rizikinga, nes naudotojo modelis yra giliai naudojamas Django (autentifikacija, administravimas, sesijos) ir svarbiais raktais per visą jūsų duomenų bazę, reikalaudamas sudėtingų, klaidoms priežengaus duomenų migracijų.

Todėl Django dokumentacija kiekvienam naujam projektui griežtai rekomenduoja pasirinktinį naudotojo modelį, nepriklausomai nuo nedelsios būtinybės — tai draudimas nuo ateities migracijos košmaro.

Be šio kritinio laiko patarimo, supratimas *kaip* kurti pasirinktinių naudotojo modelių — **`AbstractUser`** paprasčiausiai pridedant laukus ir išlaikant Django autentifikacijos elgesį (bendras, lengvas atvejis), ir **`AbstractBaseUser`** pilnai kontrolei, pvz. el. pašto prisijungimui (naudotojo vardo pašalinimas) — yra vertingas tikrų programos reikalavimų atitikimui (papildomi naudotojo laukai, alternatyvūs prisijungimo identifikatoriai, pasirinktinė autentifikacija).

Equaliai svarbu yra žinoti **teisingai naudotojo modeliui nukreipti** (per `settings.AUTH_USER_MODEL` ir `get_user_model()`, niekada tiesioginiu importu) kad kodas veiktų su bet kuriuo pasirinktinu modeliu.

Nes beveik kiekviena tikra programa turi naudotojo specifinių poreikių, viršijančių Django numatytuosius (ir net tos, kurios jų neturi, naudojasi lanksumą), ir nes nenustatymo iš anksto sąnaudos yra tokios aukštos, supratimas apie pasirinktinių naudotojo modelių — ypač imperatyvą nustatyti jį projekto pradžioje — yra svarbi, praktiškai kritinė žinija, kuri užkirsdavo dažną ir rimtą projekto lygio klaidą, todėl tapsanti dažnai minima Django gerųjų praktikos žinija.