[TypeORM] TypeORM 사용기

TypeORM 사용기

1. [TypeORM] Example using TypeORM with Express
2. [TypeORM] Advanced: Query Builder
3. [TypeORM] Advanced: JOIN

참고 자료

• ORM
  • [데이터베이스] ORM이란? (Node.js ORM Lib Sequelize 소개)
  • ORM
  • ORM(Object Relational Mapping)
• TypeORM
  • Data Source
  • Entity
  • Entity Manager
  • Relations
  • Query Builder
  • TypeORM gitbook: 함수 설명이 공식 문서에는 없을 때 참고
  • What are the different use cases for using QueryBuilder vs. Repository in TypeORM? [closed]
  • TypeORM & NestJS
  • TypeORM: What is the difference between getRawMany() and getMany()?
• SQL 관련
  • [DB] DDL, DML, DCL 이란?
  • SQL 기본 문법: JOIN(INNER, OUTER, CROSS, SELF JOIN)

여담

라우터 순서에 따라 달라지는 리다이렉팅

이 에러 때문에 약간 머리가 아팠다. 위에 내가 작성한 app.ts 파일에서 원래 라우터 순서를 “/users”, “/users/:id”, “/users/register”, … 이런 식으로 했었다. 그렇게 하니까 “/users/register”를 경로로 줬는데, 자꾸 “/users/:id”로 빠지면서 id에 NaN이 들어가고, 쿼리를 실행할 때 조건문의 WHERE id = ? 이 부분이 에러가 나는 것이었다. 사실 이런 에러를 예전에도 겪은 적이 있어서 원인을 찾는 데에는 그렇게 어렵진 않았다.

“/users/regiser”는 user라는 리소스에 속한 것이라 경로를 수정하고 싶지 않아서 대신에 라우터 끼리의 순서를 바꿨다. 기존의 순서에서 달라진 점은 조금 더 깊게 들어가는(?) 경로를 보다 위에 작성해줬다. 그래서 지금의 app.ts를 구성했다.

번역

이건 사소한 건데 자꾸 relations를 관계라고 해석해서… 문맥상 보면 이상하다 싶을 때 릴레이션의 다른 뜻을 생각해보니 예전에 데이터베이스 배울 때 테이블을 릴레이션이라고 말하기도 한다는 걸 떠올렸다. 그 밖에도 튜플이라든가 카디널리티라든가. 이래서 기술 문서는 까딱하면 잘못 번역하기 쉽다.

그래서 JOIN은 어떻게 한다고?

여기서 멘탈 나갈 뻔 했다. 솔직히 깡으로 SQL 넣어버리면 세상 쉽기는 한데, 이왕 ORM 쓰기로 한 거, 정말 웬만큼 미친듯이 복잡한 쿼리가 아니면 ORM으로 처리하고 싶었다.

JOIN에 관한 문서를 읽는데, 데이터베이스의 관계 종류에 따른 데코레이터가 나오기 시작하면서 머리가 조금 아팠다. 예전에 학교 다닐 때 잠깐 봤었는데, E-R 다이어그램 그릴 때에도 저거 생각하느라 머리 깨질 거 같았던 기억이 나면서 “설마 이걸 내가 다시 할 날이 있을까” 했고 진짜 이걸 하게 되었다.
구글링 해가면서 대충 기억 되살리고 스택 오버플로우 찾아가면서 만들어보는데, 쿼리문이 이상하게 작성되는 걸 확인했다. o.userId가 자꾸 o.userIdId이런 식으로 쿼리가 생성돠었다. 이게 왜 이렇게 되는 걸까 싶다가, 그 다음날에 머리 식히고 엔티티 파일을 다시 살펴봤다. 그러자 눈에 들어온 게, order.entity와 user.entity 두 곳에 왜 관계 데코레이터가 붙어있는 것이었다.
외래키 참조는 order쪽에서 일방적(?)으로 하는데, 왜 굳이 user.entity에서 Order[]를 받아와야 하는지 의문이었다. 그래서 해당 필드를 지우고 실행해보니 제대로 잘 나왔다.

이때까지만 해도 함수를 innerJoinAndSelect()를 쓰고 있었는데, 이걸 사용하면 내가 어떤 필드를 가져올지를 지정할 수 없다. 즉, SELECT * FROM ...이라는 구문이 생성되는 것이다. 따라서 내가 원하는 필드만, CONCAT()도 사용할 수 있는 방법이 없을까 하다가 찾은 것이 innerJoin().select().addselect()...의 방법이었다.
여기서 걱정했던 점은 SELECT * FROM ... INNER JOIN ...을 하고 난 이후에 한 번 더 그 결과를 가지고 SELECT를 하는 거 아닐까 싶었는데, 생성된 쿼리문을 보니 한 번의 SELECT로 쿼리를 작성하는 걸 확인할 수 있었다. 이런 방식이면 여러 테이블을 join하는 것도 큰 문제가 없을 것 같다.

예시 만들기

예제를 만드는 사람들의 고뇌를 알 것 같았다… 적당한 난이도를 갖추면서 직관적이면서 이해하기 쉬운 예제를 만드는 건 어렵다.