LikeCount와 같은 테이블의 number 칼럼에 +1 혹은 -1을 할 일이 생기는 경우, +1을 하는 API를 새로 구성하는 것 보다 Like 테이블에 row가 추가될 때마다 SubScriber에서 트랜잭션을 열고, +1을 추가하는 것이 프론트의 api 호출 빈도를 줄일 수 있다는 점에서 장점이 있다고 생각하였다. +1의 경우, TypeORM afterInsert( )를 사용하여 insertEvent가 해당 테이블에서 발생시 number +=1을 하는 방식으로 작성하여, 정상적으로 likeCount 칼럼의 값에 +1이 되는 것을 확인하였는데, -1의 경우, 테이블에서 해당 정보가 삭제되더라도 removeEvent가 row가 삭제된 것을 체크하지않아 -=1이 되지않는 문제가 발생하였다. 원인 Dele..
좋아요 API를 구현하고, 테스트 하던 중 아래와 같이 Column "likecount" does not exist 에러가 발생하였다. 그런데 해당 칼럼은 스토리 테이블에 존재하는 칼럼이다. 아래와 같이 TypeORM의 EntitySubscriberInterface를 implement해서 LikeSubScriber를 구현하였는데 afterInsert와 InsertEvent를 통해 Like 테이블에 새로운 row가 추가될 때마다 Story 테이블의 해당 스토리 likeCount 칼럼에 +=1을 하는 방식으로 해당 이슈를 참고하여 구현하였다. How can I incr/decr a value? · Issue #680 · typeorm/typeorm How can I increase a value by one..
CreateQueryBuilder를 사용하여 API를 구성하다가 .leftJoin으로 현재 QueryBuilder가 위치한 Entity외에 다른 JOIN Table에서 정보를 가져와서 필터링을 해야하는 경우가 생겼다. 해당 API 실행 계획은 다음과 같았다. 카테고리 스토리 JOIN 테이블에서 스토리 ID로 카테고리 리스트를 찾은 다음, 카테고리 리스트의 ID로 카테고리 스토리 JOIN 테이블를 조회하여 현재 스토리를 제외한 나머지 스토리 리스트를 전달한다. 위의 실행 계획을 createQueryBuilder에 해당 JOIN테이블을 leftJoin하는 방식으로 구현하였는데 .limit(n)을 추가하면, 쿼리가 고장나서 예상과 다른 쿼리를 2번을 날리고 스토리가 2개만 들어있는 Array가 2번 리턴되는 ..
어드민이 유저의 등급을 일반 유저에서 Prime 혹은 특별 유저로 변경 시, 해당 유저에게 알림이 가야되는 로직을 TypeORM의 SubScriber를 통해 구현하였다. afterUpdate를 사용하여 유저 테이블에 변경이 생기면 이를 감지하여 알림 테이블에 지정된 알림 데이터를 저장하는 방식으로 하였는데 유저가 유저 정보를 수정해도 해당 afterUpdate가 작동하는 문제가 발생하였다. 이 문제를 해결하기 위해서는 유저 테이블의 변경이 생기기 이전의 정보와 변경 이후의 정보의 특정 칼럼을 활용하여 예외처리를 해야하는데 TypeORM의 공식 Subscriber 문서를 찾아보면 따로 존재하는 것 같지 않았는데 TypeORM 깃헙 이슈에서 event.databaseEntity를 통해 변경이전의 정보를 가져..
개발/TypeORM 2021. 12. 26. 17:14
LikeCount와 같은 테이블의 number 칼럼에 +1 혹은 -1을 할 일이 생기는 경우, +1을 하는 API를 새로 구성하는 것 보다 Like 테이블에 row가 추가될 때마다 SubScriber에서 트랜잭션을 열고, +1을 추가하는 것이 프론트의 api 호출 빈도를 줄일 수 있다는 점에서 장점이 있다고 생각하였다. +1의 경우, TypeORM afterInsert( )를 사용하여 insertEvent가 해당 테이블에서 발생시 number +=1을 하는 방식으로 작성하여, 정상적으로 likeCount 칼럼의 값에 +1이 되는 것을 확인하였는데, -1의 경우, 테이블에서 해당 정보가 삭제되더라도 removeEvent가 row가 삭제된 것을 체크하지않아 -=1이 되지않는 문제가 발생하였다. 원인 Dele..
개발/TypeORM 2021. 12. 19. 00:25
좋아요 API를 구현하고, 테스트 하던 중 아래와 같이 Column "likecount" does not exist 에러가 발생하였다. 그런데 해당 칼럼은 스토리 테이블에 존재하는 칼럼이다. 아래와 같이 TypeORM의 EntitySubscriberInterface를 implement해서 LikeSubScriber를 구현하였는데 afterInsert와 InsertEvent를 통해 Like 테이블에 새로운 row가 추가될 때마다 Story 테이블의 해당 스토리 likeCount 칼럼에 +=1을 하는 방식으로 해당 이슈를 참고하여 구현하였다. How can I incr/decr a value? · Issue #680 · typeorm/typeorm How can I increase a value by one..
개발/TypeORM 2021. 12. 11. 22:00
CreateQueryBuilder를 사용하여 API를 구성하다가 .leftJoin으로 현재 QueryBuilder가 위치한 Entity외에 다른 JOIN Table에서 정보를 가져와서 필터링을 해야하는 경우가 생겼다. 해당 API 실행 계획은 다음과 같았다. 카테고리 스토리 JOIN 테이블에서 스토리 ID로 카테고리 리스트를 찾은 다음, 카테고리 리스트의 ID로 카테고리 스토리 JOIN 테이블를 조회하여 현재 스토리를 제외한 나머지 스토리 리스트를 전달한다. 위의 실행 계획을 createQueryBuilder에 해당 JOIN테이블을 leftJoin하는 방식으로 구현하였는데 .limit(n)을 추가하면, 쿼리가 고장나서 예상과 다른 쿼리를 2번을 날리고 스토리가 2개만 들어있는 Array가 2번 리턴되는 ..
개발/TypeORM 2021. 12. 1. 11:45
어드민이 유저의 등급을 일반 유저에서 Prime 혹은 특별 유저로 변경 시, 해당 유저에게 알림이 가야되는 로직을 TypeORM의 SubScriber를 통해 구현하였다. afterUpdate를 사용하여 유저 테이블에 변경이 생기면 이를 감지하여 알림 테이블에 지정된 알림 데이터를 저장하는 방식으로 하였는데 유저가 유저 정보를 수정해도 해당 afterUpdate가 작동하는 문제가 발생하였다. 이 문제를 해결하기 위해서는 유저 테이블의 변경이 생기기 이전의 정보와 변경 이후의 정보의 특정 칼럼을 활용하여 예외처리를 해야하는데 TypeORM의 공식 Subscriber 문서를 찾아보면 따로 존재하는 것 같지 않았는데 TypeORM 깃헙 이슈에서 event.databaseEntity를 통해 변경이전의 정보를 가져..