room model, 다대다 일대다 관계

먼저 room app을 config.settings에 추가해주자.

 

우리는 room이 모델이 만들어진 시간, 업데이트 시간 등이 필요하다. 따라서 아래와 같이 만들어 줄 수 있다.

근데 저 필드가 단순히 Room에서만 사용될 것이 아니라, review, reservation 등 여러 곳에서 사용될 필드인데 그 때마다 계속 created, updated를 만들어준다면 불필요한 반복이 될 것이다. 따라서 이걸 클래스로 만들어주어 재사용성을 높이려고 한다.

 

django-admin startapp core

core라는 앱을 만들고 config.settings에 추가해주자. 

그리고 아래와 같은 클래스를 만들어주자.

 

이 클래스를 다른클래스가 상속 받는다면 기본적으로 저 created가 들어있으니 따로 만들어 줄 필요가 없을 것이다.

근데 여기서 저 TimeStampedModel은 데이터베이스로 들어갈 것이다. 근데 우리는 저걸 data로 사용할 것이아니고, TimestampedModel을 상속하는 Model을 data로 사용할 것이다. 빨간 네모 박스의 내용을 적어주면 저 모델은 데이터베이스로 가지 않는 기능을 수행해준다. UserModel에서도 상속한 AbstractUser또한 저 내용이 들어가 있다. 

이처럼 우리가 단순히 기능을 추가해주고 싶을 때는 abstract를 True주면 된다.

 

에어비앤비는 방이 어떤 나라에 있는지 적어줄 필요가 있다. 근데 나라의 수가 워낙 많은데 이를 일일이 choices로 해줘야 하나 싶은데 이를 위해 django-countries가 있다.

pipenv install django-countries

그리고 다른 필드들도 추가해주자.

여기서 import하는 순서는

첫번째로 파이썬코드ex) import os와 같은 것이 첫번 째로오고

두번째는 django코드

세번째는 외부 모듈

네번째는 프로젝트안의 app들 이 순서로 하는게 가장 오류가 안난다.

auto_now_add는 처음 생성할 때만 시간이 업데이트되고

auto_now는 수정 될 때마다 시간이 업데이트 된다. 따라서 이렇게 저장해주자. 

makemigrations와 migrate를 해주고 admin 패널로 가면 다음과 같이 잘 country가 나오는 걸 볼 수있다.

그리고 host에는 foreignkey를 적어주었는데 이를 통해서 host와 user모델이 연결된 것을 확인할 수 있다.

 이렇게 해도 User 모델은 변하지 않는다.

foreignkey는 한 모델을 다른 모델과 연결시켜주는 역할을 한다. 연결이 시작되는 곳은 room이다.

user는 이 연결에 대한 정보가 전혀 없다. 

 

User는 하나다. 한 User는 여러 room을 가질 수 있다. 이 관계를 일대다 관계라고 한다.

예를들어서 user가 여러 post를 쓸 수 있다. 하지만 post는 오직 한 user만 가질 수 있다.

room model에foreign key를 적는다. 저기에는 id가 들어가고 그 id는 user테이블의 id라는 걸 알 수 있다.

 

수동으로 넣어줄 수도 있고 장고가 그 id를 가지고 있는 User를 찾을 것이다. 장고는 그냥 아무 숫자가 아니라 user id라는 것을 알고 있기 때문이다.

 

 

먼저 아래와 같이 두개의 룸을 생성하면 이름이 저렇게 나온다. Room object

이걸 고치기 위해서 Room Model을 좀 수정해줄 필요가 있다. 아래를 추가하고 다시 새로고침을 해보자

잘 바뀐 걸 볼 수 있다. 

 

 

 

 

우리는 room type이라는 걸 만들어 보려고한다. 이 방의 종류가 hotel room인지, share house 형태인지, private room 형태인지 카테고리를 만들어 주는 것이다. AbstarctItem을 만들어주어서 전에 만든 것 처럼 데이터베이스에는 저장이 안되는 형태로 만들어 주었고 필드는 name필드를 주었다. Roomtype에서 이걸 상속하고,

 

room 모델에 아래 한줄을 추가해 주었다.

admin에도 다음과 같이 추가해주어 roomtype을 볼 수 있도록 해주었다.

4개의 타입을 만들어 준 뒤

room model에서 가져올 수 있도록 하였다.

이게 manytomany이다 

오직 하나만 필요한 경우 foreign key를 사용하지만 여러개가 필요한 경우 ManyToMany를 사용한다.

 

우리가 전에 foreign key를 사용할 때 on_delete 옵션을 준 적이 있다.

 host key로 우리의 room 모델과 user이 연결되어있다고 했다. on_delete옵션은 만약 우리의 User(host에 넣은)가 삭제 된다면 어떻게 할 지 주는 옵션이다.

 

내가 host를 지운다면 아래와같은 화면이 출력이 된다. 이 User와 연결된 Room도 삭제가 된다고 나온다.

우리가 준 옵션 때문이다. models.CASCADE는 room과 연결된 user가 삭제될 때 그 room도 같이 삭제되는 옵션이다.

cascade는 폭포를 말한다. 제일 위에서 어떤일이 발생하고 그일이 아래에 모든 영향을 주는 것 처럼말이다.

on_delete=models.PROTECT옵션도 있는데 이건 Room을 소유하고 있는 User를 지우고 싶다면 전에 업로드한 Room을 지우기 전까지는 자신의 User를 지울 수 없다는 뜻이다.

 

on_delete=models.SET_NULL은 User을 삭제하면 room은 남아있고 host에 null이 온다 따라서 User와 연결되어있지 않은 상태로 된다.

 

on_delete=models.SET_DEFAULT는 만약 누군가 room을 삭제하지않고 계정을 지우면 그 room들은 관리자에게 넘어가게 된다.

 

보통 User을 지우면 작성했던 글들은 필요가 없어지기에 CASCADE를 주는 것이 깔끔하다. on_delete는 오직 foreign key를 위한 것이다. 왜냐면 foreign key는 한가지에만 연결이 되기때문이다. 이건 many to many에는 해당되지 않는다. 그래서 한가지에 대응되는 여러개가 없기 때문이다.

 

우리가 RoomType처럼 만들어주면 admin panel에서 사용자가 직접 이름을 추가할 수 있고,

만약 CharField에서 choices옵션을 준다면 프로그래머가 작성해둔 이름만 고를 수 있는 차이가 있다.

 

여기서 amenity facility, house rule또한 추가해주자.

생각해보니 room_type엔 하나의 값만 들어가야 될 것 같다. 따라서 foreign_key로 바꿔주었고 만약 room type이 삭제된다고해도 문제될 것이 없으므로 on_delete = SET_NULL 옵션과 null=True를 주었고, 아래 어메니티 퍼실리티 하우스룰 같은 경우에는 many to many로 주었다.

 

admin 페이지에도 다음과 같이 추가하여 register해주었다.

admin으로 가보면 자동으로 장고가 아래와 같이 모델뒤에 s를 붙여준 것을 확인할 수 있다.

하지만 여기서 amenities라고 나와야 자연스러울 것이다. 이걸 고쳐주기 위해서 Meta데이터를 수정해줄 필요가 있다.

 

verbose_name은 admin에서 보일 이름이고,

verbose_name_plural은 자동으로 s가 붙지만 그걸 우리가 적은 대로 바꿔주는 것이다.

Photo모델을 만들어서 foreign key에 Room을 넣어주었다.

Room 위에 Photo 모델을 만들면 ForeignKey에서 Room모델을 넣는 경우 읽을 수 없다고 한다. 이를 방지하기 위해서

model을 불러올때 " " <안에 넣어서 불러오면 import오류를 방지할 수 있다.

admin에도 추가해주었다.