# querybuilder

yth1122

nodeJs에서는 mybatis-mapper 모듈을 사용하였지만 NestJS에서는 TypeORM은 둘 다 TypeScript 기반으로 작성되었으며, 이 둘을 함께 사용하면 일관된 언어와 코드 스타일을 유지하기 위한 장점과 개발자 커뮤니티와 잘 작성된 문서를 가지고 있어서 지원 및 문제 해결이 용이하기해 자주 사용하는 것 같아 사용해보기로 했습니다. QueryBuilder 함수 정리 select select([조회할 엔티티 속성 배열]): 조회할 엔티티 속성을 선택합니다. where where(criteria, parameters): WHERE 절을 추가합니다. criteria는 쿼리 조건을 나타내며 parameters는 조건에 전달되는 파라미터입니다. update up

wonjun1995

열심히 개발을 하던 중 연관관계가 아닌 테이블을 join해야 하는 상황이 발생하였다. 처음 마주하는 케이스였다. 하지만 stackOverFlow에는 모든 정보가 다 있다. https://github.com/typeorm/typeorm/issues/951#issuecomment-332787865 위 댓글을 바로 참고해보았다. 연관관계가 아닌 테이블을 Join할 때 leftJoinAndMapOne이라는 함수를 사용해서 Join을 걸어주는 것이었다. 나는 이런식으로 사용했다. A라는 지금 사용중인 Repository에 alias를 주고 A에 B라는 연관관계를 만들기 위해 A.B라는 alias를 넣어준다. 그리고 B라는 엔티티를 넣고 mapping을 시켜주면 leftJoin이 된다. innerJoi

youngh0910

😀 들어가며 배치 테스크에서 보내는 API 중 일부가 점차 지연이 발생되기 시작하였습니다. 해당 이슈는 처음에는 단순한 방편(timeout 시간 증가 등)으로 해결하려고 했으나, 문제가 지속적으로 발생하였고 이를 해결하고자 typeorm 쿼리를 분석해 보았습니다. 이를 통해서 leftJoinAndMapMany 를 사용할 때 주의해야될 점 성능을 향상시키는 방법에 대하여 공유하려고 합니다. 😧 문제사항 기존 Typeorm QueryBuilder Typeorm 에서 조인하고 해당 데이터를 map 형식으로 반환받기 위하여 쿼리빌더의 leftJoinAndMapMany 을 사용하는 경우가 많습니다. 아래의 쿼리빌더가 실제로 문제가 발생했던 경우입니다. 위의 Typeorm 쿼리는 실제로 아래의 2개의 쿼리를 보낸다. 🎖️ Typorm 실제 쿼리 typeorm 의 쿼리빌더로 작성된 실제쿼리는 하

from_numpy

시작하기에 앞서 이전 포스팅에서 Typeorm의 "Find Operator(find, findOne, findAndCount ...)"를 사용하여 Nest에서 Pagination을 어떻게 구현할 수 있는가에 대해 알아보았다. ※ 이전 포스팅 참고 -- [Nest] Pagination with TypeORM 하지만, 위의 글 마지막에서도 언급하였지만 Pagination은 물론이고 데이터베이스로부터 특정 데이터를 조회하는 방법은 "Find Operator" 만이 존재하는 것은 아니다. TypeORM에서 레포지터리를 이용한 데이터 조회 및 가공 작업에는 "Find Operator" 이외에 "QueryBuilder"를 이용한 방법이 있다. <span s

baik9261

상품의 리스트를 보여주는 페이지에서 상품의 특정 정보만 가져오는 기능과 상품명을 통해서 검색 필터링을 하는 기능과 query를 사용하여 pagenation의 기능까지 구현해 보겠다. 필자의 상황은 상품의 이미지와 상품의 정보는 외래 키로 연결되지 않았다는 가정하에 진행한다. 리스트 정보 가져오기 상품의 리스트에서 보여줘야 하는 부분은 6가지이다. >- 상품의 ID 상품의 대표이지미 상품명 상품 제조사명 상품등록 시간 상품 수정

hkja0111

지난 블로그에서 NestJS가 지원하는 Test Framework인 Jest를 활용하여 Mocking 기반의 Unit Test를 작성했습니다. 이번엔 QueryBuilder와 Transaction을 활용하는 경우 Unit Test를 어떻게 작성하는지 살펴보도록 하겠습니다. Repository의 의존성을 Mocking하여 외부환경에 영향을 받지 않는, 독립된 Test 환경을 조성했습니다. 그러나 다양한 기능과 복잡한 로직을 구현하다 보면 Repository외에 QueryBuilder, Connection 등 의존성을 주입받은 다양한 모듈과 라이브러리를 사용하게 됩니다. 이런 객체들의 Mocking을 어떻게 구현하는지 알아보겠습니다. QueryBuilder Unit Test > 지난번 getMfr Service Logic은 단순히 User Repository의 find method만 사용했습니다. 이번엔 getOrderQtyDetail Ser

loakick

지난번에는 TypeORM Repository를 DDD하게 도메인 Aggregate 범위와 일치시키는 법에 살펴보았습니다. 이번에는 TypeORM에서 자주 이용하는 QueryBuilder의 코드량을 줄이는 법에 대해 살펴보도록 하겠습니다. > 🚧 이번 포스트는 코드가 굉장히 많습니다! 여유로운 마음을 가지고 봐주세요. QueryBuilder 재사용성 높이기 서비스를 만들면서 조회가 필요한 쿼리는 모두 TypeORM의 QueryBuilder 패턴을 이용하여 만들고 있습니다. QueryBuilder가 TypeORM의 findOne과 같은 함수보다 더 세밀하게(조인된 테이블 where, order, having, group등) 쿼리를 조정할 수 있기 때문입니다. 하지만