어제 오후부터 오늘 새벽5시까지 그리고 출근해서 또 시작된 삽질 그 끝에 나는 이것 하나 확실히 알았다
바로 이 portfolio의 정체
view에서 filtering 한 portfolio는 QuerySet
serializer로 보낸 portfolio는 object라는 것
어쩌면 이 당연한 사실을
삽질 약 12시간 만에 알았고,
깨달은지 수 분 내에 내가 원하는 결과를 얻었다 하
내가 가져와야 했던 데이터와 모델의 성격은
-
일단 model이 one-to-many -> one-to-many 관계인데,
-
pk의 컬럼명이 각기 다르고, 이 pk의 형식이 각기 다르다
-
그리고 이 primary key는 foreign key로 서로 누구도 물려 있지 않은 이 pk이고,
-
심지어 parameter로 받아오는 pk에 따라 분기를 해야 했고,
-
총 3개의 서로 다른 db와 총 4개의 table에서 데이터를 가져와서
-
하나의 json data로 합쳐서 전달해야 했다
일단 table을 join하는 방법은
-
select_related(정참조인 경우)를 사용하는 것인데, fk로 물려있지 않아서 불가능 하고, (fk 없이도 다른 방법이 있는지는 모르겠다)
-
pandas로 merge를 하는 것인데, 모든 data를 가져와서 합쳐야 했기 때문에 불필요한 데이터 요청이 많아 진다는 것(내 지식 수준으로는 그렇다), 하지만 테이블을 붙이는 건 크게 어려워 보이지 않았다
-
django 내에서 정참조로 연결되어 있는 pk의 특정 컬럼의 값을 가져오기 위해 for문을 열심히 돌리는 것인데, 이 또한 문제였던 것이, A, B, C 데이터 그룹을 하나로 합쳐야 하는 상황에서, A와 B 데이터를 이미 serializer로 합쳐서 받아와서, C 데이터를 for 문으로 돌려서 데이터를 얻은 다음에 무슨 수로 합치는지, 무슨 수로 다시 serializer로 보내는지 도대체가 알 수가 없었다.
-
serializer의 이해가 부족했기 때문에, 하나의 serializer에서 한 개 이상의 함수로 구분하여 데이터를 만들어 내고, (없는)컬럼을 추가한 후 view로 보내는 것이 이해가 되지 않았고,
-
하나의 serializer에서는 하나의 동일한 instance를 사용하는 것 같은데, 다른 db의 다른 model에서 가져오는 데이터를 무슨 수로 다른 serializer로 보내나???
이 총체적 난국에서,
이윽고, 정말 이 길이 내게 맞는 길인지 하는 깊은 고민에 빠지고야 말았고,
내가 이거 하나 못 불러 오는데, 이 일을 하는 것이 맞는 것인가 코딩 인생 3개월(흫) 중
가장 극심한 고통에 빠졌을 때 즈음
-
어쨌든 데이터를 죄다 따로 개판으로 줄게 아니라면, 하나의 json으로(딕셔너리로) 합칠 거라면
일단 무조건 하나의 serializer를 타야 하지 않을까?
(response를 합칠 수는 있을 것 같았는데 일단 짱구가 여기서 멈춰있었음) -
그렇다면 같은 model을 활용해야 한다는 어떤 확신 같은 것이 들었고,
orm 최적화고 나발이고 일단 어떻게든 for문을 돌려서 -> serializer로 보내서 새로 추가 할 컬럼의 해당하는 값을 가져와야 하는데,
(중간 삽질로, comprehension을 쓰는데 결과가 자꾸 빈 배열로 나와서 돌아버리,,,,,)
쿼리셋과 object의 개념이 확실치가 않아서인지 무한 attribute 에러 굴레에 빠져있다가
디버깅 삽질과 프린트 찍기를 반복 또 반복
우연히 serializer에 portfolio가 어떻게 전달 되길래!하고 찍었는데
응? 오브젝트,,,,,? 오,,,브,,,젝,,,,,트으,,,,,???
그렇게 새로운 컬럼이 추가 되고, 값이 출력이 되고야 말았다.
ㅘ
사무실에서 소리지를 뻔,,,
지난 위코드 생활이 주마등처럼 지나가면서,
어쩌면 이 순간 나의 문제는 drf고 serializer고의 문제가 아니라
명백하게 queryset, model, instance, object, sql의 문제인 것 같고,
즉, 개강 후 2주차 부터 시작했던
CRUD 1, 2, 3의 이해가 부족했던 것이 아닐까 하는
개랑 오너, 영화배우랑 무비
이거 부터 다시 공부해야 하나 하,,,
&
API를 작성하기 전에,
반드시 기획서, db, table, data 구조를 잘 파악하는 것이 얼마나 중요한지 다시 한 번 느꼈던 2차 sprint!
