5/19

justyoon·2023년 5월 19일
0
post-custom-banner

create_superuser가 실행될 때
로그인 아이디로 필요한 필드를 email로 지정해 주었다.
그런데 갑자기

유저네임을 아이디에 반영해야 하는 상황이 생겼다

USERNAME_FIELD, REQUIRED_FIELDS

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()과 같다.
/////////////////////////////////////////////////

profile
with gratitude, optimism is sustainable
post-custom-banner

0개의 댓글