1번째 줄: |
1번째 줄: |
| [[분류:장고 기능구현(초급)]] | | [[분류:장고 기능구현(초급)]] |
| ==개요== | | ==개요== |
− | 기본적으로 제공되는 유저모델은 제한적이다. 학교에서 운영한다면 학번 등의 정보를 저정해야 하는데, 이처럼 제공하지 않는 기능들을 확장하는 과정이 필요하다.
| |
| | | |
− | 장고에서 기본적으로 제공해주는 항목을 넘어 개별항목을 지정하는 등의 작업을 하기 위해 처음부터 커스텀유저를 사용하길 권장한다.
| + | === 시작에 앞서... === |
| + | # 프로젝트의 시작 전에 구현해야 한다. |
| + | #:- 기존에 가입된 회원들이 있는 상태에서 새로운 DB 테이블을 정의할 때, migrate 따위의 명령을 실행하면 <code>django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency 앱이름.0001_initial on database 'default'.</code> 같은 에러가 뜬다. 가장 간단한 해결법은 기존 DB를 삭제하고 다시 처음부터 설계를 반영하는 것이다. 때문에 이런 불상사를 막으려면 프로젝트를 제대로 시작하기 전에 최소한의 앱과 커스텀 유저는 구현해 두어야 한다. |
| + | #:- 만약 프로젝트의 중간에 추가해 넣어야 한다면 다음의 문서를 참고하자. [https://code.djangoproject.com/ticket/25313 링크.] 개빡센 여정이 예상된다. |
| | | |
− | 일반적으로 본격적인 프로젝트를 시작하기 전에 만들기가 권장된다. 프로젝트 도중에 모델을 바꾸는 것은 DB의 왜래키나 다대다 관계에 영향을 미치는데, 이를 다시 고치는 일은 꽤 어려운 일이기 때문이다.(중간에 커스텀모델을 추가하는 경우엔 DB자체를 지우고, 다시 구성한다.) 장고의 의존성 특성 때문에 최초의 DB에 생성되어 포함되어야 한다. | + | * 기본적으로 제공되는 유저모델은 제한적이다. 학교에서 운영한다면 학번 등의 정보를 저정해야 하는데, 이처럼 제공하지 않는 기능들을 확장하는 과정이 필요하다. |
| + | * 장고에서 기본적으로 제공해주는 항목을 넘어 개별항목을 지정하는 등의 작업을 하기 위해 처음부터 커스텀유저를 사용하길 권장한다. |
| + | * 일반적으로 본격적인 프로젝트를 시작하기 전에 만들기가 권장된다. 프로젝트 도중에 모델을 바꾸는 것은 DB의 왜래키나 다대다 관계에 영향을 미치는데, 이를 다시 고치는 일은 꽤 어려운 일이기 때문이다.(중간에 커스텀모델을 추가하는 경우엔 DB자체를 지우고, 다시 구성한다.) 장고의 의존성 특성 때문에 최초의 DB에 생성되어 포함되어야 한다. |
| {| class="wikitable" | | {| class="wikitable" |
| |+유저 기능을 확장하는 방법<ref>https://simpleisbetterthancomplex.com/tutorial/2016/07/22/how-to-extend-django-user-model.html</ref> | | |+유저 기능을 확장하는 방법<ref>https://simpleisbetterthancomplex.com/tutorial/2016/07/22/how-to-extend-django-user-model.html</ref> |
32번째 줄: |
36번째 줄: |
| ===사용하는 것은 AbstractBaseUser=== | | ===사용하는 것은 AbstractBaseUser=== |
| AbstractUser는 크게 변경하거나 확장하는 내용이 많지 않다.(그냥 Profile 방식을 사용해도 되지 않을까 싶을 정도로..) 하여, 여기에선 조금 어렵지만, 더 자유로운 BaseUser에 대해 다뤄보고자 한다. | | AbstractUser는 크게 변경하거나 확장하는 내용이 많지 않다.(그냥 Profile 방식을 사용해도 되지 않을까 싶을 정도로..) 하여, 여기에선 조금 어렵지만, 더 자유로운 BaseUser에 대해 다뤄보고자 한다. |
− |
| |
− | === 시작에 앞서... ===
| |
− |
| |
− | # 프로젝트의 시작 전에 구현해야 한다.
| |
− | #:- 기존에 가입된 회원들이 있는 상태에서 새로운 DB 테이블을 정의하는 것으로, migrate 따위의 명령을 실행하면 <code>django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency 앱이름.0001_initial on database 'default'.</code> 같은 에러가 뜬다. 가장 간단한 해결법은 기존 DB를 삭제하고 다시 처음부터 설계를 반영하는 것이다. 때문에 이런 불상사를 막으려면 프로젝트를 제대로 시작하기 전에 최소한의 앱과 유저는 구현해 두어야 한다.
| |
− | #:- 만약 프로젝트의 중간에 추가해 넣어야 한다면 다음의 문서를 참고하자. [https://code.djangoproject.com/ticket/25313 링크.] 개빡센 여정이 예상된다.
| |
| | | |
| ==사전작업== | | ==사전작업== |
− | 어떤 앱의 어떤 모델을 기본 유저로 사용할지 생각하고 진행한다. | + | 어떤 앱의 어떤 모델을 기본 유저로 사용할지 생각하고 진행한다.(그냥 앱을 새로 파는 게 적절하다.) |
| ==모델 작성== | | ==모델 작성== |
− | 필수적으로 2개의 모델을 작성해주어야 한다. BaseUserManager를 상속받은 모델과 AbstractBaseUser를 상속받은 모델.
| |
| | | |
− | 사람마다 짜는 방식이 달라서, 그리고 일일이 주석을 달아두지 않기 때문에 처음 하는 사람들은 해석하는 데 적잖이 애먹는다. | + | * 필수적으로 2개의 모델을 작성해주어야 한다. BaseUserManager를 상속받은 모델과 AbstractBaseUser를 상속받은 모델. |
| + | * 사람마다 짜는 방식이 달라서, 그리고 일일이 주석을 달아두지 않기 때문에 처음 하는 사람들은 해석하는 데 적잖이 애먹는다. |
| + | * 아래에선 계정 식별자를 identifier로 설정했는데, 장고에서 기본적으로 사용하는 username 필드를 사용하는 편이 좋다. |
| | | |
− | 아래에선 계정 식별자를 identifier로 설정했는데, 장고에서 기본적으로 사용하는 username 필드를 사용하는 편이 좋다.
| |
| {| class="wikitable" | | {| class="wikitable" |
| !과정 | | !과정 |