8월 6일 (화) 회고 - dev-FEFIVE/NadoCat GitHub Wiki

각자 자유로운 형식으로 작성해주세요.

문소영

박민혜

회원가입을 prisma로 변경하는 작업을 완료하고, 비밀번호 부분도 bcrypt로 변경한 뒤 로컬 DB에서 값이 들어오나 확인해보았다.
원본 레포지토리에 바로 pr을 하지 않고, fork된 내 레포지토리에 먼저 pr을 날린다음 원본 레포지토리로 날리려다가 뭔가 꼬여서 다시 해결해야할 것 같다.

박소현

RDS로 배포해서 공유하고 있는 DB로 요청 응답 테스트 했었는데, 다른 팀원들은 각자의 로컬 서버 생성 후 prisma migrate 한 내용을 push해서 사용하고 있다는걸 알았다. 테스트 단계에서는 공유 DB 오염을 안 시키는게 좋겠다. 초기화 잘 시켜놓아야겠다.

이화정

외래키 제약 조건에 관련된 에러 해결만 하루 종일 했다. 테이블을 설계할 때 N:M 관계가 된다는 것을 생각하지 못하고 만든 것이 원인이었다. (정신이 없어서 생각을 못 했다..😢) 일단 태그와 이미지 부분은 중간에 테이블을 하나씩 생성해서 문제를 해결하였다. DB 수정은 어렵지 않았지만 기존 코드를 하나씩 확인하면서 수정하는 게 제일 힘들었다. (너무 헷갈렸다..!!) cascade를 사용하지 않기로 결정했기 때문에 데이터 삭제 순서가 매우 중요했다.
Prisma는 createMany와 deleteMany를 사용하면 어떤 데이터에 변경이 있는지 알 수 없었다. { count : 1 } 이런 식으로 변경된 행의 수만 리턴해 준다. 변경된 행의 id 값이 필요했기 때문에 어쩔 수 없이 Promise.all과 create, delete 조합을 이용해 해결했다. Promise.all을 배우긴 했어도 실제 프로젝트에서 사용해 본 적은 없는데 이럴 때 쓸 수 있구나를 배울 수 있어서 나쁘지 않았다. (그런데 해결 방법이 더 있을지도..)
Prisma를 사용하다 보니 데이터가 너무 지저분하게 넘어와서 그 부분도 하나하나 수정해야 했다. 외래키 관련 문제를 해결하면서 테이블이 추가되었는데 태그나 이미지가 객체안에 객체가 또 들어있는 형태로 조회가 되어 map을 이용해 값을 변경해 주는 작업을 해야 했다. (이것도 더 좋은 방법이 있을지도..?)

장세림

동네 고양이 도감 CRUD API쪽에 이슈가 있었다. 예를 들어 create를 할 때 DB 테이블 간 연관성을 고려해 1.게시글을 생성하고 2.연관된 이미지나 태그를 생성 3.1과2를 잇는 중간 테이블 데이터 생성... 의 과정을 거쳐야 했다. 마찬가지로 delete의 경우에는 반대의 순서를 밟아야 했다. 하지만 컨트롤러에 작업한 코드에는 데이터 작업중 하나의 단계라도 잘못되었을 때 모두 생성하지 않거나/삭제하지 않는 안전 장치가 되어있지 않았다. Prisma를 사용중이기 때문에 $transaction api를 사용했다. $transaction는 실행 중에 오류가 발생하면 비동기 함수는 예외를 발생시키고 자동으로 트랜잭션을 롤백한다.
위와 같은 이슈를 고려하지 않고 만든 API들을 다 점검해봐야 했다. Controller 폴더 내 페이지별로 폴더를 생성하기로 했기 때문에 작업을 마무리하고 한 번에 파일을 옮겼다.