- 클라이언트로부터 요청을 받으면 URLconf를 이용하여 URL을 분석한다.
- URL 분석 결과를 통해 해당 URL에 대한 처리를 담당할 VIEW를 결정한다.
- VIEW는 자신의 로직을 실행하면서 만일 DB 처리가 필요하면 MODEL을 통해 처리하고 그 결과를 반환받는다.
- VIEW는 자신의 로직 처리가 끝나면 템플릿을 사용하여 클라이언트에 전송할 HTML 파일(TEMPLATE)을 생성한다.
- VIEW는 최종 결과로 HTML 파일(TEMPLATE)을 클라이언트에게 보내 응답한다.
- TEMPLATE을 쓰는 이유는 VIEW에서 MODEL 이용해 DATA를 가져오고 처리하는 프로그램을 동작시켜 처리한 결과를 보여줘야하므로 이 결과를 담아 전달하기 위해 사용한다
- 입력 양식은 form으로 전달되므로 board의 view에 replyform을 추가하여 context에 함께 전달해준다
- 실행 결과
- method를 post를 주기에 본 함수의 get부분은 사용하지 않으므로 댓글이 잘 저장된다
- 게시글과 1:N 관계이므로 reply에 foreign key를 추가한다
- foreign key를 통해 DB에 자동으로 '참조하는 객체 이름'_id로 index가 생성된다
- 현재 관계
- html에서 post.id를 전달
- url 수정
- view 수정
- reply의 post는 Post와 관계를 맺고 있어서 Post의 객체 값만 저장할 수 있기에 객체를 생성해서 저장한다
- 즉 reply.post에 id나 reply_post.id를 넣으면 int type이기에 error가 난다. 이 reply.post는 post 객체만 받으므로 post 객체를 생성해서 post.id를 설정한 후, 이 post 객체를 넣어줘야 한다
- 여기까지 진행하면 어떤 작성자의 어떤 게시물의 댓글인지 확인이 가능하다
- reply_writer는 User objects만을 받는데 어째서 request.user를 넣어도 괜찮을까? request.user를 print하면 lijahong이 나오지만 이것은 문자열이 아닌 User objects안의 출력 method로 인해 나오는 것으로 request.user는 objects가 맞다
select_related : 정방향, model에 관계된 객체가 있을때 조회할려고 할때 사용. sql에서 join으로 가져옴
prefetch_related : 역방향, model에 관계된 객체가 없을때 조회할려고 할때 사용. sql에서 query를 2개 실행하여 가져옴. 객체 가져오는 쿼리 + 객체와 관계된 객체 가져오는 쿼리. 파이썬에서 join 실행
- reply 요소가 post에 reply_set으로 들어간다 ( id, titile,...,reply_set)
- Django에서 지어주는 이름으로 prefetch_related 안에 가져오고 싶은 model + '_set'으로 추가한다
- 실행시 먼저 post에 대한 query가 실행되고, 그 다음 해당 post와 관계된 reply에 대한 query를 수행하여 첫번째 query 결과로 가져온 post들의 id를 두번째 reply query의 where 조건에 사용하여 해당 reply query에 대한 Data를 가져온다
- 모델 가져오는데 대소문자 구분 없이 DB의 앱이름_모델이름의 모델 이름을 보고 찾아온다
- reply_set는 하나의 reply model이다. 따라서 해당 게시물의 모든 reply를 가져오기에 .all을 써야한다