TIL Project - 3

부제 : models.py와 aquery의 끝..??

프로젝트 3일차 어제 마무리 작업을 해놓은 models.py를 보고 오늘은 merge를 받고 View작업으로 넘어가는 듯해보였다... 하지만 수정의 수정의 수정을 거치게 되었고 하루종일 aquery와, models.py의 수정이 이루어 지게 되었다.

수정의 서막!

models.py의 수정은 어렵지 않았다. migration도 무난히 잘 되었고, migrate역시 무난하게 잘 되었을 뿐만 아니라 db마저 잘 생성되고 테이블 역시 잘 있었다. 하지만 branch를 설정해서 git에 push를 하면서 시작되었다.

Full Request 중

git에 push하기

다들 생각에는 완성한 models.py 역시 main에 올리는게 맞다는 생각에 push를 main을 했다. 하지만 feature/models라는 branch를 만들어서 해야했다. 첫 수정이 이루어졌다.

ManyToMany 오류

wecode시작부터 괴롭힌 ManyToMany관련 오류였다. ManyToManyField관계를 설정해 줄때 'through'와 through_field라는 속성이 있다. through는 중간테이블을 수동으로 연결 해 줄때 사용하는 속성값이고, through_field는 오직 사용자가 정의 중간모델을 해줄때만 사용한다.
-> 이 부분에서 헷갈렸던것 같다. through_field는 through를 설정해준 테이블에 추가 필드값을 설정해주면 설정해주는 속성이라고 생각했었다.

이 부분을 수정을 해줌으로서 ManyToMany오류가 해결이 되었다.

부족한 Table과, Field

view의 작성

FullRequest를 한 뒤 멘토님의 merge를 기다리고 있으면서 시간이 남아 백엔드의 기능을 나누고 있었다. 구현해야할 큰 그림은 로그인/회원가입, 구매단계, main/Product로 분류하게 되었고 main/product의 View의 코딩을 하게 되었다.

View의 작성을 위해 이것저것 처음부터 따져보니 누락된 부분이 엄청 많았다... category도 OneToMany가 아니라 ManyToMany관계였고, 단순히 구현하고자 했던 tap이동 관련해서도 해결을 해야 했다.

스토리 부분의 url을 보면 wadiz.ke/web/campaign/capture/97989로 설정이 되어있다.

반환 정책 url을 보면 wabiz.kr/web/campaign/fundinginfo/97989로 url이 변경된것을 알 수 있다. 즉 다시 말해서 스토리와 반환정책 사이의 View가 다르다는 것을 알 수 있다.

-> 그래서 해결을 위해 subcatgory로서 그냥 데이터에 그냥 넣을려고 했던 스토리, 반환/정책, 새소식, 커뮤니티를 Referencetable로 설정 해서 product 테이블에 참조하는 방식으로 했다. 탭전환이 일어나게 되면 각 카테고리에 맞는 id값이 호출이 되고 호출이되면 각 탭에 맞는 목데이터를 불러오는 방식으로 구현하기로 했다.

단순계산 vs 테이블 구현 과연 어느것이 더 좋은가...

같이 Products의 View를 구현하는 지윤님과 이야기 하던 도중, 단순계산을 하는 부분에 있어 테이블을 만드는 편이 좋을까, 로직으로 단순히 구현하면 좋을까?라는 토의가 있었다.

와디즈를 보면 실시간랭킹과, 펀딩 현재상황을 보여주는 공간이 있다.
현재 펀딩이 몇 퍼센트 달성이 되었는지, 모인 총 펀딩금액이 어떻게 되는지, 펀딩을 한 서포터는 어떻게 되는지를 보여주는 공간이다. 그리고 이 기준으로 실시간 랭킹을 작성을 하려고 했다. 여기서 의문점이 든 것이 었다. Reword별 판매 금액도 알고, 목표 달성 금액, 몇명이 사갔는 지 알게 되면 굳이 테이블을 하지않아도 파이썬에서 단순계산으로 데이터를 보내주면 테이블을 만드는 것보다 더욱 효율적이지 않을까? 하는 의문이었다.

지금이야 데이터가 얼마되지않아서 테이블을 만들어서 하면 어떻게든 구현할 수 있다. 하지만 서포터의 인원수가 100명 1000명이 되면 서포터가 오를때마다 테이블에 쌓이는 데이터의 양이 늘어나게 될 뿐더러 비효율적일 것이라고 생각했다.

하지만 멘토님의 의견은 테이블을 만드는 것이 좋다! 라는 의견을 주셨다.
'트랜잭션'이라는 것이 있다. 데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 또는 한꺼번에 모두 수행되어야 할 일련의 연산들을 의미한다. 만약 테이블을 만들지 않고 계산을 하는 방식으로 하게되면 여러 테이블에 있는 칼럼을 거쳐야 되어야 한다. 그렇게되면 트랜잭션이 이루어지는 순간에 오류가 날 수 있다고 하셨다. 테이블을 만들어 두게 되면 그 테이블만 불러오게 되므로 오류가 날 확률이 적어지게 될 것이다.

그리고 추가적으로 굳이 파이썬에서 로직을 짜지 않아도, mysql에서 임시 칼럼을 만들어서 자동으로 계산을 시킬 수가 있는데 파이썬보다 더욱 빠르다고 하셨다. 생각보다 파이썬이 무거운 언어라면서...

이러한 결과 단순히 계산을 통해 데이터값을 보낼려고 했지만, 테이블을 모두 다 만들고 수정했다.

---

오늘 발생한 일들중 생각하기에 큰 것들만 블로깅을 해보았다. 물론 이것보다 더 많은 중공업과 사소한 오류들이 있었지만 한 달전과는 다르게 해결할 수 있는 능력이 생겼다. 프로젝트 기간동안 화이팅!!

그래서 완성한 aquery