이전처럼 req.user.id 처럼 간단한 Key를 사용하면, 현재 사용하고 있는 Model들이나 Collection들에 변동이 생겼을 때 Cache Key의 조건을 만족하지 못하면서 문제가 생길 확률이 매우 높다.
따라서 애초에 처음에 Cache Key를 지정할 때, 조금 더 완강한 Key를 두는 것이 일종의 해결 방법이 될 수 있다. 아래의 예시를 살펴보자.
1번 문제를 해결할 때 사용했던 Query를 다시 이용하겠다. 분명 2개의 Query는 서로 엄청나게 다른 Query이고 결과 값도 매우 다르다. 주어진 2가지 Query를 모두 Redis에 저장하려고 한다면, Key는 어떻게 해야할까?
const query1 = Person
.find({ occupation: /host/ })
.where('name.last').equals('Ghost')
.where('age').gt(17).lt(66)
.where('likes').in(['vaporizing', 'talking'])
.limit(10)
.sort('-occupation')
.select('name occupation');
const query2 = Person
.find({ occupation: /host/ });
JavaScript
복사
적절한 해결 방법은 Query에 어떤 Option이 적용 되었는가를 기준으로 Key를 삼으면 된다. Query1은 Query 1에서 적용된 7개의 Option이 Key가 될 것이고, Query2에서는 1개의 Option이 Key가 될 것이다. 2개의 Key는 서로 매우 다르기 때문에 이를 Key로 삼아 Result를 Value에 저장해서 사용하면 된다.
query1.getOptions();
query2.getOptions();
JavaScript
복사
이는 Query의 getOptions함수를 통해서 수행할 수 있다. getOptions함수는 Query에 Chaining된 모든 Option들을 단일 Object로 리턴해준다.
getOptions를 통해 얻은 Object는 getOptions를 수행한 Query에만 해당되는 굉장히 Unique한 String을 만들어 낼 수 있다. (Query에 수행되는 Option이 바뀌면 getOptions를 통한 결과도 달라지게 되고, 이는 곧 Key가 달라지는 것을 의미한다. 상당히 Unique하게 사용할 수 있다.)
따라서 이런 속성을 이용하여 getOptions로 얻은 Object를 Stringify하여 Key로 삼으면 된다. 3번 문제의 Key에 대한 문제는 1번 문제 Exec 함수 내에서 수행하게 된다.