ทำไมและคุณควรใช้ custom user model อย่างไร?

Question

Accepted Answer

**custom user model** แทนที่ `User` เริ่มต้นของ Django เพื่อให้เหมาะกับความต้องการของแอปพลิเคชัน — เพิ่มฟิลด์, เปลี่ยนตัวระบุการ login (เช่นใช้อีเมลแทน username) หรือปรับแต่งพฤติกรรม คำแนะนำที่สำคัญและพูดถึงบ่อย: ตั้งค่า 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 ในวันแรก แต่การ retrofit มันเข้ากับโปรเจกต์ที่ตั้งตัวแล้วเป็นงานใหญ่ที่มีโอกาสผิดพลาดสูง — ดังนั้นคุณจึงทำมันตั้งแต่ต้นเป็นการประกัน

## วิธีทำ: ขยาย 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` เก็บฟิลด์เริ่มต้นและกลไก auth ทั้งหมดของ Django — คุณเพียงเพิ่มฟิลด์ เป็นวิธีที่ง่ายที่สุดและพบบ่อยที่สุด

## วิธีทำ: AbstractBaseUser (ควบคุมเต็มที่ เช่น 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 เต็มที่ (เช่นการลบ username ออกทั้งหมดเพื่อ login ด้วยอีเมลอย่างเดียว) — งานมากกว่า แต่ยืดหยุ่นสูงสุด

## การอ้างอิง 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` (ใน model) และ `get_user_model()` (ในโค้ด) เสมอ ไม่ใช่การ import `User` เริ่มต้นโดยตรง — เพื่อให้โค้ดของคุณทำงานกับ custom model ได้

## ทำไมจึงสำคัญ

การใช้ custom user model เป็นความรู้สำคัญที่มีบทเรียนเชิงปฏิบัติที่สำคัญและถูกเน้นย้ำบ่อย ซึ่งนักพัฒนา Django ทุกคนควรซึมซับ: **ตั้งค่ามันตั้งแต่เริ่มต้นของทุกโปรเจกต์**

เหตุผลที่สิ่งนี้สำคัญมากคือความไม่สมมาตรอย่างรุนแรงในความยาก — การนิยาม custom user model ในวันแรก (แม้แต่ subclass ของ `AbstractUser` ที่ว่างเปล่า) แทบไม่มีต้นทุนและให้ความยืดหยุ่นที่ประเมินค่าไม่ได้ ในขณะที่การเปลี่ยนไปใช้ custom user model *หลังจาก* โปรเจกต์มี migration และข้อมูลแล้วยากและเสี่ยงมาก เพราะ User model ถูกอ้างอิงอย่างลึกซึ้งทั่ว Django (การ authenticate, admin, session) และโดย foreign key ทั่วทั้งฐานข้อมูลของคุณ ต้องการ data migration ที่ซับซ้อนและมีโอกาสผิดพลาดสูงเพื่อเปลี่ยน

นี่คือเหตุผลที่เอกสารของ Django เองแนะนำอย่างหนักแน่นให้ใช้ custom user model สำหรับทุกโปรเจกต์ใหม่ ไม่ว่าจะต้องการในทันทีหรือไม่ — มันเป็นการประกันต่อฝันร้ายของการ migration ในอนาคต

นอกเหนือจากคำแนะนำเรื่องจังหวะเวลาที่สำคัญนี้ การเข้าใจ *วิธี* สร้าง custom user model — **`AbstractUser`** สำหรับการเพิ่มฟิลด์ง่าย ๆ ในขณะที่เก็บพฤติกรรม auth ของ Django (กรณีที่ง่ายและพบบ่อย) และ **`AbstractBaseUser`** สำหรับการควบคุมเต็มที่อย่างการ login ด้วยอีเมล (ลบ username ออกทั้งหมด) — มีค่าต่อการตอบสนองความต้องการของแอปพลิเคชันจริง (ฟิลด์ user เพิ่มเติม, ตัวระบุการ login ทางเลือก, auth แบบกำหนดเอง)

สิ่งที่สำคัญพอ ๆ กันคือการรู้ที่จะ **อ้างอิง user model อย่างถูกต้อง** (ผ่าน `settings.AUTH_USER_MODEL` และ `get_user_model()` ไม่ใช่การ import โดยตรง) เพื่อให้โค้ดทำงานกับ user model ใด ๆ ที่ตั้งค่าไว้

เนื่องจากแอปพลิเคชันจริงแทบทุกตัวมีความต้องการเฉพาะเกี่ยวกับ user ที่เกินกว่าค่าเริ่มต้นของ Django (และแม้แต่ตัวที่ไม่มีก็ได้ประโยชน์จากความยืดหยุ่น) และเพราะต้นทุนของการไม่ตั้งค่านี้ตั้งแต่เนิ่น ๆ สูงมาก การเข้าใจ custom user model — โดยเฉพาะความจำเป็นที่จะตั้งค่ามันตั้งแต่เริ่มต้นโปรเจกต์ — เป็นความรู้สำคัญและจำเป็นเชิงปฏิบัติที่ป้องกันความผิดพลาดในระดับโปรเจกต์ที่พบบ่อยและร้ายแรง ทำให้มันเป็นภูมิปัญญา Django best-practice ที่ถูกอ้างถึงบ่อย