특정 string이 포함된 document를 찾고싶은 경우 match command의 변수에 regex라는 옵션을 달아준다 그러면 해당 변수로 검색해서 일치하는 모든 도큐먼트를 셀렉트해온다

자주 쓰이는 간단한 형태의 쿼리지만 정리 - Document에 대한 속성은 기존대로 표기 - Document의 array element에 대한 속성은 dot command로 표기 - 조금 더 명확한 filter를 위해서는 elemMatch를 사용할 수 있다 - Document에 대한 업데이트는 기존대로 표기 - Document의 array element에 대한 업데이트는 $ expression 표기, 단 이 경우 조건을 만족하는 첫번째 원소만 업데이트 한다 - multi 로 업데이트를 하고 싶은 경우, arrayFilter를 동일하게 두고, multi 옵션을 켜준다. 해당 예시에서는 filter와 update 구문에서 조작하는 필드가 다르므로 사용 가능.

정확히는 foreach대신 some메소드를 사용하면 된다. 그리고 조건을 만족하는 Loop에서 true를 리턴해준다 예시의 경우라면 zoneIndex가 wbsIndex와 같은 조건에 대해 Loop가 종료될것이다.

습관적으로 ===을 쓰다가 어이없이 헤맸다.. 결론만 말하면 이렇다 애초에 Mongoose의 objectId는 객체라서 === 로 비교가 불가능하고, 모두 ObjectId 타입으로 바꾸어 equals로 비교해야 한다.

상황 - Join과 유사한 방법으로 처리된 두 개의 컬렉션 데이터가 필요한데, 여러가지 조건이 존재하는 경우 - 예컨데 'A컬렉션의 name이라는 데이터가 포함된 description'이라는 데이터를 가지고 있는 B 컬렉션 데이터가 필요한 경우--- 설명이 장황하니 아래 실제 예시를 보자 위의 데이터는 work라는 도큐먼트이고 얘는 zone이라는 도큐먼트이다 zone도큐먼트의 name이 포함된 work의 name을 찾고싶은 상황이다. 그러나 이는 같은 project에 속해야하므로 projectId도 같은 데이터들만 반환해야 한다. 이렇게 복합적인 Join은 pipeline을 이용해 풀어낼 수 있다. 결과 코드는 다음과 같다. 이전 포스팅처럼 Lookup을 이용하지만, foreign과 local field..

무분별하게 다량의 데이터에 인덱싱을 하는 경우, CUD에 큰 문제가 생길 수 있다. 기본적으로 대부분의 인덱스는, 인덱싱된 데이터를 기준으로 Binary tree 탐색을 수행한다. 이로 인해 필요한 영역에 대해서만 데이터 스캔이 가능하다. 예컨데 다음과 같은 데이터가 있다고 해보자. 해당 데이터 중 '이름'에 인덱싱 처리를 하면 아래와 같은 테이블이 생길것이다. 만약 이름에 '송종국'이라는 데이터를 가지고 있는 Document에 대한 질의를 수행한다면 5번 도큐먼트만 메모리로 끌어올리는 Single block I/O가 일어난다 반면 '토트넘'으로 찾는다면, 여기에는 인덱싱 처리가 되어있지 않으므로 모든 Document를 끌어올려 질의를 수행하는 Multi block I/O가 일어난다 이렇게 적절한 인덱싱..