알아두면 좋을 것들

dev_front와 dev_backend를 main에다 merge 하면서 전체적으로 코드를 검토하게 되었다. 그동안 기능 만들기에 집중하여 애매하게 넘어갔던 부분이나 잘 몰랐던 부분을 검토하면서 정리하려고 한다. 

 

1. @Property

    @property
    def cards_of_course(self):
        cards = [ n.card for n in self.course_card_relationship.all()]
        return cards

Page에서 특정 필드 값을 Template에 다양한 방법으로 표현하고 싶을 때, 사용하는 방법이다. get_context로도 보낼 수 있지만 @property가 모듈화 되어 있어서 사용하기에는 더 좋아보인다.

context와 property를 사용하는 가장 큰 차이점!context는 request를 사용하고 싶을 때, property는 request가 필요 없을 때! property 메소드 함수에 request를 쓰면 오류가 난다. 

(Template에서는 메소드 명으로 가져와야한다.)

 

https://www.youtube.com/watch?v=5OyFch8_4fk

https://dojang.io/mod/page/view.php?id=2476 

@property에 대한 설명은 위에 잘 나와있다. 이해한대로 정리를 하자면 class에서 값을 가져오는 getter와 값을 설정해주는 setter가 있는데 @property는 getter, @함수명.setter는 setter를 뜻한다. 클래스의 변수명은 직접 변수명으로 접근해도 되지만 getter와 setter를 통해서 접근하면 원하는 조건을 입력해줄 수 있다. 

 

예를들어 어떤 경우에는 나이가 10살보다 적은 사람에만 적용되는 기능을 만들고 싶을 때, getter, setter 메소드를 통해서 기능을 적용할 수가 있다는 뜻이다. setter에서 조건에 맞게 기능을 추가해주고 getter로 가져오면 된다. 

 

(@property를 안적어도 기능 수행에는 문제가 없는 것을 확인할 수 있다. 하지만 getter 메소드이고 나중에 setter 메소드를 사용할 수도 있으므로 @property를 적어주자.)

 

2. git 명령어

git branch --delete 브랜치 이름 : git branch 삭제

git push origin --delete 브랜치 이름 : 원격 저장소 git branch 삭제

git merge 브랜치 명 : git merge

git pull origin 브랜치 명 : 특정 branch pull

 

 

3. Migrations 오류

models을 만들고 테스트하는 과정에서 기존 모델의 데이터를 그대로 남긴채로 모델을 수정을 하고 새로 데이터를 입력하거나 수정하려고 하면 오류가 발생한다. 

 

 

해결방법은 app의 migrations 파일의 있는 파일들을 삭제해주고 계속 문제가 발생되면 원인을 찾아서 수정해주면 되지만 정 안되면 깔끔하게 데이터베이스를 날려버리는게 속편하다. 

 

 

3. Templates에서의 self, page차이 (Wagtail)

templates에서 {{ self.title }}와 {{ page.title }}은 기술적으로 같다. 두개 중 선택해서 사용하면 된다. 

 

 

4. Templates와 Static 파일 관리 (Wagtail)

특별히 정해진 형식은 없지만 보통 기본 프로젝트 폴더에서 통합적으로 관리한다. 

 

 

5. Settings에서 base.py dev.py production.py 차이점 (Wagtail)

Wagtail의 Settings에 보면 base.py, dev.py, production.py를 볼 수 있다. 이들의 차이점은 

 

1)base.py

This file is for global settings that will be used in both development and production. Aim to keep most of your configuration in this file.

 

2)dev.py

This file is for settings that will only be used by developers. For example: DEBUG = True

 

3)production.py

This file is for settings that will only run on a production server. For example: DEBUG = False

 

4)local.py

This file is used for settings local to a particular machine. This file should never be tracked by a version control system.

 

1) base.py 는 공통적으로 사용하는 것을 정의 해 놓는다.

2) dev.py에는 로컬 단계. 즉 개발할 때 사용하는 것을 정의 해 놓는다.

3) production.py는 배포 서버를 위해 사용하는 것을 정의한다.

4) local.py 특정 기기에서 사용할 것을 정의한다. 

 

 

6. __str__(self)의 용도 (Wagtail)

 

  def __str__(self):

        return self.full_name

의 설정은 다른 곳에서 model을 불러왔을 때, 보여지는 변수이다. 즉 위에 코드에서는 객체를 호출했을 때 full_name이 나타난다.

 

 

7. DEFAULT_AUTO_FIELD

https://docs.djangoproject.com/en/3.2/releases/3.2/#customizing-type-of-auto-created-primary-keys

Django 3.2 release notes | Django documentation | Django

AutoField는 Django ORM에서 자동적으로 생성되는 Auto increment Primary key를 말한다. 기본값이 AutoField로 int 크기를 갖게 되는데 거의 매번 bigint 사이즈 사용을 위해 Model을 정의할 때 bigint로 정의 하기 모델마다 별도 선언을 해주었었다.

 

출처: https://www.morenice.kr/263 [morenice's blog]

 

Wagtail에서 apps.py를 확인해보면 BigAutoField로 되어 있다. Django 3.2 버전 이상부터 만들어진 프로젝트들은 주로 BigAutoField를 사용한다. 그래서 기존에 AutoField로 되어 있는 Field을 BigAutoField로 바꿔서 문제를 피하는 것이 바람직할 것이다. 

 

settings/base.py

DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'

 

 

8. Wagtail Snippets

Wagtail에서 Snippets은 언제 사용할까? 보통 재사용하는 Models을 만들 때 사용한다고 한다. 주로 Django Model이 Snippet에 저장된다. 

 

 

9. __str__(self):

Wagtail에서 Model을 작성할 때, __str__(self)을 정의해준다. 어떤 용도일까? 답은 orm을 사용해서 Model을 불러왔을 때, 표시되는 이름이다. 정의하지 않고 객체를 출력한다면 SampleModel(1), SampleModel(2), SampleModel(3) 이런 식으로 숫자로 구별되어서 전달이 될 것이다. 그래서 __str__(self)의 return 값을 모델의 필드로 한다면 필드 이름으로 보여질 것이다. 

def __str__(self):
	return self.name

 위와 같은 방법으로 사용하면 된다. 

 

 

10. 다른 Port로 서버를 실행하고 싶다면?

python manage.py runserver 포트번호

python manage.py runserver 8001

위와 같이 실행시키면 8001포트로 서버가 열린다. 

그렇게 되면 접속할 주소는 http://127.0.0.1:8001 이 된다.