aggregate에서 자주 사용되지만 꽤 복잡한 쿼리 중 하나라 정리해본다. 사실상 filter와 유사한 operator라고 생각하면 된다. aggregate는 각각의 stage가 존재하는데, filter가 project stage에서 사용되는 커맨드라면 redact는 또 하나의 stage이다. stackoverflow를 찾아보면 filter가 근소하게 성능이 좋다고는 한다 실제로 최신 Mongodb버전에 등장한 filter를 사용하는것이 선호되는것으로 보인다. 나 역시 실제 적용하는 상황에서는 filter를 사용할듯 하다. 무튼 redact는 복잡하게 nested한 document에 대해서 개발자가 원하는 조건에 맞는 결과만 리턴하게 만든다. 해당 설명은 공식문서의 예시를 사용해보겠다. 다음과 같은 n..

session을 공유하는 방법이 쿼리마다 조금씩 달라서 잠깐 정리 일단 하나의 세션을 여러개의 api에서 공유하기 위해서는 함수화가 필요하다. 예시의 경우에는 이전 포스팅에서 짜둔 useTransaction함수를 사용한다. 트랜젝션은 항상 세션을 시작시킨후, 그 세션에 해당하는 트랜젝션을 시작해주어야 한다. 또한 예시처럼 부모 리졸버와 자식 리졸버가 동일한 트랜잭션을 공유하길 원한다면 컨텍스트를 이용하여 세션을 넘겨준다. 따라서 다음과 같은 절차를 거쳐야한다 1) startSession을 통해 새로운 session객체 생성 2) ctx.session을 통해 1에서 생성한 세션을 정의 3) session객체에서 startTransaction으로 트랜잭션 실행 4) api 로직 수행 5) 트랜잭션 commi..

가장 많이 쓰이는 형태의 aggregate 구문이다. 배열의 element중 조건에 맞는 document를 찾아서, 해당하는 element만 가져오는 것이다. 이는 document단위로 가져오는 mongoose 쿼리로는 해결하지 못하고, aggregate를 이용하는것이 편하다. 이때 주의할부분은 element 조건에 대해선 elemMatch operator를 사용한다는 점.

콜렉션 A(CBS) { _id: ObjectId('아이디') itemList: [ { _id: ObjectId('아이디'), itemId:ObjectId('아이디'), quantity: 0} ....] }.... 콜렉션 B(Zone) { _id: ObjectId('아이디') itemList: [ { _id: ObjectId('아이디'), itemId:ObjectId('아이디'), quantity: number }.... ] }.... 약간 까다로운 lookup상황을 맞이했다. 위와 같은 두개의 콜렉션이 존재할때, A 컬렉션의 모든 itemList의 itemId를 조회하고 그것과 일치하는 itemId를 가진 콜렉션B의 itemList들을 조회한다. 콜렉션 A의 itemId는 unique하지만, 콜렉션B의 ..

pull operatore를 사용한다. 이때 Document는 itemList:[{object}.... ] 의 형태로 구성되어있다. 따라서 내부 key를 이용해 조건을 찾으면, 해당 조건을 포함하고 있는 element가 빠진다. 이때 multi 옵션을 설정해주어야, 일치하는 모든 element를 제거할 수 있다. 종종 pullAll과 헷갈리는데, pullAll은 Document를 multi로 수정하는 것이 아니고, 조건에 해당하는 값만 빼내는 것이다. 예시의 경우 itemId만 pull된다.

1분이다. 따라서 하나의 session객체에 포함된 트랜젝션들의 총 처리시간은 1분이 넘어가면 안된다. 멍청하게 aggregate를 포함한 많은 쿼리에 session을 공유하다가 계속 timeout 에러가 발생했다. 이러한 이슈에 대비하기 위해, 단순히 find해오는 쿼리에는 같은 session을 공유해주지 않는 것이 좋겠다. 물론 update한 데이터를 다시 find해와서 가공하는 경우는 적절하게 session을 분배해야 한다.