#12월 둘째주
일
API 1차 구현하고 간단히 배포하고 프론트분에게 전달하기로 했다.
중간에 2틀정도 기존 서비스 코드를 손봐야해서 일정이 늦어질듯하다.

공부
알고리즘 스터디 매주 수요일 이번주부터 시작한다. 매주 8문제씩 풀고 같이 설명 및 토론하는 방식.

7일_ 일일일일일일일일

#TODO 특별한건 없고 API 구현의 연속이다. 다음주까지 구현, 보완, 구현, 보완만 할 예정이다.

Joi library - enum value

parameter validation으로 Joi 라이브러리를 이용하고 있다. 이용법이 너무 쉬워서 쓰면서도 글로 쓸게 딱히 없다. 적을만한게 하나 나왔다.
parameter로 들어오는 값을 몇가지만 딱 받으려고할 때는 어떻게 해야하나. enum 값일 때는 어떻게 해야하는지 schema 정의하기 !

.valid()를 쓰면 된다.

const schema = Joi.object().keys({
  type: Joi.string().valid('value1', 'value2'),
});

or

const SomeEnumType = { TypeA: 'A', TypeB: 'B' };

const schema = Joi.object().keys({
  type: Joi.string().valid(...Object.values(SomeEnumType)),
});

const myObj = { type: 'none' };
const result = Joi.validate(myObj, schema);

하루 마무리

나도 몰래 기획이 늘어나있다. 마땅히 있어야할 기능이니 나는 따르리오. 할일은 태산이오.

8~13일_

#TODO 어제 잠깐의 번아웃으로 멈췄던 API 구현을 다시 시작한다. 뼈대는 오늘 다 완성할 듯하다. 다 하면 바로 긴급 TODO체크해둔 것부터 진행할 예정이다.

API 뼈대 80프로 완성_ 이젠 시간만 충분히 부으면 된다.

흐 빼먹은 것들이 얼마나일지는 모르지만 전반적인 뼈대는 완성했다. 그러나 내일부터 자세히 들여다보면 빼먹은 곳이 엄청 많을 것으로 예상된다.
그래도 전반적으로 코드가 어느방향으로 가야할지는 정해져있어서 코드를 짤때 고민은 크지 않을 것이다. 고민한 것들은 이제 다 해결했으니 시간싸움이다.

mongoose.find() 메서드는 document를 반환한다. js 객체를 전달해주지 않는다.

#문제
.find()로 받은 객체가 수정이 안된다.

#해결
자바스크립트 object를 return하는줄 알았는데 아니었다. 계속 내용이 추가가 안되서 삽질을 한시간은 한 것같다. 헷갈리게된 원인은

const DocumentA = await ModelA.find();

DocumentA.a = 'aaa';
console.log(DocumentA.a) // 'aaa'
//  이렇게 'aaa'가 출력된다. 
// 이것때문에 "document 수정이 가능하구나~" 하고 계속 다른 방법들을 찾아봤던 것이다.

ctx.response.body = {
  DocumentA;
// 그런데 정작 통째로 전달하면 documantA.a 가 사라져버린다.

더 찾아보니 mongoose.find() 메서드는 순수 자바스크립트 객체를 전달해주는 것이 아니라 몽고DB document를 전달해준다. document이기 때문에 수정이 불가능하다.

"수정을 가능하게 하려면 find().lean() 처럼 lean()을 붙여야 한다." lean을 쓰면 객체로 변환해서 전달해준다.

subdocument update

#문제

const UserSchema = new mongoose.Schema({
    // Signup Datas
    subDocument: [Subdoc],
});

위와 같이 생긴 모델에서 특정 subDocument를 수정할때 subDoc의 _id가 수정할때마다 계속 바뀌어버린다. _id 가 유니크하지 않게 된다.

#해결1

Subdocument _id's are not type ObjectIds, they're standard type String. Mongo automatically generates a dynamic string id for these subdocs everytime they're created or modified. You should think about migrating your sub-documents (Addresses) to their its own Model if you want static _id's that do not change upon an update. Then use a Model Reference with the ObjectId type, on the User schema definition. Then when calling User.update(), populate the subdocument content, from its model Reference name Address and filter by _id to modify the target Address doc

간단히 해석하면, "SubDocument 의 _id는 객체ID가 아니다. String 값을 뿐. mongoDB는 subdocs가 생성, 수정될 때마다 _id가 매번 바꿔버린다. _id가 바뀌길 원치 않는다면 subDoc에서 독립적인 model로 바꾸는 걸 생각하길 추천한다."

#해결2
subDocs으로 유지하길 원하고 _id가 바뀌길 원치 않는다면, 수정할때마다 subdoc에 저장되어 있는 _id 도 같이 전달해주면 같은 _id를 유지할 수 있다.

한주 마무리_

흐.. 일이 너~무 많다~ 너~~무. 둘이 할 예정이던 걸 혼자하니 주말이고 저녁이고 없이 진행중..
그래도 개인 공부를 놓을수는 없어서 매일 한문제씩 코테문제를 풀 예정이다. 스터디도 만들었다.