기존에 faker.js를 사용해서 Seeding용 API 엔드포인트를 구성하였었는데 해당 Faker 모듈이 관리가 안되는 이슈도 있고, request한 유저의 권한을 valid하긴 하지만, 데이터 베이스에 직접적으로 영향을 줄 수 있는 엔드포인트가 외부로 노출되어있는 점이 불안해서 typeorm seeding을 통해 ssh로 직접 서버에 접속해서 커맨드를 날리는 방향으로 변경하였다. Faker.js를 통한 Seed API 작성 백엔드를 개발하다보면 REST API의 GET 메소드에서 DB에서 데이터를 제대로 불러오는지 확인해야하는데 이럴 때 Seed API를 통해 테스트 용도의 fake DB를 구성하는 것이 매번 데이터를 직접 입력해넣 eight20.tistory.com NestJS와 관련된 Seedin..
DB를 기존에 사용하던 PostgreSQL에서 MySQL로 변경하고 나서 동일한 Entity의 String 타입으로 지정된 칼럼의 문자열 길이가 공백 포함 255자 이상은 저장되지 않는 이슈가 생겼다. 기존 Entity는 Id, 생성 일시, 마지막 업데이트 일시, 제목, 설명, 썸네일, 링크로 구성되어 있는데 이슈가 발생한 부분은 description 부분이었다. TypeORM의 경우, string 타입으로 칼럼 타입을 지정하면 각 DB의 기본 문자열 저장 타입으로 변환하는데 따로 Character Type을 지정하지 않으면 PostgreSQL은 varchar, MySQL은 varchar(255)이다. // content.entity.ts @Entity() export class Content { @Pr..
프로젝트를 진행할 때 TypeORM + PostgreSQL를 사용하여 개발하였는데 TypeORM + MS SQL을 사용해야하는 일이 생겼다. 기존에 PostgreSQL에서 테이블에서 랜덤으로 row를 뽑아 올 때는 PostgreSQL에서 random()으로 랜덤 함수를 지원해서 TypeORM createQueryBuilder에서 .getMany()나 .getOne() 앞에 .orderBy('random()')을 추가해서 ORDERBY random() 쿼리를 데이터베이스로 날렸었다. 아쉽게도 MS SQL에는 random과 같은 랜덤 함수를 지원하지 않았다. 대신 uuid와 같이 unique한 난수를 생성하는 함수인 newId()를 지원해서 해당 함수를 활용해서 랜덤 함수처럼 사용하여 랜덤 row를 가져올 ..
QueryBuilder를 사용하여 JOIN 쿼리가 포함된 쿼리문을 작성하다보면 주로 .leftJoinAndSelect 메소드를 사용한다. .leftJoinAndSelect를 사용하면 하나하나 칼럼을 체크할 필요가 없고, 코드 가시성적인 면에서는 장점이 있었지만, 모든 칼럼을 Select해오다보니 성능적인 면에서 필요한 칼럼만을 가져오는 쿼리에 비해 상대적으로 메모리 사용량이 많은 문제점 또한 존재한다. 작성하던 코드 중 JOIN을 3개의 테이블에 걸쳐 쿼리를 날려야되는 API가 있었는데 모든 칼럼을 SELECT해올 필요가 없어서 조금 코드 가시성은 떨어져도 .leftJoinAndSelect의 사용을 지양하고, .leftJoin과 .select, .addSelect를 사용하여 작성하였다. async fin..
개발/TypeORM 2022. 8. 1. 08:20
기존에 faker.js를 사용해서 Seeding용 API 엔드포인트를 구성하였었는데 해당 Faker 모듈이 관리가 안되는 이슈도 있고, request한 유저의 권한을 valid하긴 하지만, 데이터 베이스에 직접적으로 영향을 줄 수 있는 엔드포인트가 외부로 노출되어있는 점이 불안해서 typeorm seeding을 통해 ssh로 직접 서버에 접속해서 커맨드를 날리는 방향으로 변경하였다. Faker.js를 통한 Seed API 작성 백엔드를 개발하다보면 REST API의 GET 메소드에서 DB에서 데이터를 제대로 불러오는지 확인해야하는데 이럴 때 Seed API를 통해 테스트 용도의 fake DB를 구성하는 것이 매번 데이터를 직접 입력해넣 eight20.tistory.com NestJS와 관련된 Seedin..
개발/TypeORM 2022. 7. 14. 08:20
DB를 기존에 사용하던 PostgreSQL에서 MySQL로 변경하고 나서 동일한 Entity의 String 타입으로 지정된 칼럼의 문자열 길이가 공백 포함 255자 이상은 저장되지 않는 이슈가 생겼다. 기존 Entity는 Id, 생성 일시, 마지막 업데이트 일시, 제목, 설명, 썸네일, 링크로 구성되어 있는데 이슈가 발생한 부분은 description 부분이었다. TypeORM의 경우, string 타입으로 칼럼 타입을 지정하면 각 DB의 기본 문자열 저장 타입으로 변환하는데 따로 Character Type을 지정하지 않으면 PostgreSQL은 varchar, MySQL은 varchar(255)이다. // content.entity.ts @Entity() export class Content { @Pr..
개발/TypeORM 2022. 3. 17. 08:20
프로젝트를 진행할 때 TypeORM + PostgreSQL를 사용하여 개발하였는데 TypeORM + MS SQL을 사용해야하는 일이 생겼다. 기존에 PostgreSQL에서 테이블에서 랜덤으로 row를 뽑아 올 때는 PostgreSQL에서 random()으로 랜덤 함수를 지원해서 TypeORM createQueryBuilder에서 .getMany()나 .getOne() 앞에 .orderBy('random()')을 추가해서 ORDERBY random() 쿼리를 데이터베이스로 날렸었다. 아쉽게도 MS SQL에는 random과 같은 랜덤 함수를 지원하지 않았다. 대신 uuid와 같이 unique한 난수를 생성하는 함수인 newId()를 지원해서 해당 함수를 활용해서 랜덤 함수처럼 사용하여 랜덤 row를 가져올 ..
개발/TypeORM 2022. 1. 17. 08:20
QueryBuilder를 사용하여 JOIN 쿼리가 포함된 쿼리문을 작성하다보면 주로 .leftJoinAndSelect 메소드를 사용한다. .leftJoinAndSelect를 사용하면 하나하나 칼럼을 체크할 필요가 없고, 코드 가시성적인 면에서는 장점이 있었지만, 모든 칼럼을 Select해오다보니 성능적인 면에서 필요한 칼럼만을 가져오는 쿼리에 비해 상대적으로 메모리 사용량이 많은 문제점 또한 존재한다. 작성하던 코드 중 JOIN을 3개의 테이블에 걸쳐 쿼리를 날려야되는 API가 있었는데 모든 칼럼을 SELECT해올 필요가 없어서 조금 코드 가시성은 떨어져도 .leftJoinAndSelect의 사용을 지양하고, .leftJoin과 .select, .addSelect를 사용하여 작성하였다. async fin..