create_superuser가 실행될 때
로그인 아이디로 필요한 필드를 email로 지정해 주었다.
그런데 갑자기
유저네임을 아이디에 반영해야 하는 상황이 생겼다
class User(AbstractBaseUser):
# User Email (Required)
email = models.EmailField("email", max_length=256, unique=True)
# User Username
username = models.CharField("username", max_length=20, unique=True)
# User Password (Required)
password = models.CharField("Password", max_length=256)
is_active = models.BooleanField(default=True)
is_admin = models.BooleanField(default=False)
이메일은 추후 가입 인증을 위한 필드로 남겨 두기로 하고
유저 필드에 아이디로 사용되었던 이메일 대신 유저이름으로 변경.
유저이름을 아이디로 사용하려면 중복을 방지하기 위해 unique속성을 부여해야 한다.
USERNAME_FIELD = ['email']
REQUIRED_FIELDS = []
변경 ===>
USERNAME_FIELD = ['username']
# (constant) USERNAME_FIELD: Literal['username']
REQUIRED_FIELDS = ['email',]
# (constant) REQUIRED_FIELDS: list[str]
❗USERNAME_FIELD
, REQUIRED_FIELDS
두곳에 (literal = 문자그대로 )필드명과 다른 이름이 기입되거나 필드 타입이 (str) 문자열이 아닌 경우 관리자 계정 만들 때 value_error를 확인할 수 있다. 본인은 이 필드를 비워놓고 관리자 계정을 계속 만들려고 했는데, 삽질을 피하려면 코드의 형태를 세심히 볼 필요가 있다. 🥲
DRF의 클래스는 부모 클래스를 상속을 받는 경우가 정말 많은데 타고 들어가보면 복잡해보여도 코드의 원래의 형태를 확인할 수 있어서 참고하기 가장 좋은 방법 같다.
BaseUserManager
현재 유저모델에 상속받아 사용중인 모듈이다.
normalize_email
내장된 여러 장고모델들 중에서 Manager
를 상속받는다
해당 클래스는 BaseManager의 QuerySet
을 불러오는 from_querysey
메서드를 상속받는다.
@classmethod
클래스 메서드는 정적 메서드처럼 인스턴스 없이 호출할 수 있다는 점은 같다. 하지만 클래스 메서드의 차이점은 메서드 안에서 클래스의 속성과, 클래스 메서드에 접근해야 할 때 사용할 수 있다.
/////////////////////////////////////////////////가령 cls를 사용하면 메서드 안에서 현재 클래스의 인스턴스를 만들 수도 있다. 즉, cls는 클래스이므로 cls()는 Person()과 같다.
/////////////////////////////////////////////////