어제 그렇게 고민을 계속 하다가 잤는데
너.. 그 SQL 이렇게 짜면 해결된다..... 라고 꿈에서 알려줌.
뭐지?
근데 출근하고 해보니까 정말 됐다? 잘 돌아감(...)
일단 OK. 나중에 생각해보자.
어제의 삽질 이유는 다음과 같았다.
현재 내가 하고 있는 작업은 인젝션의 요소가 있는 rawQuery를 ORM로 변환하는 작업인데
해당 코드를 짰던 분이 기왕 하는 김에 제가 고민을 하다가 해결을 못한 것도 같이 해주셨으면 좋겠다. 라고 하셨다.
당연히 음! 겸사겸사 하면 되겠다! 라고 OK를 했지만? 그게 헬게이트 오픈일 줄은 몰랐지..
덕분에 별걸 다써봤다.
지금까지 나는 기초적인 ORM만 써봤기에 다양한 것을 써보지 못했는데..
- SUM
- AS
- CASE WHEN
- LIKE
- IN
- NOT
- IS NOT NULL
- NOT NULL
- groupBy
이게 api 한개의 로직 속에 들어가있다(....)
와.....이거 하나 고치면서 진짜 책도 계속 보고 검색도 계속하면서 시야가 확 넓어진 느낌이다
아무튼 어떻게 해결을 했는지 설명을 해보자면
- Where 조건에 deteledAt이 IS NOT NULL인 데이터를 일단 다 긁어온다.
- 해당 데이터의 PK를 map으로 사용해서 한개의 배열을 만든다.
- Where 조건에 deteleAt이 NOT NULL과 2번의 PK들을 IN 구문을 통해서 긁어온다.
- 특정 값이 0이여야하는데, 0이 아니라면 CASE WHEN 구문을 사용하여 0으로 바꿔준다.
- 3번의 데이터를 1번의 데이터에 push한다.
- 반환!
고민을 했던 이유는 1번에서 이미 그룹핑을 한 데이터고
1번이 메인 데이터, 4번이 서브 데이터였다.
그래서 두개를 그룹핑하는 것이 제일 좋은 해결책이라고 생각했지만....안된다니 뭐(....)
사실 서브쿼리면 되지 않을까? 라는 생각도 해봤는데, 아직 거기까지 능력은 안되는 것 같더라ㅠㅠ
아무튼 그렇게 해결을 하고 PR을 올려놓고 OK 사인을 받았따 엣헴
싱글스레드는 생각보다 많이 빠르다.
위에꺼는 처리하고, 다른 쿼리를 수정하던 중에 고치고 싶었던 로직이 있었다.
Array.map()을 사용하는 구문이였는데
기존의 테이블에서 뽑은 key가 아닌 새로운 key에 담아주는 것이였다.
그래서 싱글스레드니까, DB에서 다 처리할 수 있는게 좋지 않을까? 라는 생각에
CASE WHEN THEN END로 해당하는 부분을 모조리 수정하고, 반복문을 제거했다.
근데 더 느림, 무려 3배나 느림
.....?
이게 단순한 I/O라면 노드가 진짜 상상하는 것보다 엄청 빠르기 때문에
내가 고민했던 과정에서는 멍청한 짓이였다(....)
뭐 저 작업한다고 150줄에 가까운 코드를 전부 지웠다가 새로 쓰는 재밌는 경험을 했는데 결국 7줄만 적용하고 원복했다
하하 젠장
Typeorm에 대한 많은 고민을 하고 있는 것 같다.
회사에서도 똑같이 이런 고민을 하고 있는데
이 개노답 ORM을 버전업을 할지
아니면 아예 다른 것으로 갈아탈지. 두개의 선택지가 있는데
내가 보기엔....Prisma로 넘어가는게 옳은 선택이 되지 않을까 라는 생각이 계속 드는 것 같다.
0.2 -> 0.3 하위호환 죽여버린 꼬라지보면 지금 0.3.8버전이라
곧 0.4버전 나올텐데 여기서 또 sibal 그러면 화병나서 죽을지도 모르겠다
이참에 기획하고 있는 사이드프로젝트를 prisma로 구현을 해가지고
사람들이 사용감이 좋다는 말을 그렇게 많이하던데, 좋으면 이걸로 바꾸자고
베스트 프렉티스라던가 다양한 사용법을 다 들고와서 건의를 해봐야겠따.
끝!
아, 오늘 추석날이라 조기퇴근했는데 코드가 손에서 안놔져서 그냥 일 더 했다
물론 재택이라 할만햇쒀
즐거운 명절 연휴 보내세요~!
