NestJs와 TypeORM을 같이 사용할 때, 대부분 TypeORM에서 기본 제공하는 Repository 구현체에 제네릭으로 해당 레포지토리를 통해 접근하려는 엔티티 클래스를 주입해서 Service 클래스의 생성자에 추가하여 사용하였었다. TypeORM에서 제공하는 해당 방식을 사용하면 Repository를 따로 구성하지 않고, 엔티티, 서비스 클래스 만으로 간결하게 구현할 수 있다는 장점이 있었지만, 추후 TypeORM에서 다른 라이브러리로의 전환시, 리팩토링 비용이 많이 들어갈 가능성을 배제할 수 없다. ORM 마다 제공하는 API가 다르기 때문에 interface에 필요한 스펙을 명시해두고, 구현체를 따로 구현하는 방식을 도입했다. 1. 인터페이스 기반 Custom Repository 구현 인터페..
기존에 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를 가져올 ..
개발/NestJS 2023. 11. 22. 08:20
NestJs와 TypeORM을 같이 사용할 때, 대부분 TypeORM에서 기본 제공하는 Repository 구현체에 제네릭으로 해당 레포지토리를 통해 접근하려는 엔티티 클래스를 주입해서 Service 클래스의 생성자에 추가하여 사용하였었다. TypeORM에서 제공하는 해당 방식을 사용하면 Repository를 따로 구성하지 않고, 엔티티, 서비스 클래스 만으로 간결하게 구현할 수 있다는 장점이 있었지만, 추후 TypeORM에서 다른 라이브러리로의 전환시, 리팩토링 비용이 많이 들어갈 가능성을 배제할 수 없다. ORM 마다 제공하는 API가 다르기 때문에 interface에 필요한 스펙을 명시해두고, 구현체를 따로 구현하는 방식을 도입했다. 1. 인터페이스 기반 Custom Repository 구현 인터페..
개발/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를 가져올 ..