| 작성자 | 성창민 |
| 일 시 | 2024. 11. 19 (화) 18:00 ~ 21:00 |
| 장 소 | 복지관 B-128-1호 |
| 참가자 명단 | 임혜진, 장원준, 이재영, 성창민, 김명원 |
| 사 진 |  |
기존 모델에 유저 모델 연결하기
기존 CLIVING의 모델은 유저를 넣을 것을 하나도 고려하지 않고 만들었었다.
처음 백엔드를 개발하다보니, 막연하게 분리가 될 것이라고 생각했던 것 같다.
아무튼 저번 시간에 유저를 만들었고, 이제는 이전 모델에도 유저별로 정보를 따로 저장해야 했기에, 모델 개선에 들어갔다.
이 모델은 날짜별 페이지 기록을 생성하기 위해 만든 Page모델인데,
아래 사진은 수정한 사진이다.
이전까진 id와, user가 없었다. 그리고 date가 id의 역할을 했다.
처음엔 단순히 user 필드만 넣으면 알아서 날짜별, 유저별 분리가 되어 저장될 줄 알았다.
그러나 date가 id 였고, 유니크한 필드로서 작동했기에, 서로 다른 유저가 Page를 생성해도, 날짜가 같다면 하나의 데이터로서 인식이 되었다. 그래서 처음 만든 데이터가 저장되고, 두번째 만든 데이터는 처음 만든 데이터를 업데이트 하는 작업만 해주었다.
따라서 date는 값을 판별하는 용으로서 남기고, id를 새로 적용하여 구분하기로 했다.
date는 Char필드로, 날짜를 6자리 문자열로 바꾸어서 저장하고 있는 필드인데,
많은 view에서 이 필드를 필터링 할 때 사용하고 있기에 어쩔 수 없이 살려둘 수 밖에 없었다.
추후 유지보수가 필요하다면 date_dateFieldValue라고 적혀있는 필드로 수정해야 할 것 같다.
그리고, 유저와 관련되지 않았지만 작은 문제가 있었는데,
date_dateFieldValue가 auto 필드로서 작동하여, 새로 만든 테스트 데이터 값의 해당 필드의 날짜를 수정할 수가 없었다.
CLIVING을 처음 만들 땐, auto가 너무 편리해서 살리고 싶어서 수정을 딱히 하지 않았는데, 테스트 데이터를 만들기에 너무 불편해서 수정에 들어갔다.
auto 필드를 빼고, 밑에 save를 오버라이딩 하여 date가 입력되지 않는다면, date와 date_dateFieldValue를 오늘의 날짜로 만들게 하였다.
이렇게 하면 admin페이지나, API 를 직접 사용하여 date필드를 채워주었을 때는 해당 날짜로 채워지고, 평소 어플에서는 날짜별로 자동으로 페이지를 생성해주기에 auto의 기능도 사용할 수 있었다.
무엇보다 auto가 데이터 생성될 때 바로 작동하여 값 수정이 너무 불편했는데, 이제 생성 단계에서 수정이 가능해졌기에, test_data를 만들어주는 코드를 미리 짜두고 사용할 수 있었다.
DB를 날리고 새로 만들어도, python manage.py test_data 를 한번 쳐주면 랜덤 데이터 100개를 생성할 수 있다.
아래는 test_data.py의 일부 코드이다.
Faker패키지를 사용하여 만들었다.
이렇게 모델을 수정했고,
View에서도 유저별로 데이터가 다르게 출력되야 하기에 토큰과 필터링을 추가하는 작업을 진행했다.
PageViewSet을 보면, permission_calsses={IsAuthenticated]가 추가되어 토큰 인증을 받아야만 뷰가 작동하도록 했고,
토큰에 포함된 User 정보를 ~filter(user=self.request.user)를 통해 사용하여 자신의 Page 만 필터링하도록 했다.
필요한 API도 추가로 만들어주었다.
지금까진 클라이밍 시간만 계산해주는 API만 존재했지만, 어떤 클라이밍 문제를 도전했는지 색깔을 카운팅해주는 API를 추가하였다.
이번 모델을 수정하면서 '이전에 더 잘 만들었더라면 지금 이렇게 고생하지 않아도 될텐데' 라는 생각이 계속 들었다. 미리 유저를 만들 생각을 하고 모델을 구성했더라면 매우 편리했을 것 같았기 때문이다. 그러나 이러한 과정이 없이 처음부터 모든걸 알고 개발할 수 없다는 걸 알기에 조금 귀찮더라도 지금 당장 할 수 있는것들을 해보며 개발해보기로 마음먹었다.